1

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?

3 Answers 3

1

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)

3
  • 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, 2010 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, 2010 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, 2010 at 13:54
0

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.

2
  • Already done...First thing I did was make sure I had 2 copies of each drive
    – Jason Berg
    Aug 30, 2010 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, 2010 at 23:36
0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .