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.
Il giorno 27 set 2023, alle ore 11:58, Zdenek Kabelac < zdenek.kabelac@xxxxxxxxx> 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.kabelac@xxxxxxxxx> 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@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
|
