2

I have an interesting case, where e2fsck refuses to recognize the file system inside a qcow2 image file. Using testdisk I am able to see the partition, so some markers would be left.

The reason this problem occurred in the first place was because the host of the virtual machine died.

So I choose None as the "type" of partition and get the following.

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
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

It seems superblocks still exist and are intact, but how can I convince mount to use one of those superblocks as long as I don't know where they are located?

kpartx doesn't see anything on /dev/loop0 after I did the usual losetup -o 32256 /dev/loop0 imagefile for qcow2.

The image itself is (qemu-img info):

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

NB: I do have backups, but they are a few weeks old and if at all possible, I'd diff the stuff on the disk against the backups. Most are Git and Mercurial repos, so it's possible to fetch them again from elsewhere.

0

Okay, sorry for answering my own question so soon, but I noticed something flabbergasting. The .qcow2 file was of size 120400379904 Bytes, whereas the conversion of the image with qemu-img convert -O raw gave me an image of size 128849018880 Bytes.

Quite a difference.

Now, if we take the size in sectors found by testdisk, we will indeed notice that 512*251657216 is 128848494592, which happens to be 512 Bytes more than the file size of the "raw" image. That looks promising, I thought to myself.

I generated these files a few years ago, so I am not sure whether I created them as sparse images. Nevertheless, if qemu-img info shows it that way, I thought to myself, let's try to convert the image format. Keep in mind that this doesn't change the original file!

qemu-img convert -O raw input output

does that job, albeit slowly.

Running testdisk again on that file worked surprisingly well, although I was still unable to convince mount to use a different superblock, despite -o sb=....

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
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

After that, I could get testdisk to copy the files into a directory and diff it against my backups.

There were a few corruptions, such:

ext2fs_read_inode(ino=384492884) failed with error 2133571369.

and also other minor issues, but the problems were affecting only about 0.1% of all files and folders. Start testdisk as follows to be able to figure out which files must be considered damaged:

testdisk /log imagefile.img

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.