Disk Crypto and Backups: VeraCrypt, LUKS and a Resilient 3-2-1 Strategy

A laptop stolen on a train, a seized hard drive, a ransomware that encrypts every network share at 03:12: three scenarios, one question. Can someone reach your data, and can you yourself get it back after a total loss? Disk crypto and a resilient 3-2-1 backup strategy are two sides of the same coin: confidentiality against theft, availability against loss. This post shows concretely how to encrypt with LUKS and VeraCrypt, how to actually manage keys, and how to build backups so that neither a thief nor ransomware nor your own fumble can ruin you.

The threat model first

Encryption without a threat model is crypto theater. Full-disk encryption protects data at rest: stolen or seized hardware in a powered-off state. It does not protect the running system where the key sits in RAM, not against malware with root, not against a cold-boot attack on an unlocked device, and not against coercion when someone forces the passphrase out of you. So define clearly whom you defend against, the way we derive it in OPSEC for Security Researchers: Building a Personal Threat Model. The model dictates the choice: is standard LUKS enough, do you need hidden volumes, do you need strict isolation like in Tails, Whonix or Qubes OS: Which to Pick for Each OPSEC Scenario. A common confusion is mixing up confidentiality and availability: encryption alone rescues no data lost to a dead disk, an accidental delete, or ransomware. Conversely a perfect backup with no encryption does nothing to stop a thief from reading the copy. Only both axes together make an honest defense, so note per scenario which of the two goals is under threat and size the measure accordingly instead of reflexively applying one solution everywhere.

Setting up LUKS on Linux properly

On Linux, LUKS2 is the standard. At creation, key derivation is what matters: cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --key-size 512 --pbkdf argon2id /dev/nvme0n1p3. Argon2id is memory-hard and slows brute force massively, unlike the older PBKDF2. Verify with cryptsetup luksDump that argon2id and a sane memory cost are actually active. LUKS offers eight keyslots: use one for the passphrase, one for a keyfile in a safe, one as an emergency recovery you keep offline. Rotate compromised slots with luksKillSlot. For servers, combine LUKS with boot hygiene and least privilege as in Linux Server Hardening: Applying CIS Benchmark Without Breaking Production, otherwise the encrypted disk protects a leaky running system.

VeraCrypt, hidden volumes and plausible deniability

VeraCrypt shines cross-platform (Windows, macOS, Linux) and with containers instead of whole partitions. A .hc container is a file mounted as an encrypted volume, ideal for portable, sensitive datasets. The killer feature is the hidden volume: inside an outer volume sits a second one whose existence cannot be cryptographically proven. Under coercion you reveal the outer volume's passphrase, holding plausible decoy data, while the hidden volume stays invisible. That is powerful but error-prone: write too much to the outer volume and you overwrite the hidden one. VeraCrypt is also deliberately slow at derivation (high iteration count), making brute force expensive. Choose a long, high-entropy passphrase, because no iteration count saves a weak password.

Key management that holds

The key is the real attack surface, not the algorithm. A passphrase of six random Diceware words beats any clever but short password. Separate knowledge and possession: passphrase in your head plus a keyfile on a YubiKey or an offline stick. For unattended server unlock, bind the key to a TPM with a PCR policy so the disk only boots if the firmware measurement chain is unchanged; Clevis and systemd-cryptenroll automate this. Keep a recovery key physically separate and offline. The same coercion-resistant thinking, including duress mechanisms, is deepened in Personal Crypto: Hardware Wallets, Passphrase and Coercion-Resistant Backup. Remember: a lost key with no recovery means guaranteed data loss, a leaked key means guaranteed compromise.

The 3-2-1 rule and its extension

The 3-2-1 rule is the core of any resilient strategy: three copies of your data, on two different media types, with one off site. Concretely: the live data, a local backup on a different disk or a NAS, and a geographically separate copy in an encrypted cloud or offsite target. The modern extension is 3-2-1-1-0: the extra one stands for an offline or immutable copy, the zero for zero errors in verified restores. That one offline copy is precisely the difference between surviving and sinking when ransomware encrypts every reachable drive. A backup the ransomware can encrypt too is not a backup, it is a second hostage.

Encrypting backups with restic and borg

Backup software must encrypt client-side before the data leaves the device. restic and BorgBackup do exactly that: deduplication plus encryption, so the target (S3, a foreign server, an external disk) only ever sees ciphertext. With restic you create a repo with restic init, back up with restic backup /data, and prune with a retention policy like --keep-daily 7 --keep-weekly 4 --keep-monthly 12. The repo key is never uploaded to the provider, which is decisive when the offsite target is untrusted. Borg offers the same with borg init --encryption=repokey-blake2. Both let you treat the backup target as potentially hostile, the only sane default for offsite copies.

Immutable and offline backups against ransomware

The decisive question with ransomware is: can the compromised host destroy its own backups? If yes, you have none. Make at least one copy immutable or physically offline. In the cloud you use S3 Object Lock in compliance mode or Backblaze B2 immutability, so even stolen credentials cannot delete objects before the retention window expires. Locally, rotate two external disks with one always in the cupboard, physically disconnected. Add append-only repos (restic over a rest-server with --append-only) so a compromised client can write but not delete. Detect unusual mass deletions or encryption waves early with detection in the style of Threat Hunting with Sigma and Elastic: From Indicator to Detection Rule.

Restore tests, or you have no backup

A backup that has never been restored is a hope, not a backup. Schedule regular restore drills: restore a random file, then a whole folder, then a full system in a VM and compare hashes. With restic you check repo integrity via restic check --read-data-subset=10% and rehearse the real restore with restic restore latest --target /restore-test. Document the restore time (RTO) and the maximum tolerable data loss (RPO) so nobody has to guess in a real event. The zero in 3-2-1-1-0 stands exactly for this: zero errors in a verified restore. Without that test you discover the broken backup on the very night you need it.

Common mistakes

Five traps show up again and again. First: a weak passphrase on strong crypto, which nullifies the whole effort. Second: the key sits next to the data, like a keyfile on the same unencrypted partition. Third: backups in the same trust boundary, so an attacker with access wipes them too. Fourth: never-tested restores that fail in a real event on a forgotten password or a corrupt repo. Fifth: carelessly filling the outer VeraCrypt volume and overwriting the hidden one. Each of these traps turns a seemingly secure strategy into an illusion. The good news: all five are avoided with discipline rather than expensive technology.

Practical checklist

First: LUKS2 with argon2id, verified via luksDump. Second: a passphrase of at least six Diceware words, separated from a keyfile you possess. Third: sensitive transport data in VeraCrypt containers, with a hidden volume when coercion is a risk. Fourth: honor 3-2-1, extended to 3-2-1-1-0 with an offline or immutable copy. Fifth: encrypt backups client-side with restic or borg, treat the target as hostile. Sixth: Object Lock or append-only against ransomware. Seventh: set a retention policy and prune. Eighth: a monthly restore drill with hash comparison, RTO and RPO documented. Ninth: keep the recovery key offline and physically separate. Live these nine and you survive theft, seizure and ransomware alike.

FAQ

Is full-disk encryption alone enough? No. It only protects data at rest. A running, unlocked system, malware with root, or an open laptop with the key in RAM are not covered. Combine disk crypto with system hardening, a short auto-lock timeout, and encrypted, separated backups.

Cloud backup or my own offsite copy? Both are legitimate as long as you encrypt client-side and the key never reaches the provider. The cloud gives you easy geo-separation and immutability via Object Lock; a rotated external disk in another building gives you full control. The ideal is combining both.

Conclusion

Disk crypto and backups solve two different, equally important problems: nobody reads your data, and you never lose it. LUKS2 with argon2id and VeraCrypt with hidden volumes cover confidentiality; an honestly lived 3-2-1-1-0 strategy with client-side encryption and at least one immutable offline copy covers availability. Practical takeaway: encrypt the first disk today, set up the first restic repo with an offsite target today, and do the first real restore test this week. Security you have never rehearsed is just a rumor about your own resilience.