[Nottingham] Growing a RAID 1

[J I]

Thanks, Andy.

I actually made the leap to BTRFS for the RAID, a couple of subvolumes and
it all went very smoothly.

Old (11.5 year old!) drives are out and I am now seriously considering
flipping the other server.

J.

On Wed, 25 Jan 2023 at 17:08, Andy Smith via Nottingham <
nottingham at mailman.lug.org.uk> wrote:

> Hi,
>
> On Tue, Jan 17, 2023 at 11:58:01PM +0000, J I via Nottingham wrote:
> > Can anyone point me at some instructions on how to do that?
>
> These will work (have done this myself many times):
>
>
> https://raid.wiki.kernel.org/index.php/Growing#Extending_an_existing_RAID_array
>
> So, being a bit more verbose on what steps are relevant to you:
>
> 1. Make sure you have backups. Growing MD RAID-1 is pretty well
>    tested but human error is a factor especially with tasks you are
>    unfamiliar with.
>
> 2. Go back to step 1 after not taking it seriously enough the first
>    time it was read.
>
> 3. Remove one of the devices from your RAID-1 by marking it failed.
>
>     # mdadm -f /dev/md0 /dev/sda
>
> 4. Physically remove sda from your computer and physically attach
>    the replacement. If you can do hot swap then lucky you, you get
>    to do all of this without switching your computer off. Otherwise
>    clearly you'll be shutting it down to remove each device and add
>    each new one. It should still boot fine and assemble the array
>    (degraded).
>
> 5. I'm going to assume you have power cycled in which case the drive
>    names may have changed. Your new drive will probably now be sda,
>    BUT IT MIGHT NOT BE, SO CHECK THAT SDA IS WHAT YOU EXPECT IT TO
>    BE. One other likely outcome is that your previous sdb is now sda
>    and the new drive is sdb. You can do "smartctl -i /dev/sda" to
>    get some vitals like model and serial number. If you had hotswap
>    and didn't power cycle, your new drive will likely be /dev/sdc.
>    It doesn't matter what it's called; just use the new name.
>
> 6. Partition your new drive how you want it. I see you have used the
>    entirety of the old drive as the MD RAID member but current best
>    practice is to create a single large partition rather than use
>    the bare drive. There are various reasons for this which I won't
>    go into at this stage. So let's assume you now have /dev/sda1, a
>    partition on your first new drive.
>
> 7. Add your new drive to the (currently degraded) array:
>
>     # mdadm --add /dev/md0 /dev/sda1
>
>    The array will now be resyncing onto the new drive, though it
>    will still be the same size. Check progress:
>
>     $ cat /proc/mdstat
>     $ watch -d cat /proc/mdstat
>
> 8. Once that's done, repeat steps (3) to (7) with sdb. You should
>    end up with a clean running array on both the new drives, but it
>    will still be the old (small) size.
>
> 9. Tell the kernel to grow the array to as big as it can go:
>
>     # mdadm --grow /dev/md0 --size=max
>
>    I've never had an issue with the bitmap stuff it mentions but if
>    concerned then you might want to do as it says.
>
>    After this your array should say it is the new size, though your
>    LVM setup will not know of that.
>
> 10. Resize the LVM PV so LVM knows you have more to allocate from:
>
>     # pvresize /dev/md0
>
> That should be it. At no point should you have had to reboot into a
> live environment or anything since the RAID should have continued
> working in degraded state up until the end of step (8). If you DID
> happen to encounter a hardware fault during the swap though, you
> could be in for a bad time, hence backups.
>
> If you somehow DO end up with a non-working system and have to boot
> into a live / rescue environment, don't panic. Most of them have
> full mdadm tools and kernel support so you should be able to fix
> things from them. If you hit a snag, ask on the linux-raid mailing
> list. Don't be tempted to experiment unless you know exactly what
> effect the various commands will have.
>
> I haven't discussed the bootloader implications since you said these
> are not your boot drives. The page does a reasonable job of that.
>
> > I have a feeling it's going to be more complicated than just
> > replacing the drives one at a time with a rebuild (and then some magic to
> > grow things to the full 4TB).
>
> That's really all it is.
>
> Note that you'll need a GPT partition table (not MBR) in order to
> have a partition of ~4TB. That will be fine.
>
> > Do I need to be overly concerned with /etc/fstab which seems to be using
> a
> > UUID:
> > /dev/disk/by-id/dm-uuid-LVM-47rf... /var/lib ext4 defaults 0 0
>
> This is a UUID to a device-mapper (LVM) device. Nothing will change
> as far as your LVM configuration is concerned so that UUID will
> remain the same.
>
> If you have other fstab entries you are concerned about, let us
> know.
>
> Cheers,
> Andy
>
> --
> https://bitfolk.com/ -- No-nonsense VPS hosting
>
> --
> Nottingham mailing list
> Nottingham at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/nottingham
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/nottingham/attachments/20230126/c042b402/attachment.htm>