How to NOT lose your backup encryption key

Encrypted backups are mandatory — putting unencrypted backups in a cloud bucket is a privacy incident waiting to happen — but they introduce a new failure mode: losing the encryption key means losing the backups. There's no recovery path, no "I forgot my password" button. The provider can't help you; the tool can't help you. The data is mathematically inaccessible.

This article covers the playbook for not letting that happen. Treat it as more important than the backups themselves: you can re-take backups; you can't re-derive a lost key.

The failure modes

1. Single-location key, single human knows it. The person quits / forgets / dies. Backups are now encrypted bytes nobody can read.
2. Key stored on the box being backed up. Box dies → key dies with it. Backups exist off-host, can't be decrypted.
3. Key in a password manager that nobody else has access to. Same as #1 with extra steps.
4. Key derived from a memorable passphrase that turns out not to be that memorable. Six months later you can't reproduce it. Equivalent to #1.
5. Key written down once, never re-verified. Paper backup exists but the actual characters are unreadable / contain a transcription error. Discovered during the actual disaster.

All five have one shared property: the failure isn't visible until you try to restore. The drill that catches all of them is the same: do a test restore from off-host backup, on a clean machine, using only the key material in your designated recovery location. If you can't restore, the key is effectively lost. Fix that now, while the box you'd restore from still exists.

The three-copies rule

For each backup-encryption key, store it in three places, each of which an authorized recoverer can reach independently:

1. Primary password manager. 1Password, Bitwarden, Vaultwarden — the daily-driver vault. Tagged so anyone with vault access can find "BACKUP KEY for <system>".
2. Secondary password manager owned by a different person. Your co-founder, your spouse, your business partner. Different account, different 2FA. If you're a one-person operation, this can be a printed copy in a safe deposit box; the point is independence from #1.
3. Printed paper copy in a sealed envelope, kept somewhere physical (home safe, office safe, lawyer's office). Use a typeface that doesn't confuse 0/O, 1/l/I — typeset, don't handwrite, and include a checksum if the key supports one.

A passphrase recoverable from any one of those three survives most realistic disasters. Concentrating on any one of them is how keys go missing.

Generate keys that survive transcription

Long random hex strings transcribe badly. Long random word lists (Diceware) transcribe well — they're memorable to a human and unambiguous when written.

# Diceware-style passphrase via pwgen (6 words, ~77 bits entropy)
shuf -n 6 /usr/share/dict/words | tr '\n' ' '

Six words from a 40k-word dictionary is more entropy than you'd get from a 12-char hex string and immensely easier to write down and re-type.

If your backup tool requires a specific format (32-char hex, base64-encoded keyfile), generate that AND a Diceware unlock for the keyfile, then store the unlocked keyfile + the unlock passphrase in the three copies above.

Restic + borg specifics

Restic and borg both default to passphrase-encrypted repositories. The passphrase derives a key; if you lose the passphrase, the key is gone too. Both also support keyfile mode (a binary key independent of any passphrase) which is harder to handle but useful for unattended/scripted restores.

Pragmatic recommendation for most LYLIX VPS operators:

• Use passphrase mode (default). Store the passphrase per the three-copies rule above.
• On the VPS itself, the passphrase lives in /etc/borgmatic/passphrase.txt or equivalent, owned root:root 0600. This is for automated backup runs; it's not your DR copy.
• The DR copies are in your password manager, your partner's password manager, and the envelope. The VPS-local copy is for convenience only — assume it's gone when DR time comes.

Multi-VPS fleet: rotate keys, or unique keys?

If you operate multiple LYLIX VPSes, the choice is per-VPS keys (each box has its own) or one fleet-wide key (shared across all boxes).

• Per-VPS keys — better isolation, harder to manage. Compromise of one VPS doesn't expose the others' backups. The key-storage burden multiplies; you need a system to keep track.
• Fleet-wide key — simpler key management, weaker isolation. Compromise of any box exposes the fleet's backups (an attacker who gets the key from the compromised box can decrypt all backups in the same repo).

For small fleets (under ~10 VPSes), fleet-wide is fine if you accept that compromise of one means compromise of all. For larger fleets or compliance-sensitive workloads, per-VPS keys with a key-management system (Vaultwarden, HashiCorp Vault, AWS KMS) becomes worth the operational overhead.

Key rotation

You almost never need to rotate a backup encryption key. The reasons to rotate are:

1. Suspicion of key compromise (someone gained read access to a place the key was stored).
2. Compliance requirement (some frameworks require periodic rotation regardless of compromise).
3. Employee turnover where the departing person had access to the key.

Rotation in borg/restic involves creating a new repository encrypted with the new key, copying archives over (or just starting fresh), and decommissioning the old. It's mildly painful; the operational answer is to set keys generously up front and rotate rarely.

The drill, one more time

The single most useful thing you can do today: pretend you've lost access to your laptop and your usual password manager. Restore your most recent backup using only the credentials in your designated DR location (envelope, partner's vault, whatever). If you can, the key-storage strategy works. If you can't, fix it now — not during the actual disaster.