[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ext3-users
Subject:    Re: recovery recommendations
From:       Andreas Dilger <adilger () dilger ! ca>
Date:       2011-01-21 20:05:13
Message-ID: 50F3AE32-891C-448F-9AFF-9E700ACD86DC () dilger ! ca
[Download RAW message or body]

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






_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users


[prev in list] [next in list] [prev in thread] [next in thread]