0

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
user3728501
  • 231
  • 1
  • 3
  • 10
  • 1
    Your disks have a GPT partition table. You should look at it. – Michael Hampton Oct 25 '20 at 20:49
  • @MichaelHampton Ok - what should I do with it? Print the details? It's a bit confusing because looking at it with gparted suggests the disk is "unallocated" - aka no partition etc. So what tools should I use and what am I aiming to do? – user3728501 Oct 25 '20 at 20:50
  • Try a different tool? Like a modern version of fdisk? – Michael Hampton Oct 25 '20 at 20:52
  • Sure, if I run fdisk -L it prints info suggesting there is a gpt table on there, hang on a sec if I can ssh to the machine I will show you the output – user3728501 Oct 25 '20 at 20:57
  • It looks like you mistakenly created a GPT signature on your disks, which deleted the md superblock. Probably when opening gparted? – wazoox Oct 25 '20 at 21:14
  • @wazoox Is `gparted` likely to do something like that. I agree it is the most likely explanation, but seems a bit "dodgy" for gparted to be writing to disks and trashing raid information. Still, is there a way to recover it? I suspect, from previous experience, simply re-creating the array *might* work... but it also *might not* and I don't want to take any risks you see. – user3728501 Oct 25 '20 at 21:17
  • You already took the risk! And it looks like you lost. You may find some useful information by searching for something like mdraid superblock recovery, but you should be prepared to restore from your backups. – Michael Hampton Oct 25 '20 at 21:27
  • What does `file -s /dev/sdh` report? – wazoox Oct 26 '20 at 22:08

1 Answers1

0

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
user3728501
  • 231
  • 1
  • 3
  • 10