Pros and cons of encrypted LVM

I encrypt all of my drives but especially SSDs.

The reason I started was I had some hard drives with intermittent failures. These failed in such a way that a lengthy scrub was not possible but reading some files was. Using LUKS, I don't need to worry about scrubbing a failing or failed drive.

I also like that on my laptop, my data is secure even if I lose it or it is stolen.

Add to that, there is no real way to delete data on an SSD except using a manufacturer's delete command. Meaning if you have a sensitive file and delete it, it might still be available given the right tools. But not if you use LUKS.

The down sides? Having to enter a password on boot isn't a big deal to me. The performance impact is also pretty minimal. I'm sure you can find some benchmarks.

I use BTRFS on LUKS on my desktop & my laptop the latter of which is an X220 with an i5 and 8GB of RAM, 512GB SSD and find Debain and Gnome to run great.

The pros are you won’t be able to read the data without the decryption key. The cons are you won’t be able to read the data without the decryption key.

But seriously: do this as a matter of routine. You won’t notice a performance impact.

I've always used LUKS on LVM with SSDs and the performance hit is pretty negligible compared to the gap that is HDD -> SSD.

Do it. SSDs fail catastrophically and that means you get no notice. Backups are paramount but what's more paramount is what jpodster said - the data's encrypted at rest.

Rebooting requires a second password, but OH NO. YOU REBOOT SO OFTEN UNDER LINUX. :)

Ok, I'm running encryption on my entire root disk, booting from an USB drive. USB drive has the boot partition and the keys for the root partition. Took me a while to set all that up.

Pros- I yank the USB drive, and my data is secure and pretty much uncrackable, no way to run jack the ripper and guess the password. EDIT. And I'm using pure dm-crypt, not LUKS, so not even headers remain on the hard drive- it just looks like random rubbish.

Cons- I have to enter a password every time I boot.

Another con- some performance hit. I mean I have a NVMe SSD, which should peak at 3 GB/s. For me it peaks at 1 GB/s because data needs to be encrypted/decrypted, and this is with a fairly beefy CPU (AMD 3700X). CPU usage on heavy disk reads/writes is also noticeable, but I have many cores so using up some of that doesn't cause me pain. If you have SATA drives (even SSDs), you won't notice that as they top out at 500 MB/s, so your CPU will encrypt/decrypt faster than they can transfer data anyway. For me- 1 GB/s is plenty, so I'll keep using encryption.

I do encryption just as prophylaxis. I mean it's unlikely my data is going to be physically stolen. But it is good to be prepared and learn to do these things, and it's important more people do this and the tools for it are polished and troubleshooted properly.

not really any secret data or anything, just lots of personal information and documents

The term you're looking for is "sensitive" or "personally identifiable" information. Just for reference, most orgs encrypt this sort of information, including data at rest (full disk encryption) to keep it from being leaked.

My general rule is whenever feasible, use full disk encryption. I've been doing it for as long as it was an install option for Debian, so hardware doesn't really matter. For me, this includes my clients (home development machine, portable) and home file/backup server. Only exceptions are things I need to come up without input, eg, mail and web servers.

Con: Forgetting how to unlock your data.

Way too many upsides and I've been generally unable to detect the downsides.

Encryption is pretty important. I try to encrypt any device I use.

IIRC my procedure for Debian is a non encrypted boot partition and an encrypted everything else partition. The encrypted partition gets used by LVM and split up into whatever I need; requires boottime password.