3

I need to move a server mdadm RAID1 setup on a new pair of bigger disks, from 2TB to 4TB. The disks are GPT with 4 partitions:

/dev/nvme1n1p1 /dev/md0 biosboot /dev/nvme1n1p2 /dev/md1 swap /dev/nvme1n1p3 /dev/md2 /boot /dev/nvme1n1p4 /dev/md3 / 

I also need to expand md1 a bit and md3 to fill the remaining space.

How should I proceed to mirror the data to the new disks without risking to lose anything?

Since the raid is created on the partitions, can I just recreate the partition with different sizes and add them to the array or they need to have the exact starting block of the old disk?

What I thought to do (I'm using the MD numbering here but I'm referring to the actual partition [ie. md0 is nvme2n1p1]):

  • Create the partitions on the new disks. Creating md0, md2 and md3 of the same size. md1 will be created initially with the new increased size so md2 and md3 will have different starting block. Then md1 will be deleted and recreated to have the same size as old drive. This leaves me in a state with all the partitions of the same old size but moved on the disk for later.

  • Add the new partitions, one new disk at time, to the old array. Failing one of the old drive I get to resync them to mirror the data.

  • Once both new disks are mirrored I fail\remove the old ones. So the array remains with only the new one.

  • Proceed to install grub on the new drives and update initramfs. Also check fstab for any issues.

  • Expand the mdadm raid size for md1 and md3. Then use the filesystem utils to resize them too (XFS).

  • Reboot and pray

Would it work?

The alternative is to recreate a completely new array on the new disks and rsync every partition.

10
  • You don't need a reboot for anything else that connecting or disconnecting devices. biosgrub parttions is also not supposed to be RAIDed (I've never seen it that way, at least). Also, better don't fail a device to force a sync, but reshape to have 3-way mirror RAID1 degraded to have 2 functional mirrors instead of having 2-way degraded mirror to one copy with working spare. That's definitely safer. Also better migrate to LVM setup. Finally, this topic was discussed here a few times; I am sure this is duplicate. Search. Commented Sep 19, 2024 at 5:10
  • See here: serverfault.com/questions/223194/… Commented Sep 19, 2024 at 5:12
  • I read every single question asked, but can't find an exact answer (either not using RAID1 like your link or just suggesting to make a new array and rsync). I didn't go for LVM because at that time I read somewhere the performance were worse than an md array? Even worse if using LVM on top of md. But I might be wrong. I didn't specify it, but there are also another 2 disks on the same server, in another RAID1 array to mount /var/lib/mysql only, which will not be touched. So i'd rather stick with the actual setup to not have to deal with 2 different implementation on the same server. Commented Sep 19, 2024 at 9:46
  • What I'm referring in my post is basically the first solution here unix.stackexchange.com/questions/665389/… I just need to know if there would be any issue in having the initial partitions on the new disks starting at different blocks. If there is no issue with that I think it's safe to just add the new partitions on the same array and then fail the old ones when the sync is completed. Also, what does reshape exactly means? Isn't it just using --grow --raid-devices=4 with the 2 new disks and then failing/removing the older ones? Commented Sep 19, 2024 at 9:48
  • A partition is a block device by itself in Linux, and MD considers that block device, it doesn't care it is a partition or whatever, it just uses a block device and lays its metadata as it would normally do. // LVM itself does't make performance any worse. The only thing that might be bad for performance in LVM is thick volume snapshots; just don't use it. Also LVM can be (and very often is) deployed on top of MD RAID; you aren't bound to use its own RAID functionality. Why I introduced it is that it makes you not worry about physical layout of your volumes. Just extend them and live happily. Commented Sep 19, 2024 at 9:58

0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.