recovering ext4 partition after dd'ing over start of HD

Question

I accidentally used dd and wrote over the first 208MB of my external disk. What I wrote over is a partition on its own (Debian nestinstaller) so what I see now is not my old (now damaged) ext4 partition but another smaller partition. This limits the tools and advices I could follow.

My plan was to recreate the partition table with testdisk and then fix everything with the backup superblocks as described here. I'd lose the first 208MB but that's ok compared to the other 300GB of data in there. Something like the following:

mke2fs -n /dev/sdb1   # doesn't work because sdb1 is the 208MB new partition
testdisk ...          # used this to create new correct partition table
mke2fs -n /dev/sdb1   # now works fine, get backup superblock positions
e2fsck -b backup_position -y /dev/sdb1 # returns many errors hence the -y

However, I have been unable to recover anything. I used testdisk to write a new partition table that matched what I had before. When I then run e2fsck I get many different errors. I get a filesystem after that but it's completely empty, no files.

The lost+found directory is full of files (recovered ones I think) but I need to recover the directory tree, not just the files. I need the filename and previous directories to know what the files are (microscope images, mass spec data, etc.. Without the names and the directories where they were, they mean nothing).

I got another HD exactly the same and made a copy of the whole HD with dd so I can experiment recovery without losing anything. Any advice?

Answer 1

I finally managed to fix this. Just for the record here's how I did it. Part of the solution I found here and it involves knowing the settings used to create the filesystem (I was pretty sure I didn't change the defaults).

Basically I first had to fix the partition table to reflect what I actually had there (I used testdisk for this but parted, cfdisk or fdisk should work fine as well). I just removed the wrong partitions and replaced by a single ext4 type partition covering the whole disk with the correct CHS values.

The rest is mostly from the link at start (read it for details) but basically I ran mke2fs -n /dev/xxx to find the positions for the superblocks backup. Then used the last backup closest to the end of the disk (only the ones at the start of the disk had been overwritten with dd) to run fsck. This generated a lot of errors but fsck has a -y option (not the same as -a).

$ sudo e2fsck -a -b backup_block_number /dev/xxx

I thought this had not worked because I couldn't see any files but actually they had all been saved to the lost+found directory.

So in the end I did salvage most of my files while keeping their filenames and directory structure. Hope this may help others in the future.

Answer 2

Ok, this works for recovering from an accidentally inited drive in a MegaRAID array. My RAID controller inited ALL the drives in the RAID, not just the ones for the RAID6 array I was remaking. Ouch! At least I did a quick init, and not a slow init - the slow init wipes the drive to zeros.

Quick init erases 10M at the beginning and end of the drives. So, me with an ext4 partition on the whole drive (under Linux) and one drive, RAID0, had some chance. With the drive being a 6TB drive, and almost 5TB on it, I was sweating - it was my backup of the RAID6 array I was reforming!

By the way, I did not slip up - the LSI MegaRAID should NOT have inited drives in my other drive group - but it did. As a note, what I should have done is REMOVE THAT DRIVE FROM THE ENCLOSURE and re-imported it AFTER I had the newly arranged RAID6 drive group. Silly me. REALLY silly me....

OK, fortunately the LSI MegaRaid does nothing fancy with RAID0 drives (if there is one I guess not sure about multiple). Here is what I did to fix it. OS=Fedora F22. Drive = one big ext4 partition, done with parted. First I snap-shotted the drive to a brand new, exact same model drive, in a spare server with a couple of spare bay slots:: Ten hours later it finished......

$ dd if=/dev/sdb of=/dev/sdc bs=64M conv=notrunc
89424+1 records in
89424+1 records out
6001175126016 bytes (6.0 TB) copied, 35130.2 s, 171 MB/s

That was my golden backup.

NOTE - My drive was /dev/sdb - you need to set your to whatever drive you are trying to recover. Don't screw up the drives, or you will be in even more of a mess....

Then, that done I did the following.

(1) remove snapshot from machine (not silly again, I can assure you - that one would be off to disk recovery hospital if I failed, while I checked myself into the local ER!).

(2) reboot FC22 machine with the drive. Run parted, redo the partition (in my case, delete the corrupted one, write in a new 0% to 100% ext4 partition). You HAVE to know exactly where the original partitions were, and their exact type - the next step depends on this - if not, STOP HERE. You won't make it. use testdisk and photorec or similar, or for a big drive where it really matters, ship it out.

(3) run mke2fs -n /dev/sdb1 (don't forget the -n, or again you can just walk away...)

For me the result looked like:

$ mke2fs -n /dev/sdb1
$ mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 1464843008 4k blocks and 183107584 inodes
Filesystem UUID: 1ac318a6-7953-42d5-8d7b-0597c54e1935
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544

There you are, that's where all the spare superblocks are...... We know the first and last are trash, but the ones in the middle should be OK. (Note, you can use mkfs.ext4 -n /dev/sdb1 to be super cautious and get the same result).

(4) Run e2fsck -y -b 102400000 /dev/sdb1. You will need the -y, as there will be a lot of "yes" needed to fix the mess created by the missing front end of the disk.... and choose any superblock in the middle you like... and after about 30 minutes of silence (use another terminal and "top" to watch the progress, or the flashing disk light) in my case presto, a mountable partition, and pretty much everything intact in the /lost+found directory.

Anyway I hope this helps - if you are reading this carefully, then I wish you the best of luck. And thanks to the guys writing above. You saved me from a really sickening end.....