Okay, so, here's the situation. Motherboard on my old computer (a Shuttle) went out. Decided to get a new computer, because hey, it was four years old.
New computer came with two new SATA drives, which I've set up to to be mirrored with software raid -- partitions /dev/md0 and /dev/md1.
All is good.
Now, had the exact same disk configuration in my old system. If plug in those disks into the 3rd and 4th SATA ports, and boot, what will happen?
I hope the RAID autodetect system is smart enough to not get the old /dev/md{0,1} mixed up with the new one and eat data. Right?
What Will Happen?
Thanks!
Matthew Miller wrote:
Okay, so, here's the situation. Motherboard on my old computer (a Shuttle) went out. Decided to get a new computer, because hey, it was four years old.
New computer came with two new SATA drives, which I've set up to to be mirrored with software raid -- partitions /dev/md0 and /dev/md1.
All is good.
Now, had the exact same disk configuration in my old system. If plug in those disks into the 3rd and 4th SATA ports, and boot, what will happen?
I hope the RAID autodetect system is smart enough to not get the old /dev/md{0,1} mixed up with the new one and eat data. Right?
What Will Happen?
I think it will pick one of each of the mdN devices and ignore the other. It won't eat data unless the mismatched disks have matching UUIDs which is unlikely unless you image-copied them or had synced with the other set in the past. If you want it to ignore the new set until you reconfigure it, fdisk the partition types to something other than FD so it won't autodetect at boot up.
On Fri, Apr 04, 2008 at 11:54:55PM -0500, Les Mikesell wrote:
I think it will pick one of each of the mdN devices and ignore the other. It won't eat data unless the mismatched disks have matching UUIDs which is unlikely unless you image-copied them or had synced with the other set in the past. If you want it to ignore the new set until you reconfigure it, fdisk the partition types to something other than FD so it won't autodetect at boot up.
Okay, thanks. Any suggestions on how to reconfigure it to use higher numbers on the fly without losing data? I'd like the old md0/md1 to end up as md2/md3.
Matthew Miller wrote:
On Fri, Apr 04, 2008 at 11:54:55PM -0500, Les Mikesell wrote:
I think it will pick one of each of the mdN devices and ignore the other. It won't eat data unless the mismatched disks have matching UUIDs which is unlikely unless you image-copied them or had synced with the other set in the past. If you want it to ignore the new set until you reconfigure it, fdisk the partition types to something other than FD so it won't autodetect at boot up.
Okay, thanks. Any suggestions on how to reconfigure it to use higher numbers on the fly without losing data? I'd like the old md0/md1 to end up as md2/md3.
If you have a place to hold a backup you can mount one of the underlying partitions and rsync it somewhere for safekeeping. I've always rebuilt from scratch when moving mirrors but I think you can use mdadm --assemble or --create to put them together. A safe approach might be to use --create to make the new device but only specify one of the partitions with the other as --missing. Then if the new md device still has the data, you can mdadm --add the other partition, if it has a problem you can mount the other partition and copy it over. Even these operations are slightly dangerous, though since a disk error on either partition will break things.
On Fri, Apr 04, 2008 at 03:25:33PM -0400, Matthew Miller wrote:
Now, had the exact same disk configuration in my old system. If plug in those disks into the 3rd and 4th SATA ports, and boot, what will happen?
Okay, so, what happens is: the old (newly added to this system on drives now named sdc and sdd) partitions are ignored and can be made temporarily into /dev/md2 (and /dev/md3 using)
sudo /sbin/mdadm --assemble /dev/md2 --uuid=(the proper uuid)
and the uuid can be found with
sudo /sbin/mdadm --examine --scan
(Thanks for your answers, Les!)