In an earlier article, I had promised live migration of LVM data to encrypted storage. I was able to acquire an external SATA disk for my backup server today, so here we go. 🙂
The backup server is running headless, so I opted to store the key locally for now. Yes, I’m a moron. But hey, at least it’s not on the same medium.
# dd if=/dev/urandom of=/etc/luks.key count=256 ; chmod 600 /etc/luks.key
As long as the disk isn’t the only one, I can’t predict the device name it will come up as. Thus, it is referenced by its udev ID when formatting it with LUKS:
# cryptsetup luksFormat /dev/disk/by-id/scsi-SATA_WD_My_Book_WD-WCAU123-part1 /etc/luks.key
Open the new LUKS device:
# cryptsetup luksOpen -d /etc/luks.key /dev/disk/by-id/scsi-SATA_WD_My_Book_WD-WCAU123-part1 pv_crypt_1
The entry in /etc/crypttab makes the encrypted device come up on boot:
/etc/crypttab:
pv_crypt_1 /dev/disk/by-id/scsi-SATA_WD_My_Book_WD-WCAU123-part1 /etc/luks.key luks
Create a new Physical Volume on the crypted device:
# pvcreate /dev/mapper/pv_crypt_1
Now the Volume Group can be extended with the new PV:
# vgextend datavg /dev/mapper/pv_crypt_1
I rebooted at this point, in order to see if everything would come up as expected.
The new PV is now visible:
# pvs PV VG Fmt Attr PSize PFree /dev/dm-0 datavg lvm2 a- 931.51G 931.51G /dev/sdb1 datavg lvm2 a- 465.76G 0
The next step is to migrate the VG content to the new PV. Migration will take a very long time if the disk is full, so you may want to use a screen session for this.
# pvmove -v /dev/sdb1
This is a classical LVM operation that may be cancelled at any time and picked up later. In fact, my Promise SATA driver crashed hard in the middle of the operation, and everything went along fine after a kernel upgrade.
When pvmove is done, throw out the original PV from the volume group:
# vgreduce datavg /dev/sdb1
The Volume Group is now on encrypted storage.