Recuperação do LVM Filesystem

Question

Eu estava tentando redimensionar minha cripta LUKS seguindo este link e cheguei à partição redimensionar com parted e seriamente estragar as coisas. Eu digitei 870 como o novo tamanho e esqueci de colocar um G no final. Ele reduziu minha partição para 870M . Eu a redimensionei imediatamente para 870G , mas então o dano foi feito. Felizmente, eu ainda poderia descriptografar a cripta do LUKS, mas não consegui que meu Volume Lógico tivesse um arquivo de dispositivo no sistema. O LVM reconheceu o volume como existente e mostrou o arquivo do dispositivo ao qual ele estava anexado, mas o arquivo não existia e mostrou que ele não tinha nenhum sistema de arquivos. Eu fiz vgscan --mknodes e ele gerou com sucesso o arquivo do dispositivo, mas testdisk ainda não o mostraria. Eu recriei o volume e coloquei um novo sistema de arquivos ext4 nele e agora testdisk mostrará a unidade, mas a varredura não gera nada. Eu recebo um monte de entradas ext4, mas todas elas dizem Não é possível abrir o sistema de arquivos ou Nenhum arquivo encontrado. Existe alguma maneira para eu recuperar o sistema de arquivos que estava no disco? Eu não quero escrever nenhum dado até obter o que está nele, a menos que isso não seja possível.

EDIT: Depois de cutucar a coisa real que eu preciso de ajuda é recuperar arquivos de um sistema de arquivos ext4 anterior. Minha unidade tinha um sistema ext4 e, desde então, foi sobrescrita por uma nova, no entanto, todos os dados do sistema antigo ainda existem, como mostrado por sudo dd if=/dev/Storage/Storage bs=1M | strings -fn 16 . A única coisa que fiz depois do meu estrago foi colocar um novo ext4 FS on e nada mais, então a maioria dos meus dados provavelmente ainda está intacta. Eu preciso recuperar esses dados.

pvdisplay mostra o seguinte

--- Physical volume ---
PV Name               /dev/mapper/Storage
VG Name               Storage
PV Size               931.51 GiB / not usable 3.68 MiB
Allocatable           yes (but full)
PE Size               4.00 MiB
Total PE              238466
Free PE               0
Allocated PE          238466
PV UUID               CAueGx-Glzx-zCd0-H00m-R8d5-KTRc-9Ff7ay

--- Physical volume ---
PV Name               /dev/mapper/sda3_crypt
VG Name               mint-vg
PV Size               118.50 GiB / not usable 0   
Allocatable           yes 
PE Size               4.00 MiB
Total PE              30336
Free PE               10
Allocated PE          30326
PV UUID               UJJfu8-S2Ac-pEZl-PlPa-uUzJ-axEs-ckbDWG

Meu backup mostra

# Generated by LVM2 version 2.02.98(2) (2012-10-15): Thu Aug 13 20:45:52 2015

contents = "Text Format Volume Group"
version = 1

description = "Created *before* executing '/sbin/lvreduce --config log{command_names=0} -f -l 217600 /dev/Storage/Storage'"

creation_host = "desktop"   # Linux desktop 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64
creation_time = 1439523952  # Thu Aug 13 20:45:52 2015

Storage {
     id = "lM3S9T-inH1-mKsq-5doN-H8hT-zO3F-LF9jDx"
    seqno = 2
    format = "lvm2" # informational
    status = ["RESIZEABLE", "READ", "WRITE"]
    flags = []
    extent_size = 8192      # 4 Megabytes
    max_lv = 256
    max_pv = 256
    metadata_copies = 0

    physical_volumes {

        pv0 {
            id = "nH1Axo-5nBo-WcyA-Xc4E-KwRt-K0Ib-ScK8Ch"
            device = "/dev/mapper/Storage"  # Hint only

            status = ["ALLOCATABLE"]
            flags = []
            dev_size = 1953520999   # 931.511 Gigabytes
            pe_start = 2048
            pe_count = 238466   # 931.508 Gigabytes
        }
    }

    logical_volumes {

        Storage {
            id = "Qb01kz-y1RG-PVQp-cGjB-sj77-xgnJ-w9kn3n"
            status = ["READ", "WRITE", "VISIBLE"]
            flags = []
            creation_host = "desktop"
            creation_time = 1436247513  # 2015-07-06 22:38:33 -0700
            segment_count = 1

            segment1 {
                start_extent = 0
                extent_count = 238466   # 931.508 Gigabytes

                type = "striped"
                stripe_count = 1    # linear

                stripes = [
                    "pv0", 0
                ]
            }
        }
    }
}

    

Answer 1

Você não pode consertar o LVM aumentando o tamanho do tamanho original, a menos que tenha muita sorte e o LV não tenha nenhuma fragmentação devido aos redimensionamentos anteriores. As chances são de que o novo LV terá o primeiro 20G de seu sistema de arquivos original, mas os 780G restantes (ou o que quer que seja) são ovos mexidos (dados errados, compensação incorreta, ordem errada).

E isso supondo que você esteja usando mídia HDD. Se fosse SSD, com issue_discards=1 no seu lvm.conf , os dados simplesmente desapareceriam, e é por isso que nunca uso essa opção.

Você precisa verificar /etc/lvm/{archive,backup}/ para versões antigas de seus metadados. Cada arquivo lá diz quando foi criado, por exemplo:

description = "Created *before* executing 'lvremove HDD/mdtest1'"

Você está procurando o que diz Created before lvresize 850 com G ausente. E, em seguida, vgcfgrestore metadados do LVM usando esse backup e esperamos que ele volte a funcionar.

Se você não tem esses arquivos em /etc/lvm , ou porque você fez isso de um CD ao vivo que perdeu esses dados, ou o dano aconteceu no seu LV raiz, as coisas ficam um pouco mais complicadas como você tem que esperar os metadados do LVM no disco para conter esse bit de histórico em seu buffer circular.

Método aproximado para ver o que possivelmente está aí:

dd if=/dev/pvdevice bs=1M count=1 | strings -w -n 16

    

Answer 2

Se você não tivesse perdido o antigo ext4, poderia ter havido alguma esperança de fsck fazer alguns reparos e encontrar algumas estruturas de diretório intactas.

Ainda pode haver esperança para isso, usando um superbloco alternativo que estava na parte do disco em que você não mexeu com mkfs . Ou se o seu antigo FS tiver um número diferente de superquads de backup do que o seu FS vazio atual, pode haver alguns que não foram sobrescritos.

e2fsck -b some-offset

Isso se aplica somente se o seu LV estiver mapeado para os mesmos bytes que o antigo (sobre o qual Frostschultz falou em sua resposta).

Você pode recuperar alguns tipos de arquivos que podem ser selecionados em um fluxo binário. (Desde que você não tem nomes de arquivo de mapeamento de metadados para intervalos de bytes.) Alguns arquivos têm um cabeçalho reconhecível, e é possível dizer onde está o fim do arquivo. Contanto que seus arquivos estejam fragmentados, há alguma esperança de recuperar alguns arquivos sem nome.

O mais importante é uma ferramenta para fazer isso. Pretende encontrar ficheiros jpg, gif, png, bmp, avi, exe, mpg, wav, riff, wmv, mov, pdf, ole, doc, zip, rar, htm e cpp.