LVM question
from Cenzorrll@lemmy.world to selfhosted@lemmy.world on 05 Jan 18:42
https://lemmy.world/post/41198029
from Cenzorrll@lemmy.world to selfhosted@lemmy.world on 05 Jan 18:42
https://lemmy.world/post/41198029
Hi all, I’m playing around with LVMs to expand data storage and I’m looking at what would be required to transfer those drives to another device, all the steps I can find require exporting the volume group and then importing on the other device. But what would be the case if your boot drive were to fail, and you needed to move the drives without being able to export the volume group. Can you just do an import with a new device, or are there other steps required to do so?
Secondly, is there a benefit to creating an LVM volume with a btrfs filesystem vs just letting btrfs handle it?
threaded - newest
@Cenzorrll For comparison of LVM with BTRFS there are several article available.
https://www.baeldung.com/linux/btrfs-lvm
https://fedoramagazine.org/choose-between-btrfs-and-lvm-ext4/
From personal experience, I have an encrypted software RAID1 with mdadm and BTRFS on top.
Is not LVM, but same direction.
Before implementing this, I made some tests.
Related to encryption, when RAID1 was implemented with BTRFS, the CPU load had been doubled, because every BTRFS disk has an encryption process.
With software RAID1, only one encryption process is there.
Like, btrfs on top of LVM versus btrfs? Well, the latter gives you access to LVM features. If you want to use lvmcache or something, you’d want it on LVM.
That’s kind of what I figured, my biggest concern at this point would be how difficult it is to move the lvm volume to a different device. It seems pretty straightforward if you have a working setup, but from what I’m seeing in my research is silence if your device (server, etc.) dies and you need to move those volumes to another. I’m finding guides on either recovering from corruption or lost metadata, or transferring from one working device to another. Nothing I can find about importing a fully functional lvm to a new device if it hasn’t been exported.
I’ll be able to do that later today, so I guess I’ll see what happens if I do. Better to try it out now when it isn’t critical.
LVM itself does not provide redundancy, that’s RAID. LVM is often used on top of a RAID device. If your boot drive fails, LVM itself won’t save you, RAID (software RAID 1 is really common for a boot drive) can.
LVM can be used to seamlessly move data between physical volumes. You can add a new PV to the VG and move extents between LVs. I’ve used it to love-migrate to a larger drive that way. Once the physical extents have been moved to the new PV, you can reduce the old PV and then remove the old disk.
I try keep my data drives and boot drives separate on my servers, I make sure I can rebuild the server relatively easily so no matter what happens I can get back up and running. In my research on LVMs I wasn’t seeing anything saying you could just move the drives to a new setup, that you had to export and import first. In the case of a suddenly dead boot drive, I wouldn’t be able to do that. I did see some steps for backing up an LVMs metadata and recovering from that, so I might be sure I do that at some point, but another user said that modern distros should be able to scan for LVMs without issue, which is not what I found in my quick test in my setup. So I’ll be checking that out in a more modern setup to double check.
From what I was reading, recovering from corrupted metadata is not something I want to do. I’d rather not use LVM if that’s what’s required if I can’t just move the drives to a new server, as nice as it would be to resize filesystems on a whim.
If personal anecdote is good for anything, I’ve been using LVM on top of software RAID on Linux for close to 20 years now without ever losing a volume. The last time I lost data was on ReiserFS 3. Like I said, LVM does not protect against drive failure itself. That’s why I use RAID underneath. I’ve got my OS disk to protect against failures like that. Also frequent and verified backups of my data files to make sure that is protected.
And yes, modern (still supported) distros can scan LVM PVs on boot without issue.
LVM Physical Volumes (PV) can be moved between Linux machines without issue (I’ve done that several times), it’s not like hardware RAID where you have to have the same controller on both machines. Nothing I’ve done has ever required LVM metatata export/import.
If you’re talking about just moving the physical volumes (as in the actual hard drives) as is to another computer they’re automatically scanned and ready to go in majority of modern distributions. No need to export/import anything. This is obviously assuming your boot drive isn’t a part of volume group and you have healthy drives at your hands. You can test this with any live-distribution, just boot from USB into a new operating system and verify your physical volumes/volume groups from that.
If you want to move the volume group to a new set of disks simplest way would be to add physical drive(s) to volume group and then removing the old drive(s) from it after data has been copied. Search for pvmove and vgreduce. This obviously requires a working system, if your data drive has already failed it’s a whole another circus.
I did not find just moving the drives to work. There were some other issues that I came across that might have a part to play in it, I made the lvm and filesystem on an RPI5 running OMV and moved it to a rock3c running OMV from an armbian install. Turns out there’s a pagefile size mismatch between the two that prevented mounting the btrfs filesystem. But I still wasn’t able to get the rock3c to recognize the VG or that there were new PVs attached without exporting first. So perhaps the armbian install isn’t modern enough to automatically recognize it.
I didn’t expect learning new things about btrfs to be the outcome of this little experiment, but I guess that’s just how things work.
I haven’t tested lvm on arm-based systems, but if it doesn’t automatically locate them you could try pvscan/vgscan/lvscan.