Yeah, that’s the gist of it.
You can use any filesystem you like. I generally use btrfs for the OS partition, ext4 for the data partition(s). But it’s a matter of preference. You can use LUKS, just takes some extra steps. I have one data partition with LUKS, one without (mainly for Steam games… don’t care to encrypt, want max speed).
My setup looks something like this (lsblk output, modified for brevity):
NAME SIZE RO TYPE MOUNTPOINTS
nvme0n1 1.8T 0 disk
├─nvme0n1p1 2.9G 0 part /boot
├─nvme0n1p2 357.4G 0 part
│ └─luks-.... 357.3G 0 crypt /
├─nvme0n1p3 499.8G 0 part
│ └─luks-.... 499.8G 0 crypt /mnt/UserData
└─nvme0n1p4 1002.9G 0 part /mnt/FastData
If I want to reinstall, I just delete p2 and install into the empty space (“Replace Partition” option). Maybe also delete and recreate a fresh p1 prior to install. But p3 and p4 I leave untouched.
Just once, after (re)install, you’ll want to create the mount point directory(s), and ensure your desktop user owns them (otherwise, they’ll be owned by root when you mount, and you’ll have permission issues). I put them in /mnt but that’s a matter of preference, e.g.:
sudo mkdir /mnt/UserData
sudo chown 1000:1000 /mnt/UserData
You’ll need to know the UUIDs of the partitions you want to mount. lsblk -f will tell you.
Then you’ll want to add them to your /etc/fstab, to auto mount on boot. Without LUKS, this is all you need:
UUID=... /mnt/FastData ext4 defaults,nofail 0 2
With LUKS, you first need to generate a keyfile and add it as a valid key to the partition, so it can be used to unlock it. This is persistent; no need to ever do it more than once for as long as the partition exists. Just keep the file somewhere safe:
sudo dd if=/dev/urandom of=crypt.keyfile bs=1024 count=4
sudo chmod 0400 crypt.keyfile
sudo cryptsetup luksAddKey /dev/nvme0n1p3 crypt.keyfile
You can still use your passphrase to unlock the partition. This just adds the keyfile as an alternative. I’d encourage looking into this some more (you’ll need to, to learn how to manually create a LUKS partition, anyway) and practicing on a dummy partition or VM, to gain confidence.
Then you need an entry to /etc/crypttab, to use that keyfile to auto unlock it on boot:
luks-UU-I-D UUID=UU-I-D /path/to/crypt.keyfile
“UU-I-D” should be the UUID of the partition, not the luks volume inside it.
The keyfile can live anywhere, but must be available at the time the unlocking would happen. So, in practice, you probably want it somewhere on your encrypted root partition (which you’ll have already unlocked with your passphrase by that point). But the keyfile should be owned by root and have 0400 permissions. You don’t want your desktop user (or anyone but root) to be able to read its contents.
Finally, the /etc/fstab entry looks a bit different from the unencrypted one:
/dev/mapper/luks-UU-I-D /mnt/UserData ext4 defaults,nofail 0 2
The first column matches the first column of crypttab, but with /dev/mapper/ prefix.
If you want certain subdirectories of home (like Downloads) to map to subdirectories of your data partition(s), you’ll want to also add bind mount entries to fstab. Or you can just use the already mounted locations directly, and configure applications to point there. I wouldn’t recommend symlinks, not all applications handle them correctly for directories.
See also: Automount Additional Drives Through fstab at Boot | CachyOS
This is the first time I hear about this concept, but it makes so much sense.
Back in the olden days, the common wisdom was to make /home a separate partition, and keep it, replacing only the / partition when reinstalling or distro-hopping.
But the problem with that is that /home is full of system specific configs and the like, which do not transfer well. And distros like to put some of their own stuff in /home. So you inevitably wind up with a mangled and broken home, full of mismatched configs and potentially failing to boot.
This approach is basically an evolution of that; surrendering /home to the system, and building the user’s true home somewhere else.