I have a tar backup of a RAID-1, /dev/md0 (actually backing up from /). I would like to restore this to a physically different computer that also has RAID-1 configured. There is no doubt I can do the restore, my concern is whether there is anything in the RAID config (UUID?) that references the specific hard drives of the original machine. Note that the /etc/mdadm.conf of the source machine will also get restored to the target machine.

Will a restore to the target machine's / (/dev/md0) work without problem, or do I have to re --assemble, or something?

Apart from mdadm.conf, I don't think there is anything in your filesystem that references the array. The filesystem doesn't know that it exists on a RAID.

Each array member has two UUIDs in the RAID superblock: One UUID that identifies the array (i.e. all array members have the same array UUID), and one UUID that identifies the disk (i.e., each disk has its own). I am not sure if a wrong UUID in /etc/mdadm.conf causes a problem; to be certain, you could exclude mdadm.conf from the restore and recreate it later. Current versions of MDRAID work fine without mdadm.conf; you only need it for things like the notification mail address.

EDIT: My source for the statement in the last sentence is https://raid.wiki.kernel.org/index.p...ck_.282011.29:

1 members found this post helpful.

berndbausch: thanks for the feedback. I went ahead and tried restoring two different machine backups to the target computer and it worked just fine. The only annoyance was that the backup machines had /dev/md0 configured as boot and /dev/md1 configured as swap and on the target machine that was reverse. To fix that I edited /etc/fstab, /etc/lilo.conf and /etc/mdadm.conf and flipped the /dev/mdX values after the restore and reran lilo, and it booted without problem. In fact, on the 2nd machine restore I forgot to modify /etc/mdadm.conf and it still booted and did not appear to confuse mdadm.

In case you (or anyone) is wondering why I'm doing this, our internal auditor wanted us to routinely restore our Webserver and AD/DC servers from backup to verify the backups are good and can be restored. I created a VERIFY computer that will be used quarterly to restore these backup tarfiles and verify booting.

You just discovered that non-persistent storage device names can cause headaches. /dev/sda, /dev/md127, /dev/dm-0 and the like are not reliable names; external influences like adding or removing devices can change those names.

MD RAID has persistent names in the /dev/md directory. Persistent names for disks are found in the subdirectories of /dev/disk. They are based on device characteristics that won't change, are extremely unlikely to change, or are under the admin's control, like labels, UUIDs, PCI and SCSI addresses etc.