Home / server / Questions / 1040035
In Process
user3728501
Asked: 2020-10-26 11:00:59 +0800 CST

mdadm - Attempted to move raid array to new system, superblocks gone?

  • 772

I attempted to move a mdadm raid 1 array to a different system this evening.

I took the 2 SSDs out of one system and put them in another, then booted that system.

I opened gparted to check what the disks appeared as. They showed up as being blank (unallocated) drives.

I then shut down this system and moved the drives back to the original system, and booted.

sudo mdadm --assemble --scan --verbose

reported that no raid superblocks were found on sdg or sgh, which is where I would expect the data to be.

I thought this should be a fairly trivial process, but I'm now not sure what to do.

Any help would be appreciated, it's kind of important I don't loose the data on these drives...

This is the (approximate) output of sudo mdadm --misc --examine /dev/sd[efgh]

sde/sdf report the expected output, starts with Magic a92b4efc... then prints a bunch of info about this raid 1 array.

sdg/h simply produce mbr magic aa55 and then partition[0]: 1953525167 sectors at 1 (type ee)

I really have no idea what this means but I have a feeling from an issue I was having with another system that there is some conflict between the mdadm raid information and a gpt parition table? Is my guess right, if so what should I do about this? Perhaps assemble the raid in a degraded state and see if the data can be read?

fdisk -l

sde/f make up md1, md0 is missing - should be sdg/h.

Disk /dev/sde: 931.5 GiB, 1000207286272 bytes, 1953529856 sectors
Disk model: WDC WDS100T2G0A-
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/md1: 931.4 GiB, 1000072019968 bytes, 1953265664 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sdf: 931.5 GiB, 1000207286272 bytes, 1953529856 sectors
Disk model: WDC WDS100T2G0A-
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sdg: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 860 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 76628399-779F-47D5-BF40-91930ECC85C8


Disk /dev/sdh: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 860 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0A316DF5-1431-44D5-8328-16960E7206B5
linux raid mdadm software-raid

1 Answers

  1. If anyone is in the same situation as me, you could try this

    Shutdown the system, remove one of the two drives, and reboot.

    Reason for removing 1 of 2 drives in a raid 1 array? If you **** it up completely, you will have removed on device, thus hopefully you can try and alternative method with that drive instead of nuking both members of the mirror.

    sudo mdadm --create --verbose --force /dev/md0 --level=1 --raid-devices=1 /dev/sdg

    Here is why I think this worked.

    I remember that I created a mirror pair and I did not go through the steps of zeroing the drives/zeroing the (parition) superblocks before creating the array. I believe my mdadm.conf file and updating initramfs (sudo update-initramfs -u) prevented this pair of drives experiencing any issues with the system it was in. I suspect that either gparted or fsck (or maybe something else) detected an issue due to some confusion between gpt partition scheme and mdadm raid superblock, and whatever tool touched the drives overwrote the mdadm superblock with a gpt block of some kind.

    Anyway - I've had similar issues with another system which was triggered by rebooting that system, so I took a punt on the issue being similar. (It was.) Moving these drives to a new system caused the same problem.

    I don't exactly understand the cause, only the solution.

    I would recommend if you find yourself in this situation, create a new raid pair, zero the superblocks first and then go through the regular mdadm creation procedure. Then copy the data from the recovery mode (created using the line given above) to this new raid, and then verify the contents is the same, before trashing the contents of this "unstable array.

    To verify contents, do something like

    find . -type f -exec sha256sum {} \; | sort > ~/sums.txt
diff ~/sums1.txt ~/sums2.txt
    • 0