Encrypting backups adds a failure mode that unencrypted backups do not have, because the key becomes a single point of failure for every copy you hold. More data is lost to a forgotten passphrase than to an attacker reading an archive, and almost nobody plans for the first risk. This covers what each layer of encryption actually protects, how the common tools hold keys, rotation that does not mean rewriting terabytes, and the restore test that finds the gap.
So the useful framing is not whether to encrypt, which is settled, but which of three questions you are answering. Who may read the archive is confidentiality. Who can restore it, and under what conditions, is availability. Who can destroy it is integrity. Encryption improves the first and can quietly ruin the second, and most backup policies are written as though only the first exists.
MassiveGRID: Backup Services with AES-256 encryption on R1Soft block-level incrementals, RAID10 storage in Tier-3 and Tier-4 datacenters, US and EU locations, $0.01 per GB · HSM and Decanus Terminal for hardware-backed key custody, Common Criteria EAL 5+ certified
Backup Services · HSM & Decanus Terminal · Disaster Recovery
Three Places Encryption Can Happen
These are routinely conflated, and they protect against completely different things.
| Where | Protects against | Does not protect against |
|---|---|---|
| In transit (TLS) | Interception on the network | Anyone with access to the stored copy |
| At rest, provider-managed | Stolen or decommissioned disks | Anyone who can read through the provider's own access path |
| Client-side, your key | Everyone without the key, the provider included | Nothing, and that is the problem |
Provider-managed encryption at rest is genuinely valuable and it is not confidentiality from the provider. If your requirement is that nobody but you can read the archive, that requires client-side encryption with a key the provider never holds, and it hands you sole custody of the only thing that can decrypt your data.
The Tension, in One Sentence
Client-side encryption means the provider cannot read your backups, and therefore cannot help you when the key is gone.
Every support team that runs backups has had this conversation. The archive is intact, the storage is healthy, the customer has the data, and it cannot be decrypted. There is no escalation path and no vendor override, because the absence of one is the feature you selected.
Which means the key management plan is not paperwork around the backup. It is the backup.
How the Common Tools Hold Keys
Knowing the specific model matters, because the recovery story differs.
restic derives a master key from a repository password. The master key is stored in the repository, wrapped by the password, so you can add and remove passwords without re-encrypting data. Multiple passwords can open one repository, which is the mechanism for giving a second person access:
restic -r /srv/backups key list
restic -r /srv/backups key add # add a second passphrase
restic -r /srv/backups key remove <id>Borg makes the distinction explicit in the mode you choose at repository creation. With repokey, the key lives in the repository, protected by your passphrase, so the repository plus the passphrase is enough. With keyfile, the key lives in your home directory and the repository is useless without it, so that file needs its own backup somewhere the repository is not:
borg init --encryption=repokey-blake2 /srv/backups
borg key export /srv/backups /secure/borg-key-export.txt
borg key export --paper /srv/backups # printable, for a safeProxmox Backup Server encrypts client-side with a key file the server never sees, and prints a paper key precisely because the failure mode is well understood.
The pattern to notice: every mature tool provides an export path for the key, and the export is only useful if you actually run it and store the output away from the backups.
Rotation That Does Not Re-Encrypt Everything
Compliance frameworks ask for key rotation, and a naive reading implies re-encrypting every archive on a schedule, which for a large repository is impractical.
Envelope encryption solves it. Data is encrypted with a data encryption key, and that key is itself encrypted with a key encryption key. Rotating the outer key means re-wrapping a small amount of key material rather than rewriting terabytes. This is exactly what restic's password model and Borg's repokey mode are doing.
So rotation in practice means changing the passphrase or the wrapping key, which is fast, while the data keys stay put. If a data key is genuinely believed compromised, that is not rotation, that is a re-encryption event and it needs the full pass.
Two operational rules. Never remove the old credential until the new one is confirmed working against a real restore. And write down what rotation actually rotated, because an auditor asking whether data keys or wrapping keys were changed is asking a meaningful question.
Where to Keep the Key
Ranked by how well each survives the disaster the backup exists for:
| Location | Assessment |
|---|---|
| On the server being backed up | Worthless. The event that destroys the server destroys the key |
| In the backup repository, passphrase-protected | Fine, provided the passphrase itself is stored elsewhere |
| In a password manager | Reasonable, if the manager is not itself dependent on the failed system |
| Printed and held in a safe | Genuinely resilient, and awkward to rotate |
| Split among several holders | Strong. No single person can restore alone or lose it alone |
| Hardware security module | Strongest. The key material never leaves the device |
The first row is the mistake that actually happens, usually because the key was generated on the server during setup and never moved. Check for it: if the only copy of the passphrase is in a config file or a shell history on the host, the backup is decorative.
Split custody deserves more use than it gets. Requiring two of three holders to reconstruct a key removes both the single point of loss and the single person who could exfiltrate every archive, and it is a policy decision rather than a technology purchase.
When an HSM Is Warranted
A hardware security module generates keys inside tamper-resistant hardware and never releases the private material. Operations happen on the device; software asks it to encrypt or decrypt and receives a result rather than a key.
That matters for backups in three situations. When a regulator requires hardware-backed key custody. When you cannot accept the risk of an administrator copying a key. And when the number of keys and holders has grown past what a password manager and a written procedure can govern honestly.
MassiveGRID's HSM and Decanus Terminal is deployed in private cloud clusters, with the Terminal managing up to 64 HSMs across locations from one place, holding over a million keys across 120 partitions. The vault is certified to Common Criteria EAL 5+, keys are generated from hardware true random number generation, and tamper detection erases key material if the hardware is breached, with sensors active even when the unit is unpowered so transit is covered. The design is crypto-agile for post-quantum algorithms, which matters for anything you must keep readable for a decade.
Partitions are the feature that fits backup practice: separate key custody per tenant, per environment or per regulatory scope, on shared hardware, without a shared key.
Test the Restore, Not the Backup
Encryption turns an untested restore from a risk into a likely failure, because it adds a step that can fail silently and independently of the data.
Test the whole path, on a machine that is not the source, using only the key material you would actually have available in a disaster:
restic -r s3:https://s3.example.com/backups snapshots
restic -r s3:https://s3.example.com/backups restore latest --target /tmp/verify
borg extract --dry-run --list /srv/backups::archive-nameThe discipline that matters is the third clause. A restore test performed by the engineer who set it up, on the host that holds the key, from a shell with the passphrase in the environment, proves almost nothing about a real recovery. Have someone else do it, from the documented procedure, with the key retrieved from wherever your plan says it lives. That is the test, and it usually finds a gap the first time.
A Workable Arrangement
For most organisations, layered rather than either extreme.
MassiveGRID Backup Services provides the operational layer: R1Soft block-level incremental backups with AES-256 encryption, on RAID10 storage in Tier-3 and Tier-4 datacenters separate from the protected host, with bare-metal restore, US and EU storage locations, unlimited backup operations at $0.01 per GB and two free snapshots per VPS. This is the copy you restore from routinely, and the provider can help when something goes wrong with it.
Then add client-side encryption for the subset of data whose confidentiality genuinely requires that the provider cannot read it, with the key held under split custody or in an HSM, and a documented recovery procedure somebody other than its author has executed. Applying that to everything is a common over-correction: it maximises confidentiality and maximises the chance that a restore fails when you need it.
Keep the two questions separate when you design this. Confidentiality asks who may read the archive. Availability asks who can restore it, and under what conditions. A plan that answers only the first is the plan that produces an intact archive nobody can open. Our guide to immutable backups and ransomware recovery covers the third question, which is who can destroy it.