What an awful idea to encrypt data on an hardware accelerator SSD is everything but an affordable storage for keeping safely your data
and as soon some cells will fail , and with LVM , the first ones will be where LVM tables are sitting (and being heavily modified) .. you'll loose ALL the data, because of the extents mechanism Nevertheless, if you got damaged just the cells where encryption keys are written, again you loose everything Remember that the data must seat on the affordable hard disk drive. SSD is just an hardware accelerator, if of high quality (enterprise class) it can be good as cache for RAID systems Man that has been advised, is half saved Kind regards R. Ottieni BlueMail per Android Il giorno 27 set 2023, 11:58, alle ore 11:58, Zdenek Kabelac <zdenek.kabe...@gmail.com> ha scritto: >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. > >running 'dmsetup suspend' on your home device, >that taking a snapshot of your underlying LV. > >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. > >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 my tests don't tell me if there are other people doing similar >> things on production systems, or if they are happy with the results. >> Unusual setups tend to exhibit unusual bugs, and I am not super fond >> of bugs in my storage systems. :-) > >Yep - people prefer simple rock solid solutions.... >That's why the above describe scenarios is not really used.... >As solving then all individual errors that may appear is far from being >simple. > > >> 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'.. > >>> Speaking about snapshots - you should consider switching to >'thin-pools' for >>> far better performance... >> >> I only need snapshots for backups: once a day, create a snapshot, >> mount it, do a file-level incremental backup, unmount it, delete it. >> >> Would the thin-pools make a difference in this case? > >Well there are many ways how to skin a cat... >I.e. check blk-archive https://github.com/jthornber/blk-archive > >Regards > >Zdenek > >_______________________________________________ >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/
_______________________________________________ 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/
