2

This is perhaps too specific/personal a question for S.O. but here it is:

I've inherited a server currently running a single hard drive, which through default Ubuntu 16.04 server setup, is running its disk in the following partition scheme:

sda1 : 512 Mb : Boot : primary/physical partition
sda2 : Rest of Disk : Extended Partition
sda5 : Rest of Disk : Logical, Linux LVM Partition

There is one volume group in the LVM, made from only this disk. It is divided into:

swap_1 (2.00 GB)
root (remaining space)

The final goal is to move this drive's contents (and structure) onto two, larger, individually bootable RAID1 drives.

That being said, my "goal" is for each new of the new sdb, sdc is to:

/dev/md0 is going to be a raid1 between sdb1 and sdc1, which will be formatted and (hopefully) a copy of sda1. Md0 will not be LVM'd but used directly (so we can boot from it)

/dev/md1 is going to be a raid1 between sdb2 and sdc2. /dev/md1 is going to be used as the only PV for a new VG, divided similarly to above (2GB for swap, and the rest for storage).

So, my hypothetical process involves booting into this system with a recovery CD, setting up md0 and md1, creating the LVM on md1, and copying the data using dd from sda1 to md0 and /dev/vg1/root to /dev/vg2/root, respectively. And of course, installing grub to /sdb and /sdc.

Initial tests are looking promising, but is there a better practice means of doing this?

Improve this question

1 Answer 1

Reset to default
0

There doesn't seem to be anything particularly wrong (or complicated) with what you're doing, though since you're using LVM you have another option: you can use pvmove to move the data to the new array. The advantage is you can do that online, almost eliminating downtime.

To use pvmove, you'd extend the existing volume group (pvcreate /dev/md1 && vgextend existing-group /dev/md1) then use pvmove to move the logical volumes (pvmove --atomic /dev/sda5 /dev/md1), and finally remove sda5 from the volume group (vgreduce existing-group /dev/sda5).

You can copy /boot online (with dd), because it's not used during normal operation—just unmount it first.

Either way, make sure to update your initramfs—it now needs to start mdraid, it didn't before.

Plan your next reboot and have a recovery disc handy just in case something went wrong (e.g., initramfs wasn't generated correctly). And of course testing & reading manpages first is a good idea.

Improve this answer
5
  • Thank you for the advice! My supervisor doesn't want to run the copy live (in case something goes wrong), so I'll probably be sticking to dd with a live disk. I'd completely forgotten about updating initramfs though, so good call there!
    – X14U2NVX
    Oct 12, 2016 at 16:22
  • @X14U2NVX Just remember an important thing about dd: it's way too easy to get if and of confused. Make sure to check thrice before hitting enter. (And of course, always have backups).
    – derobert
    Oct 12, 2016 at 16:39
  • Great advice! Do you think I should zero the rest of the drive (since my new md1 is considerably larger than sda(2/5)?
    – X14U2NVX
    Oct 12, 2016 at 17:01
  • @X14U2NVX no, no need to zero it, unless you need to erase old data on it (e.g., for security reasons). If its a new disk, it shipped zero'd anyway.
    – derobert
    Oct 12, 2016 at 17:03
  • ah, makes sense. Ah, one last thing. Had to update /etc/fstab (as I was copying over it and forgot it wasn't in /boot)
    – X14U2NVX
    Oct 12, 2016 at 17:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .