2

Accidentally booted the Acer Recovery partition of my multi-boot laptop and despite selecting EXIT when presented with a choice of whether I wanted to recover anything or not, one of my partitions got mangled. Now I could really use some advice on rewriting the partition table and recovering the filesystem.

  1. I've cloned the whole drive (dd if=... | ssh me@desktop -of=...) and am working exclusively on the cloned drive.

  2. I've tried gpart, parted, testdisk (as well as gparted). No luck so far.

My drive layout is:

/dev/sda1 ntfs 12GB
/dev/sda2 ntfs 100MB
/dev/sda3 ntfs 72.17GB
/dev/sda4 extended 213.82GB
  unallocated 27.93GB
  /dev/sda5 ext4 148.98GB
  /dev/sda6 ext4 29.33GB
  /dev/sda7 swap 7.58GB
unallocated 2.49MB

The mangled partition is the ~30GB unallocated partition (first logical partition in the extended partition).

Too bad Acer Recovery hit that exact partition. I wouldn't have bothered trying to recover any of the others (Windows that I don't use, Linux for testing, Linux alt. distro also for testing). This one, though, contains data I'd really like to recover.

I know the exact boundaries of the partition, I know the details of the underlying (ext4) filesystem.

However, the tools usually recommended to recover are not working. A deep scan by testdisk indicated that the Acer Recovery tool apparently decided to copy the partition table for the main Windows partition resulting in complaints about sizes not matching up. gpart, parted and testdisk were not able to find a filesystem. testdisk found an ntfs filesystem which was "unrecoverable".

I suspect the superblock was nuked as well, but a search revealed the existence of multiple backup superblocks.

What's the best bet moving forward? I want to try and rewrite the partition table and recover the filesystem, presumably with e2fsck using a backup superblock.

What tool will allow me to rewrite the partition table without doing anything to my data? What about setting a filesystem? Would I need to do that before trying to restore the superblock from backup? How?

TIA,

fyo

Improve this question
2
  • There are tools, like Convar's PC Inspector, which analyses raw disc and find files with recognisable formats within it, even without the help of the indices that a filing system normally provides, though the less fragmented the disc, the better. You will need a bootable Windows system, like Hiren's Boot CD, to run it. I recommend backing up the raw disc before you start: I have successfully used dd from a Linux LiveCD to save raw disc to a file and restore it to have another go after a failed recovery.
    – AFH
    Commented Jun 17, 2015 at 23:24
  • As I noted, I have already backed up the entire disk. I am convinced that everything on the partition is there, with the exception of initial part. There are numerous ways of attempting to recover individual files, but that is a last ditch effort. At this point what I want is to recover my partition as a whole, essentially restoring it to its previous state. I am not convinced that this is not possible, despite testdisk et al claiming that anything found was "unrecoverable". I am convinced my data is all there. At this point, I'm going to try a more forensic approach. Will report back.
    – fyo
    Commented Jun 23, 2015 at 9:44

3 Answers 3

Reset to default
0

If you are asking if you can recover the 30GB unallocated partition, I don't think you can. Unallocated partitions can't be recovered from my understanding. Someone correct me if I'm wrong.

Improve this answer
3
  • You can, actually, if you recreate the partition table and as long as nothing causes the partition to be overwritten.
    – oldmud0
    Commented Jun 18, 2015 at 0:53
  • @oldmud0 Ohh, I see. Thanks for the correction.
    – Thom
    Commented Jun 18, 2015 at 1:00
  • I have attempted to recreated the partition table, but without much luck. No (valid) filesystem is found and the superblock plus backup superblocks are all reported either missing or invalid ("bad magic number"). I'm thinking there might be some offset issue making everything come up wrong and have set aside some time to look at the raw data with a hexeditor and try to see if I can find things manually and perhaps even figure out what the problem is.
    – fyo
    Commented Jun 23, 2015 at 9:46
0

Since you state you know the partition boundaries I would use losetup with options -o offset and --sizelimit size

This will let you create a loopback device of the 30GB partition that you can operate on. If the partition is not overwritten a Testdisk search on the loopback device should find something.

You could also use Photorec to search for files based on file extension, if just to verify that your data is still there.

Improve this answer
0

Finally sorted it out and everything is back to normal. There were a couple of oddities that others might possible learn from, so here are the details:

Everything was done on a CLONE of my drive. Please clone your drive (or at least partition) before you start messing around with anything, preferably from a live CD.

My first step after the usual tools failed to produce a result (as per the OP) was to simply use a hex editor (hexedit) to edit the whole partition, skipping to the first byte of the unallocated space where my things were supposed to be.

Compare the results in the hex editor with Ext4 Disk Layout: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout

Everything was quite clearly there. The superblock, which all the tools reported was bad, was there and looked perfectly fine. The data was there. Probably the only thing every mangled was the partition table.

However, the superblock was offset 2048 bytes as opposed to 1024 bytes per the spec. This is apparently was caused many of the tools to fail.

Armed with this knowledge, I fired up testdisk again and started translating their CHS triplets to sectors to see what the heck was going on. As mentioned initially, testdisk did actually find what was presumably my partition, but it wouldn't restore it. After checking the sector boundaries of all the partitions, the reason was clear:

Testdisk showed to of my partitions as being larger than they in fact were (sda3 and sda5 in the OP). I'm not sure why. The current partition table showed the correct size and the ext4 filesystem in sda5 showed the correct number of blocks. In the case of sda5, testdisk found the partition to overlap sda6, so it wouldn't allow me to select both in the revised partition list. In the case of sda3, the partitions didn't overlap, but testdisk still wouldn't allow me to restore my missing partition along with sda3. The gap between them was presumably smaller than testdisk liked, for whatever reason.

Creating a partition with GParted in the unallocated space wasn't working because GParted insisted on a 1MB gap between sda3 and the new partition. Even with the correct sda3 size, this would result in the superblock (and much more) being wiped, so that was a no-go. Kind of odd, since all my partitions (except the two Windows Restore ones) were created with various versions of GParted.

The solution was to use parted instead and manually enter the correct boundaries, which were actually correctly detected by testdisk (and verified with hexedit, since testdisk did not accurately detect other boundaries).

Whew.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .