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.....
testdisk
to recreate the partition. I will try withfdisk
.fdisk
I couldn't even usee2fsck
as it wouldn't find the superblock backups. I think the problem was that I couldn't edit the CHS (the new partition set it to 64 but should be 255)