recovery recommendations

[Andreas Dilger]

On 2011-01-21, at 12:06, Eric Sandeen wrote:
> On 1/21/11 12:36 PM, m.p. wrote:
>> Recently a 640GB external enclosure was PEBKAC'd with the following
>> command:
>> 
>> dd if=/some-185mb-linux-install.iso of=/dev/sdx
>> 
>> [not of=/dev/sdx1]
>> 
>> Since the PEBKAC, the drive has not been written to beyond being
>> unplugged. I have made an image of the drive and have attempted to run
>> against it: testdisk, fsck.ext3 with alternate superblocks, and even
>> "fsck.ext3 -Sy", to no avail.
>> 
>> So. I am *convinced* that my 550gb of data is recoverable. It seems that
>> [obviously] the first 185mb is gone - whatever files those were.
> 
> You really need to restore from backups.  You just overwrote 30% of
> your filesystem with something else... you've lost partition data,
> metadata, directory data, file data ... whatever was in that first
> 185M.

Eric, note 185 Megabytes, vs 550 Gigabytes, so only the first 1.5 groups were clobbered (which may have been largely filled by the journal, depending on when the filesystem was formatted).

> I think the best you can do is low-level recovery at this point,
> groveling around for file fragments with something like the photo recovery
> tools.

Actually, I think the chance for significant data recovery is pretty good.

> Maybe, just -maybe- if you can find a backup superblock, fsck might try
> to piece a few things together.

I think the first thing to do is to recover the partition table EXACTLY the way it was before.  There was a tool for this, "gpart" or something similar, that could recover partition tables.

Alternately, if you build and run the "findsuper" tool from e2fsprogs sources (I've attached an x86_64 binary here, maybe it will work for you), it will tell you the starting and ending offset of each ext* filesystem, based on superblocks that it finds on the disk.  You need to take the byte offsets and convert them into kB or sector offsets for use with fdisk.

Once you get the partition table correct, e2fsck should have no problem to recover the filesystem, though it will be missing the root directory and possibly a bunch of other files that were stored in the first 185MB of disk.  The possibly good news is that the journal _used_ to be stored at the start of the filesystem, and would fill 32MB or 128MB of the start of the disk, and in turn that dissuaded the allocator from putting files into that group.  Sadly (maybe), the journal is now allocated in the middle of the filesystem for performance reasons and that coincidental "data protection" is no longer with us.

> But you can't generally overwrite 1/3 of a filesystem and expect normal
> tools to recover for you, I'm afraid.

Surprisingly, extN is very robust in this regard.  I've been able (required) to recover data from similarly corrupted filesystems, and a lot can be done.  With changes like flex_bg and UNMAP it will get a lot harder, however.


Cheers, Andreas