So I've been handed these 2 drives that were part of a RAID0 (eek!) array in a NAS. One of the drives had failed. Turns out, the drive had a bad controller card. What I've done is copied the information from the good drive to another good drive (dd if=/dev/sda of=/dev/sdb) then swapped the controller card to the bad drive. The bad drive now spins up and I can see bits on it.

I'm trying to rebuild the array but it's failing. For some reason, there's no superblock information on either drive. I'm not sure why that's the case. The drives came out of an Iomega Storcenter, so maybe it did something weird to create the array. I've tried rebuilding the array like this:

mdadm --assemble --scan

and this:

mdadm --create /dev/md0 --assume-clean --raid-level=0 --raid-devices=2 /dev/sda4 /dev/sdb4

That second one creates the RAID and I can pick out certain data when reading it with a hex editor, but the filesystem still won't mount.

Anybody have any tips for what I should be trying next?


Have you tried to assemble the drive by explicitly specifying all (or as much as possible) parameters?

I'd try mdadm --assemble /dev/md0 /dev/sda4 /dev/sdb4 - If that doesn't work, specify the level and blocksize, or try by uuid instead of by components.

You could try mdadm -E /dev/sda4 and /dev/sdb4 as well, to see how much info is still there.

I think the create assume-clean only works in very specific situations; please try the above with the original images (without create)

  • Examining the drive just complains about no superblock being detected...same thing with assemble...no matter how much information I give it, it won't assemble without the superblocks – Jason Berg Aug 30 '10 at 16:53
  • No superblock on either drive, even on the good one? That's strange... was it a md-raid before or a hardware-raid? – Joris Aug 30 '10 at 20:09
  • Drives came out of an Iomega Storcenter. I hacked around a bit with the device and I can say it definitely looks like it was an md-raid. – Jason Berg Aug 31 '10 at 13:54

I'd copy the bad drive to a new drive using dd before doing anything else.

The bad drive probably has mechanical or electronics problems, and the utilities you are using are not designed to cope with these. Most drive failures I see anymore are fast and furious hardware/electronics failures, so I pull bad drives immediately and copy the data to new drives before doing anything else. Every minute you run a defective drive increases your chance that the data will be unrecoverable without time consuming drive surgery. Look in dmesg or /var/log/kernel for clues.

  • Already done...First thing I did was make sure I had 2 copies of each drive – Jason Berg Aug 30 '10 at 16:28
  • Your commentary said that you put the BAD drive into the controller and had problems with it. Have you checked the kernel logs and dmesg, or were you simply using "the force"? – voltaire Sep 1 '10 at 23:36

Raid Reconstructor. I'm sure it's saved plenty of butts in the past. Ran in on copies of the drives and it spit out an image that I could run repairs against. Looks like all of my client's data is in tact. Not a free solution, but sometimes it's just worth paying for something that does the job well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.