Como recuperar dados de uma unidade desarrumada (LVM escrito em cima de Ext4)?

5

O administrador anterior de um servidor que está sob minha supervisão cometeu um erro. Ele acidentalmente criou um volume LVM (não mais do que pvcreate, eu acho, embora não tenha certeza) em um disco que realmente continha uma partição Ext4 com dados. Como recuperar dados de um erro como este? Estou pronto para ler a documentação do ext4 e fazer o meu, mas talvez não seja necessário? Algumas ferramentas que eu tentei não conseguiram encontrar um sistema de arquivos Ext4, então acho que preciso de algo mais sério.

    
por Vilx- 08.09.2014 / 00:08

3 respostas

6

Se você executar mkfs.ext4 -n /the/partition , ele imprimirá como seria uma unidade formatada EXT4 nesse sistema.

# mkfs.ext4 -n /dev/dm-3
mke2fs 1.42.8 (20-Jun-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
3276800 inodes, 13107200 blocks
655360 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
400 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424

É importante que ele indique onde estão os locais dos superblocos.

Usando essas informações, tente montar a unidade usando um superbloco alternativo.

mkdir /tmp/mntpnt
mount -o ro,sb=163840 /dev/dm-3 /tmp/mntpnt

Desde que apenas os cabeçalhos da partição sejam destruídos, pode funcionar.

Se isso não funcionar, você pode tentar consertar o sistema de arquivos usando fsck.ext4 , especificando o endereço do superbloco. Faça backup dos dados com dd ou algo assim antes de fazer isso .

fsck.ext4 -b 163840 /dev/dm-3

Isso pode acabar substituindo o superbloco ruim por um dos bons conhecidos, o que poderia ser o suficiente para fazer com que todo o disco fosse remontado. Então, novamente, você pode perder os inodes da chave (como o seu inode do sistema de arquivos raiz). A milhagem pode variar.

    
por 08.09.2014 / 03:26
3

Eu daria a demonstração do UFS Explorer para ver o que ele pode detectar ... É o meu utilitário go-to para recuperação de sistema de arquivos . Uma vez eu tive uma partição XFS com 4 milhões de arquivos deletados acidentalmente e usei esse utilitário para recuperar os dados.

Mas fora disso, é uma experiência de aprendizado e uma chance de testar sua rotina de backup. Desculpe pela perda.

    
por 08.09.2014 / 00:20
3

A primeira etapa em qualquer operação de recuperação é fazer uma cópia dos dados e executar a recuperação na cópia. Depois de fazer isso, você pode tentar recuperar os dados.

Dependendo do que exatamente o administrador fez, o mais provável é que a tabela de partição tenha sido corrompida, o superbloco principal do volume tenha sido corrompido ou ambos. Você pode reconstruir a tabela de partição usando fdisk : basta criar uma nova tabela de partição com a mesma configuração do original. Certifique-se de obter o tipo (MBR ou GPT) correto. e2fsck -b permitirá que você execute um reparo do sistema de arquivos usando uma das cópias secundárias do superbloco ou, no caso improvável de todos terem sido corrompidos, mke2fs -S recriará a estrutura de metadados sem tocar nos dados.

    
por 08.09.2014 / 01:48