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

Losing an encrypted machine is annoying. Losing the encrypted backup of the encrypted machine ends the project. The gap between those two outcomes is usually a two-column spreadsheet: where the key lives today and who has actually tried to restore from it. At Basilisk OffSec we run quarterly wipe-and-restore drills on our research workstations, and almost every iteration surfaces a forgotten detail: LUKS header with no backup, passphrase drift between vaults, a Restic snapshot pointing at a bucket that was already rotated. Disk encryption and backup are not separate topics; they are the same gear turning in opposite directions.

On Linux, LUKS2 with Argon2id is still the default pick in 2026. Use `cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 1048576 --pbkdf-parallel 4 /dev/nvme0n1p3` for an aggressive KDF cost on modern hardware, and never skip `cryptsetup luksHeaderBackup` to a 16 MiB file stored on a separate physical medium. That file is what separates a usable encrypted disk from a random brick if sector zero of the partition corrupts. We pair it with TPM2 sealing via `systemd-cryptenroll` for passwordless boot on trusted stations, while keeping a recovery slot with a 6-word Diceware passphrase. More on this layered defense logic in Linux Server Hardening: Applying CIS Benchmark Without Breaking Production.

VeraCrypt enters the picture when we need portable containers or plausible deniability. A 50 GiB `.hc` file with a hidden volume is still the lowest-profile way to carry engagement evidence through an airport, as long as you understand that plausible deniability only works if your counterpart accepts the premise. For full disks on Windows we prefer BitLocker with TPM plus PIN, and VeraCrypt only for secondary partitions or USB sticks shared between Linux and Windows. We document each choice as part of our personal OPSEC process, connected in OPSEC for Security Researchers: Building a Personal Threat Model and in the OS choice discussion in Tails, Whonix or Qubes OS: Which to Pick for Each OPSEC Scenario.

The classic 3-2-1 strategy reads as three copies, two different media, one offsite. In 2026 we run a 3-2-1-1-0: the fourth copy is immutable (S3 Object Lock or Backblaze B2 with a hold), and the zero means zero errors in the latest verification. Our pipeline uses Restic with an AES-256 encrypted repo, daily snapshots to a Synology NAS in the rack, weekly replication to a USB HDD living in an off-site safe, and monthly replication to Backblaze B2 with seven-year retention and Object Lock governance. The Restic key is generated with 256 bits of entropy, split via SLIP39 into 3-of-5 shards and distributed between a physical safe, a hardware wallet, and a trusted lawyer, a process similar to the one in Personal Crypto: Hardware Wallets, Passphrase and Coercion-Resistant Backup.

Encrypting is not enough: a backup that has not been tested does not exist. Every first Friday of the month we tear down a research VM, rebuild it from scratch using the latest Restic snapshot, and stopwatch the time until the environment is usable. RTO target: 90 minutes for a pentest workstation with custom tooling. To validate integrity we run `restic check --read-data-subset=10%` weekly and a full `restic check --read-data` every quarter. Logs ship to our internal Elastic and get correlated with simple Sigma rules, an idea we expand on in Threat Hunting with Sigma and Elastic: From Indicator to Detection Rule. If a check fails, we open a ticket the same way we would for a production IOC.

Watch out for the anti-patterns we keep seeing in consulting work: LUKS header backup stored inside the very disk it protects; Restic key in plaintext under `~/.config`; Time Machine snapshot pointing at a NAS without at-rest encryption; replication to a personal Google Drive treated as offsite. Each one has been a real postmortem on a client engagement. The rule of thumb: if you cannot whiteboard the full key chain from plaintext to the coldest medium, and name who has physical access to every link, your threat model is leaking.

To close with something actionable: block two hours this weekend, run `cryptsetup luksHeaderBackup` against every encrypted disk you maintain, generate a fresh Diceware passphrase, and store the header on an encrypted USB stick kept at a different address. Then run a test restore of your latest backup into a throwaway VM and measure how long it took. If you could not restore or it took more than two hours, you do not have a backup, you have hope. Crypto and backup hygiene is exactly the kind of quiet work that decides whether an incident ends as a funny anecdote in the retro or as a labor lawsuit.