The good: I have a five-disk RAID5. One drive began dying, so I used mdadm to fail it and remove it from the array. I physically added the new replacement drive and booted to a liveCD.

The bad: To recreate identical partitions on the new drive I used gparted to copy the partitions from an old drive, which automatically performed an fsck on the old drive's partitions. This removed whatever lets Linux know it is a RAID member, preventing md from using it. The partition types now show ext4 and it cleared the partition labels and "UUID_SUB"s. I tried to fix this by using dd to copy the MBR (first 512 bytes) from a valid RAID member, which didn't seem to change anything. I also used cfdisk to manually set the partitions' types to "linux raid autodetect", which seemed to have no effect. The partition types for valid RAID members display as "linux_raid_member" and they all have "UUID_SUB"s which resemble a normal UUID.

The question: I think the data on the old drive is still intact. If so, how can I get md to recognize it as a RAID member again? Apparently this information is not stored in the first 512 bytes or the dd operation would have fixed it. My server's been down for two days now, so any insight is greatly appreciated!

I'm not that knowledgable on using mdadm, but wouldn't dd-ing the header of another raid drive just create a clone of an already existing RAID member since they have the same disk identifier?
Also, I'm doubt that RAID layouts adhere to the 512 bytes where the MBR is usually written.

Look here for more information on the RAID superblock versions. It lists info on multiple versions of the linux kernel raid superblock (where the raid information is actually stored on disk)

According to this, I believe mdadm uses the superblocks .90 or higher.

EDIT: Even if the ext filesystem didn't overwrite any data on the disk, I still don't know how you would go about recovering the superblock and restoring the correct UUID.
Try reading this.

Pascal

1 members found this post helpful.