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 <[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
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.