Full-disk encryption answers exactly one question: what happens when someone else has your laptop and you do not. That is a narrow promise, and it is a valuable one — a stolen machine, a laptop left in a taxi, a disk sent back under warranty, an old drive going in a skip. It is worth twenty minutes at install time, and it is worth understanding precisely what it does not do.
What this does not protect you from. A machine that is running or suspended is unlocked — the key is in RAM and the files are readable, so a laptop stolen from a desk while asleep is not protected. It does nothing against malware, since anything running as you can read everything you can. It does not protect files you send elsewhere. And it is not a backup: an encrypted disk that fails is exactly as lost as an unencrypted one. Encrypt the disk and keep backups, encrypted separately.
1. The easy path: do it at install
Every mainstream installer offers “encrypt the disk” as a checkbox, and taking it is by far the least effort. Encrypting a system that is already installed is possible and is a genuinely risky operation; if you have the option of reinstalling, take it.
What you get is LUKS: the partition is encrypted as a block device, and a header at the start holds your passphrase-protected key. Choose a passphrase you can type at a cold boot with no password manager available — four or five unrelated words beat a short complicated string, because you have to type it correctly before anything on the machine exists to help you.
lsblk -f # look for crypto_LUKS on the partition
sudo cryptsetup status /dev/mapper/<name>
sudo cryptsetup luksDump /dev/nvme0n1p3 | head -20Verify: lsblk -f shows crypto_LUKS on the partition holding your system, and luksDump reports Version: 2.
2. Encrypting an additional disk
luksFormat destroys everything on the target. There is no undo and no warning beyond a prompt you will be tempted to skim. Run lsblk and confirm the device name immediately before, exactly as with dd — and note that device names can change between boots, so a name you noted yesterday is not evidence today.
lsblk # confirm the target, twice
sudo cryptsetup luksFormat /dev/sdb1 # type YES in capitals
sudo cryptsetup open /dev/sdb1 data
sudo mkfs.ext4 /dev/mapper/data
sudo mkdir -p /srv/data && sudo mount /dev/mapper/data /srv/dataTo have it appear at boot, it needs two entries: /etc/crypttab to unlock the device and /etc/fstab to mount the result. Reference it by UUID, never by /dev/sdb1.
sudo blkid /dev/sdb1 # the LUKS UUID
# /etc/crypttab
data UUID=<luks-uuid> none luks,discard,nofail
# /etc/fstab
/dev/mapper/data /srv/data ext4 defaults,nofail 0 2nofail on both lines is what stops a missing or unopenable disk holding the boot — systemd turns fstab entries into units, and a failed one prevents the system reaching its normal target.
Verify: reboot. You should be prompted for the second passphrase, and findmnt /srv/data should show it mounted afterwards.
3. Back up the header — the step nobody knows about
Your passphrase does not decrypt the disk. The header does. The passphrase unlocks a key stored in a small header at the start of the partition, and if those few megabytes are damaged — by a misfired dd, a partitioning mistake, a bad update to the wrong device — the data is gone permanently, correct passphrase or not. Back the header up once, keep it somewhere other than the disk it came from, and treat that file as being at least as sensitive as the passphrase itself. It is a snapshot of the key slots as they were on the day you took it, which matters the moment you rotate: restore an old header and every passphrase you have retired since is live again, while the one you are currently using is not — luksHeaderRestore exits 0 and says nothing about either. Re-take the backup after every luksAddKey, luksChangeKey or luksKillSlot, and destroy the copy it replaces.
sudo cryptsetup luksHeaderBackup /dev/nvme0n1p3 \
--header-backup-file ~/luks-header-nvme0n1p3.img
sudo chmod 600 ~/luks-header-nvme0n1p3.img
# copy it to encrypted external storage, then delete the local copyA second passphrase is worth adding at the same time. LUKS holds several key slots, so a spare passphrase kept in a password manager on another device turns “I have forgotten it” from catastrophe into inconvenience.
sudo cryptsetup luksAddKey /dev/nvme0n1p3 # add a second passphrase
sudo cryptsetup luksDump /dev/nvme0n1p3 | grep -A2 Keyslots
sudo cryptsetup luksChangeKey /dev/nvme0n1p3 # change one
sudo cryptsetup luksKillSlot /dev/nvme0n1p3 1 # remove slot 1Verify: luksDump lists two key slots, and you have tested the new passphrase by unlocking with it — before deleting anything.
4. Automatic unlocking, and what it costs
Typing a passphrase at every boot gets old, and the machine has a TPM that can hold a key and release it only if the firmware and boot chain are unchanged. systemd-cryptenroll sets this up in one command.
sudo systemd-cryptenroll /dev/nvme0n1p3 \
--tpm2-device=auto --tpm2-pcrs=7 --tpm2-with-pin=yes
# then add tpm2-device=auto to that device's options in /etc/crypttabBe clear about the trade. With a TPM alone, a stolen laptop boots itself to a login screen with the disk already decrypted — your protection is now the login password, not the encryption. That is a reasonable posture against a casual thief and a poor one against anyone determined. --tpm2-with-pin=yes asks for a short PIN as well, which restores most of the benefit while still being quicker than a long passphrase.
The other consequence: PCR 7 covers Secure Boot state, so a firmware update, a BIOS setting change or a shim update can legitimately stop the TPM releasing the key. Keep a passphrase slot enrolled — it is what you will use on that morning.
Verify: reboot and confirm it unlocks without the full passphrase; then confirm the passphrase still works by using it deliberately once.
5. Disposing of a disk becomes trivial
This is an underrated benefit. Securely erasing an SSD by overwriting it does not reliably work — wear levelling means the drive may not overwrite the blocks you think it did. On an encrypted disk you do not need to: destroy the key slots and the remaining ciphertext is noise.
sudo cryptsetup luksErase /dev/sdb1 # wipes every key slot. Irreversible.Seconds rather than hours, and more thorough than overwriting. Make certain of the device name first; this has no more undo than luksFormat does.
6. The practical caveats
- Performance is a non-issue on modern hardware. Every current CPU has AES acceleration; the overhead is not something you will notice. Check with
cryptsetup benchmarkif you want the numbers. - TRIM needs the
discardoption to reach the SSD through the encryption layer. Without it the drive slowly loses performance; with it, the pattern of used and unused blocks is visible to someone examining the disk. Most people should enable it; if your threat model is serious, do not. - Hibernation writes RAM to swap — including the encryption key. If you hibernate, the swap must be encrypted too, or you have put the key on disk in plain text.
/bootis usually not encrypted, so someone with repeated physical access could tamper with the initramfs. Secure Boot with your own keys addresses this; for most people it is beyond the point of diminishing returns.- Suspend is not off. If encryption matters to you, shut the machine down rather than closing the lid.
Before you call it done
lsblk -fshowscrypto_LUKSon every partition holding real data- The header is backed up, off this machine, with restrictive permissions
- A second passphrase exists, and you have unlocked with it
- If you enrolled a TPM, a passphrase slot still works and you have tested it
- Backups exist and are encrypted separately — encryption is not a backup
- You know that suspend leaves the disk unlocked, and shut down when it matters
Related
- Disks and Mounting — lsblk, UUIDs and fstab, all used above
- dd — including why overwriting does not reliably erase an SSD
- How Linux Boots — where the unlock prompt comes from, and what the initramfs is
- Automated Backups — the thing encryption is not a substitute for
- Restoring a Linux Server — what a header backup does when you restore it, and the other things a file-level backup does not contain