recovery recommendations
Eric Sandeen
sandeen at redhat.com
Fri Jan 21 20:09:19 UTC 2011
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
>
>
>
>
>
More information about the Ext3-users
mailing list