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 > > > > > _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
