So in hindsight, I realize that I made a mistake. I didn’t encrypt my drive during the installation process and naturally would like to do it now. Of course, without losing my data or various settings, etc etc etc.
Is that possible? Or is the option to encrypt only available pre-instalation?
IIRC, encryption is only available when formatting your drive.
What filesystem type did you select during install?
Did you create a separate /home?
I imagine you can, but you would need to image your current partitions, reformat and encrypt the disk and then restore the image you had on top of the new partition layout with encryption enabled, plus make all of the fixes for the OS to know what’s going on. Basically, you might as well just backup important configs and files and just reinstall, since doing it the manual way is more painful than straight up reinstalling.
You can also use fscrypt instead.
This way, you wouldn’t have to reformat, but it may mean that you have to change your workflow a bit since you would need to put files in a specific folder for them to be encrypted. Any files outside the folder would be unencrypted.
Check here: https://wiki.archlinux.org/title/Fscrypt
If one must use encryption this is a sane method, there’s no need to encrypt the system itself, just your data. This will result in better performance and less likelihood of an unbootable system. IE, ddnn has the best solution so far ;0
Adding to this, this is what I do, because I don’t want to run into that very situation where I can’t access anything at all.
Also, I said “folder”, but you can do this with multiple folders - not just one.
The key thing is that the folder needs to be brand new, you encrypt it, then place the files you want to protect in that folder. I have 4 folders that I encrypt, including my “Downloads” folder.
Also, it is important to keep a backup of the “encryption file” as a just in case (can’t remember the actual name - read the Wiki for the actual name).
AND, BIG AND, though it would be nice to decrypt the folders automatically on login - using your login password as the decryption password, in my opinion, you shouldn’t do this for two reasons:
Basically, make sure you have backups; even for encrypted files.
BTRFS partitions can be encrypted after installation. I converted my current EOS system earlier this year, leaving only the EFI partition (using systemd-boot). I believe I used this guide:
https://www.jamesgisele.com/blog/encrypting_existing/
It was fairly straight-forward. Obviously the same caveat of having good backups, but it worked and my system has been fine ever since. Certainly was way faster than moving all of my data back.
I going to take it back a step.
Your drive currently stores un-encrypted data. Even if you now employ encryption from now on, there’s still a potential risk, that the un-encrypted data that had been on it, could be retrieved later.
Some SSD’s have a great way of addressing this, by encrypting the data on the SSD (self-encrypting drive). The purpose of this is quite different to the disk encryption you’re discussing here, so bear with me.
It’s value is that you can cycle the encryption keys internally on the SSD, essentially securely wiping the drive. In simple terms, the data on the drive is encrypted, but you destroy the keys and change the locks.
If your SSD supports this, and many Samsung, Western Digital, Crucial and Kingston drives do, I’d suggest backing up all your data, performing that “secure wipe”, and re-installing with full disk encryption on what is now a completely clean slate.
This sounds like a good idea. I have a Samsung 970 Evo Plus; how do I do a wipe on the drive?
The hardware vendor implementations got a very bad reputation in the past. I remember the headlines.
Granted that was a while ago. Are they actually considered usable now? Overall it feels that OS implementations like LUKS are still the current standard.
Your UEFI/BIOS may have a “Secure Erase” feature, which interfaces with that feature on the SSD. Just make sure you backup anything important first 
Just to clarify, I was not suggesting the use of the self-encrypting drive feature of the SSD instead of LUKS, rather before using LUKS to essentially secure wipe the drive first. A process that basically throws away the encryption keys of the current data, rendering it inaccessible.
I agree that LUKS is the stronger option for full disk encryption.