Backup Encryption: Key Management Done Right

Most backup setups in German SMBs in 2026 are encrypted — that is the good news. The bad news: in many cases the key management is so thin that the encryption causes more damage than protection in the moment of truth. Three real-world scenarios:

• The only employee who knew the Restic repo password has left the company. Nobody can access the off-site backups any more.
• The TrueNAS datasets are encrypted, the key lies as a JSON file on the same TrueNAS. Ransomware hits and key and data are gone at the same time.
• The PBS repo is client-side encrypted, the key file was never copied elsewhere. Server crash and backup restore fails.

Backup encryption is hygiene — but only if key management is part of the design. This article shows the principles and concrete implementation for the common tools.

Symmetric vs. Asymmetric — What Goes Where

The most important conceptual split:

Symmetric encryption (AES-256, ChaCha20) is fast and made for large data volumes. The same key encrypts and decrypts. For the actual backup data AES-256 is the standard — fast enough that the disk is the bottleneck, not the CPU.

Asymmetric encryption (RSA, ECC) is slower, but has the advantage that public and private keys are separated. In backup practice it is typically used for key wrapping: the actual data key (AES) is encrypted with an RSA public key and stored alongside the backup. To restore, the matching private key is needed.

In modern backup tools this typically looks like: a symmetric master key per backup job, which in turn is “wrapped” with a passphrase or an asymmetric key. Anyone wanting to decrypt a single backup job needs both.

Key Vault Options — What Fits Where

Where does the key that belongs to the backup live? An overview of common options with pros and cons:

HashiCorp Vault. Enterprise standard for central secret management. Audit logs, rotation, access policies, integration with identity providers. Requires setup effort and at least three nodes for HA. Pro: fully featured, auditable. Con: overhead for very small environments.

Bitwarden / Vaultwarden. Actually a password manager, but well suited to store backup keys (short strings, passphrases). The self-hosted version (Vaultwarden) runs on any small VM. Pro: low entry hurdle, team sharing. Con: no auto-rotation, weaker audit trails than Vault.

KeePassXC with YubiKey. File-based encrypted database protected by master passphrase plus hardware token. For single-person workflows or small teams. Pro: no server infrastructure, offline-capable. Con: sharing cumbersome, multi-user workflows fragile.

AWS KMS / Azure Key Vault. If cloud infrastructure already lives at a hyperscaler, the native KMS services are a serious option. Hardware-backed keys (HSM), audit logs, fine-grained IAM integration. Con: vendor lock-in, and storing backup keys at the same provider that hosts the cloud data is not appropriate for every compliance model.

Hardware tokens / smartcards. For highly sensitive master keys there are dedicated solutions (YubiKey HSM, Nitrokey HSM, smartcards). Key material never leaves the device. Pro: highest security. Con: physical handling, availability during maintenance.

Pragmatic recommendation for SMBs in 2026: Vaultwarden for backup repo passphrases, KeePassXC + YubiKey for master keys. For larger environments or regulated industries: HashiCorp Vault.

3-2-1 for Keys — Keys Need Backups Too

The 3-2-1 rule is standard for data. For keys it is often forgotten. Minimum requirement:

• Two copies of the master key, ideally three
• Geographically separated (not everything in the same vault)
• Encrypted (a plaintext key on a USB stick is not a solution)

A concrete setup that has proven itself:

1. Master key in the primary key vault (e.g. Vaultwarden), access for IT leadership
2. Encrypted backup of the whole vault monthly to a separate medium
3. Emergency key in a bank safe deposit box — printed on paper, in a sealed envelope

The latter sounds old-fashioned but is the only variant that survives a complete IT outage (all systems encrypted by ransomware, all accounts locked). We have customers whom exactly this setup saved during a ransomware incident — the managing director opened the safe deposit box, took out the key and used it to decrypt the off-site backup.

Rotation: Annually, but Sensibly

Backup master keys should be rotated. How often depends on the risk profile — a sensible rule of thumb for SMBs: once a year, plus on any suspicion of compromise or personnel change with key access.

Rotation does not mean: re-encrypt old backups. That would usually be disproportionately expensive. Instead:

• New master key is created and stored in the vault
• From the effective date, new backups are encrypted with the new key
• Old backups remain accessible with the old key — the old key stays in the vault, separately labelled (“ARCHIVE — until date X”)
• After the retention period for the old backups, the old key is also deleted

Those who nevertheless want to follow the re-encryption model (e.g. because an old key was compromised): plan a one-off effort with the tool-specific mechanisms (see below).

Run Through Recovery Scenarios

A key management concept is only as good as the rehearsed emergency. Three scenarios that should be tested at least once a year in every SMB environment:

Scenario 1: IT lead is unavailable tomorrow. Can another employee or management access the backup keys? If the answer is no, there is a bus-factor problem.

Scenario 2: Entire datacentre unreachable. Are keys accessible from an alternative location too? Ideally: from the managing director’s laptop at home, plus a safe deposit box.

Scenario 3: Ransomware has encrypted all online systems. Is at least one key copy offline (paper, cold storage)? If only online vaults exist, the concept is not ransomware-proof.

Concrete Tools: PBS, Restic, TrueNAS

Proxmox Backup Server (PBS) — Client-Side Encryption. PBS supports client-side encryption with a 256-bit AES key per datastore. The key is generated on the PBS client and stays there; the PBS server only ever sees encrypted chunks. In practice:

proxmox-backup-client key create /etc/pve/priv/pbs-encryption.key

This file must be stored securely outside the backup target. Without it the backup is unrecoverable — not even by Proxmox Server GmbH. We recommend: upload the key file to Vaultwarden and print a safe-deposit-box copy (hex or base64 dump).

Restic — repo passphrase. Restic encrypts every repository with a passphrase. A master key is derived from the passphrase, which in turn encrypts the data keys. Restic supports multiple passphrases per repo (restic key add) — very practical for team setups:

restic -r s3:s3.example.com/bucket key add

Each team member or service account gets its own passphrase. When an employee leaves, their passphrase is revoked with restic key remove — without re-encrypting the whole repo. See also Restic: encrypted backups and Restic REST server for centralised backup.

TrueNAS — dataset encryption. TrueNAS encrypts ZFS datasets with either a passphrase or a key file. The crucial point: the key must not live on the same TrueNAS that it encrypts. Recommendation:

• Export the dataset key as a JSON file (zfs key export)
• Upload the JSON file to an external vault (Vaultwarden, KeePass)
• Configure TrueNAS for unlock-on-boot only if the boot console is physically secured; otherwise manual unlock after reboot

For replication between TrueNAS systems the key can be sent along (zfs send -w) — that way the target pool remains encrypted as well, without decrypting in between. See TrueNAS replication with ZFS encryption keys.

GoBD and GDPR: Retention Periods for Keys

A point that regularly comes up in audits: keys must be retained at least as long as the encrypted data. If the tax office demands eight years of accounting data and the backup is there but the key was deleted three years earlier — formally the data is no longer readable, and that is a GoBD problem.

Concrete recommendations:

• Document a key retention plan (which key, which retention period, when deleted)
• In the vault, mark old keys clearly (“ARCHIVE — retention until 31.12.2034”)
• For GDPR erasure requests (“right to be forgotten”): if the data lies in encrypted backups and the key would be pseudonymous, that is a special case to clarify with the data protection officer

Conclusion

Encrypted backups are standard and right in 2026 — but they are only as robust as the key management. Three minimum requirements from our perspective:

1. At least two copies of every master key, one of them offline (paper, safe deposit box)
2. Vault outside the backup infrastructure (Vaultwarden, KeePass, Vault — not on the TrueNAS being encrypted)
3. Recovery test at least once a year, with an actual restore attempt without the main responsible person present

Anyone who has this survives not only ransomware and hardware failures, but also personnel changes and long-term compliance audits. DATAZONE helps build the right key concept for PBS, Restic and TrueNAS environments — pragmatically and sized for SMB realities.