On Wed, Sep 27, 2023 at 11:58 AM Zdenek Kabelac <zdenek.kabe...@gmail.com> wrote: > > Dne 27. 09. 23 v 1:10 Jean-Marc Saffroy napsal(a): > > Hi, > > > > On Tue, Sep 26, 2023 at 10:00 PM Zdenek Kabelac > > <zdenek.kabe...@gmail.com> wrote: > >> Yep typical usage is to encrypt underlying PV - and then create LVs and its > >> snapshots on encrypted device. > > > > Sure, I'd do that in other circumstances. > > > > But in my case it would just be a waste: I am replacing several disks > > on a desktop computer with a single 2TB NVME SSD for everything. Only > > /home needs to be encrypted, and it's tiny, like 100-200GB. Going > > through encryption for most application I/Os would use CPU time and > > increase latency with no benefit. > > > > So I prefer to manage available raw (un-encrypted) space with LVM. > > > > Now, I also need to do backups of /home, and that's why I want > > snapshots. But that first layer of LVM would only show a snapshot of > > an encrypted volume, and the backup job shouldn't have the passphrase > > to decrypt the volume. > > > > Which is why I'm trying to find a way of doing snaphots of an "opened" > > LUKS volume: this way, the backup job can do its job without requiring > > a passphrase. > > well that's where you will considerably 'complicate' your life :) > As you would need to 'orchestrace' this yourself with 'dmsetup' usage.
If you mean that I'd have to script a few things, then I am perfectly fine with that. > running 'dmsetup suspend' on your home device, > that taking a snapshot of your underlying LV. What is the role of "dmsetup suspend"? I am having trouble finding decent documentation about its purpose and how it's related to snapshots. I did not need it in my experiments, so I am curious. > Here the usage of 'thin-pool' would possibly help a little bit - as you get a > control over when a snapshot LV appears in your system. > > Once you have the snapshot created you 'resume' the top-level > decrypted volume. > > Then if you want to access your snapshot - you create another 'crypto' device > - unlock it again with your key - and it should work. At boot time (or login time, same thing), I need to give the passphrase to open the LUKS device, but after that, backup jobs run in the background, they are not interactive. If I were okay with giving the passphrase to my backup script, then I could simply have the backup script create its snapshot from the encrypted LV, and I wouldn't have started this thread in this case. :-) > But the level of complexity here is rather high - this it might be actually > way easier to just 'partition' your device for 'encrypted' and unecrypted' > parts and use 2 PVs for 2 VGs.... But then I can't resize the encrypted volume/partition. > > Just the one /home in my case, so no worse than prompting for the > > passphrase for an entire disk. > > Every access to a snapshot needs then a new separate 'unlock'.. Not with the approaches I suggested, as they work to build the snapshots on top of the "open", decrypted device. It seems LVM cannot do it directly, but it becomes possible (at least in my simple tests) if I use a bunch of dmsetup commands, or if I use the decrypted device as the PV for a new VG. But I don't know if these approaches are safe to use, and that is what drove me here. In the mean time, I found this page: https://access.redhat.com/articles/2106521 Apparently, LVM on LUKS on LVM would be case of "LVM recursion", and so not entirely unheard of. Does anyone here have experience with "LVM recursion"? Cheers, JM _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
