Como encontrar superblocos alternativos no sistema de arquivos ext3 do qcow2 sem partições?

Question

Eu tenho um caso interessante, onde e2fsck se recusa a reconhecer o sistema de arquivos dentro de um arquivo de imagem qcow2. Usando testdisk eu posso ver a partição, então alguns marcadores serão deixados.

A razão pela qual esse problema ocorreu em primeiro lugar foi porque o host da máquina virtual morreu.

Por isso escolho None como o "tipo" de partição e obtenho o seguinte.

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org

Disk /dev/loop0 - 120 GB / 112 GiB - 235156929 sectors

The harddisk (120 GB / 112 GiB) seems too small! (< 4079258 TB / 3710063 TiB)
Check the harddisk size: HD jumpers settings, BIOS detection...

The following partitions can't be recovered:
     Partition               Start        End    Size in sectors
>  ext3                         640  251657855  251657216 [DATA]
   ext3                     1864062  253521277  251657216 [DATA]
   ext3                     1864064  253521279  251657216 [DATA]
   ext3                     2387454  254044669  251657216 [DATA]
   ext3                     2387456  254044671  251657216 [DATA]
   ext3                     2911614  254568829  251657216 [DATA]
   ext3                     2911616  254568831  251657216 [DATA]
   ext3                     3435774  255092989  251657216 [DATA]
   ext3                     3435776  255092991  251657216 [DATA]
   ext3                     3959934  255617149  251657216 [DATA]

[ Continue ]
ext3 blocksize=4096 Large file Sparse superblock, 128 GB / 119 GiB

Parece que os superblocos ainda existem e estão intactos, mas como convencer o mount a usar um desses superblocos, desde que eu não saiba onde eles estão localizados?

kpartx não vê nada em /dev/loop0 depois que fiz o usual losetup -o 32256 /dev/loop0 imagefile para qcow2.

A imagem em si é ( qemu-img info ):

file format: qcow2
virtual size: 120G (128849018880 bytes)
disk size: 112G
cluster_size: 65536
Format specific information:
    compat: 0.10

NB: Eu tenho backups, mas eles têm algumas semanas de idade e, se possível, eu iria diferenciar as coisas no disco contra os backups. A maioria são repositórios do Git e do Mercurial, por isso é possível recuperá-los novamente de outro lugar.

    

Answer 1

Ok, desculpe por responder minha própria pergunta tão cedo, mas notei algo espantoso. O arquivo .qcow2 era do tamanho 120400379904 Bytes, enquanto a conversão da imagem com qemu-img convert -O raw me deu uma imagem do tamanho 128849018880 Bytes.

Totalmente diferente.

Agora, se considerarmos o tamanho em setores encontrados por testdisk , notaremos que 512 * 251657216 é 128848494592, que é 512 bytes mais do que o tamanho do arquivo da imagem "bruta". Isso parece promissor, pensei comigo mesmo.

Eu gerava esses arquivos há alguns anos, então não tenho certeza se os criei como imagens esparsas. No entanto, se qemu-img info mostrar dessa maneira, pensei comigo mesmo, vamos tentar converter o formato da imagem. Tenha em mente que isso não altera o arquivo original!

qemu-img convert -O raw input output

faz esse trabalho, ainda que lentamente.

Executar testdisk novamente nesse arquivo funcionou surpreendentemente bem, embora eu ainda não conseguisse convencer o mount a usar um superbloco diferente, apesar de -o sb=... .

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org

Disk bigdata/vm_disk_vdb.img - 128 GB / 120 GiB - CHS 15666 255 63
     Partition               Start        End    Size in sectors
>P ext3                     0   1  1 15664 239 62  251657216 [DATA]


Structure: Ok.


Keys T: change type, P: list files,
     Enter: to continue
ext3 blocksize=4096 Large file Sparse superblock, 128 GB / 119 GiB

Depois disso, consegui copiar testdisk para os arquivos em um diretório e compará-los com meus backups.

Houve algumas corrupções, como:

ext2fs_read_inode(ino=384492884) failed with error 2133571369.

e também outros problemas menores, mas os problemas estavam afetando apenas cerca de 0,1% de todos os arquivos e pastas. Inicie testdisk da seguinte forma para poder descobrir quais arquivos devem ser considerados danificados:

testdisk /log imagefile.img