Qualquer maneira de recuperar sistemas de arquivos ext4 de um volume lógico LVM excluído?

Question

No outro dia, tive um bom momento cerebral durante a expansão de um disco em um convidado Linux em VMware. Eu estiquei o arquivo de disco Vmware para o tamanho desejado e então fiz o que costumo fazer em convidados Linux sem LVM: eu apaguei a partição LVM e a recriou, começando no mesmo local que a antiga, mas estendido para o novo tamanho do disco. (Que será seguido por fsck e resize2fs.)

E então eu percebi que o LVM não se comporta da mesma maneira que o ext2 / 3/4 em partições raw ... Depois de restaurar o guest Linux do backup mais recente (tirado apenas cinco horas antes, por sorte) agora curioso sobre como eu poderia ter recuperado do seguinte cenário. Afinal, é virtualmente garantido que eu também serei um idiota no futuro.

Convidado Linux virtual com um disco, particionado em uma partição / boot (primária) (/ dev / sda1) de 256MB e o restante em uma partição lógica estendida (/ dev / sda5).

/ dev / sda5 é então configurado como um volume físico com pvcreate, e um grupo de volumes (vgroup00) é criado sobre ele com o comando usual vgcreate. vgroup00 é então dividido em dois volumes lógicos root e swap, que são usados para / e swap, logicamente. / é um sistema de arquivos ext4.

Como eu tinha backups do guest quebrado, consegui recriar o grupo de volumes com vgcfgrestore a partir da instalação do LVM de backup localizada em / etc / lvm / backup, com o mesmo UUID para o volume físico e tudo isso. Depois de executar isso, eu tinha dois volumes lógicos com o mesmo tamanho anterior, com 4 GB de espaço livre onde esticara o disco.

No entanto, quando tentei rodar o "fsck / dev / mapper / vgroup00-root" ele reclamou de um superbloco quebrado. Tentei localizar superblocos de backup executando "mke2fs -n / dev / mapper / vgroup00-root", mas nenhum deles funcionou. Então eu tentei rodar o TestDisk mas quando eu pedi para encontrar superquadros ele apenas deu um erro sobre não conseguir abrir o sistema de arquivos devido a um sistema de arquivos quebrado.

Portanto, com a política de alocação padrão para o LVM2 no Ubuntu Server 10.04 de 64 bits, é possível que os volumes lógicos sejam alocados a partir do end do grupo de volumes? Isso definitivamente explica por que os volumes lógicos restaurados não contêm os dados esperados. Eu poderia ter recuperado recriando / dev / sda5 exatamente com o mesmo tamanho e posição de disco que anteriormente? Existem outras ferramentas que eu poderia ter usado para encontrar e recuperar o sistema de arquivos? (E claramente, a questão não é se eu deveria ter feito isso de uma maneira diferente desde o começo, eu sei disso. Essa é uma pergunta sobre o que fazer quando a merda já atingiu o ventilador.)

    

Answer 1

Toda vez que você executa uma operação com o LVM, por padrão, os metadados anteriores são arquivados em /etc/lvm/archive . Você pode usar vgcfgrestore para restaurá-lo, ou pegar as extensões manualmente (mais difícil, mas lvcreate(8) deve cobri-lo).

Editar:

E para facilitar ao máximo, devo acrescentar que você pode encontrar o último backup antes de sua operação destrutiva, observando as descrições:

# grep description /etc/lvm/archive/vg01_*
/etc/lvm/archive/vg01_00001.vg:description = "Created before executing 'lvremove -f /dev/vg01/foo'"
/etc/lvm/archive/vg01_00002.vg:description = "Created before executing 'lvremove -f /dev/vg01/bar'"
/etc/lvm/archive/vg01_00003.vg:description = "Created before executing 'lvremove -f /dev/vg01/baz'"

Editar:

A política de alocação normal (padrão) alocará uma faixa do primeiro PE livre quando houver espaço suficiente para isso. Se você quiser confirmar onde o LV foi alocado, você pode procurar nos arquivos, estes são perfeitamente legíveis por humanos.

    

Answer 2

Não há opções de recuperação realmente boas e não há ferramentas que suportem isso ao meu conhecimento. No entanto, consulte a seção de recuperação de dados de perigos e advertências do LVM para alguns artigos sobre recuperação manual.

Geralmente, é melhor fazer um backup de imagem bruta do (s) volume (s) quebrado (s) ou discos subjacentes e fazer a recuperação de dados nas versões de backup, para que você tenha uma nova tentativa de recuperação.

A resposta acima também tem uma seção sobre o redimensionamento de volumes de LVM - expandi-los é razoavelmente seguro, e geralmente é melhor usar lvresize em vez de excluir e recriar.

Em um ponto relacionado: como você está usando o VMware, você também deve cuidar para que o cache de gravação do disco rígido elimine as barreiras de gravação do kernel Linux convidado por meio do hipervisor e de qualquer sistema operacional host. Também é importante que as barreiras de gravação sejam configuradas no guest FS e no guest kernel, que devem ser 2.6.33 ou superiores.