recovery recommendations

[Eric Sandeen]

On 1/21/11 2:05 PM, Andreas Dilger wrote:
> 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).

Oops sorry, my old physics teacher would not be proud:
"think units before you think numbers" he said...

So ignore what I said, and listen to Andreas. Sorry about that!

-Eric

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