Arch Linux

hacosta

Member

From: Mexico

Registered: 2006-10-22

Posts: 423

Help recovering a raid1 md array using mdadm.

Hello,

I was trying to convert a 2 disk raid1 into a 4 disk raid1+0 and now I'm in a bit of trouble. My 8 GB raid1 array (with important data) looked as follows:

/dev/md0:
           Version : 1.2
     Creation Time : Tue Apr  7 18:52:00 2020
        Raid Level : raid1
        Array Size : 7813795776 (7451.82 GiB 8001.33 GB)
     Used Dev Size : 7813795776 (7451.82 GiB 8001.33 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Fri Oct  9 17:20:15 2020
             State : clean
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : gordita:0  (local to host gordita)
              UUID : d3b4f790:22162651:47cae43c:1ee5165b
            Events : 38866

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sdc1
       1       8       17        1      active sync   /dev/sdb1

I then created a new array using:

# mdadm --create --verbose /dev/md1 --level=1 --raid-devices=2 /dev/sda1 /dev/sde1

And tried creating a raid0 array out of md0 and md1 using

# mdadm --create --verbose /dev/md2 --level=0 --raid-devices=2 /dev/md0 /dev/md1
mdadm: chunk size defaults to 512K
mdadm: Defaulting to version 1.2 metadata
mdadm: RUN_ARRAY failed: Unknown error 524

That command failed but it altered the metadata on /dev/md0 and now trying to mount md0 results in:

# mount /dev/md0 /data
mount: /data: unknown filesystem type 'linux_raid_member'.
# mount -t xfs /dev/md0 /data
mount: /data: mount(2) system call failed: Structure needs cleaning.

Is there a way to recover the data in md0?

frostschutz

Member

Registered: 2013-11-15

Posts: 1,652

Re: Help recovering a raid1 md array using mdadm.

That's not how you convert a RAID. For converting you'd need mdadm --grow.

mdadm --create --verbose /dev/md2 --level=0 --raid-devices=2 /dev/md0 /dev/md1

This command creates a new RAID /dev/md2, formatting /dev/md0 and /dev/md1 in the process. mdadm --create does not preserve data. It's like mkfs, it gives a shiny new RAID.

So you simply formatted over your filesystem with another layer of RAID.

Now, thankfully, mdadm metadata is tiny compared to a lot of other things out there, and the RAID level you chose also did not cause a further damage (resync etc.), and for some lucky reason the array failed to run, so presumably you didn't write anything else either.

If those assumption are all correct, then the "damage done" in this particular case should be a single overwritten sector (~512 bytes at offset 4096 bytes for mdadm metadata version 1.2).

The problem is that trying to re-create your situation, the `mount -t xfs` worked for me. So you might have suffered more damage after all.

You can get rid of mdadm metadata using `mdadm --zero-superblock`. Then I guess you can try your luck with `xfs_repair`. You should do all these on a copy of the data, or use a copy-on-write overlay https://raid.wiki.kernel.org/index.php/ … erlay_file

If the filesystem is too badly damaged to be repaired, you can try your luck with `photorec` instead. But this is a last resort only and will only recover unfragmented files of a known type.