Learn Proxmox Backup Server - Client-side Encryption

#Introduction

After dedup and GC saved storage in episode 6, now we talk about confidentiality. Backup data is a full copy of your entire system — if the backup server falls into the wrong hands, everything you protect is exposed too. Episode 7 closes this gap with client-side encryption: data is encrypted before it leaves the client, so the PBS server itself never sees plaintext.

Imagine it like storing notes in invisible ink: the one storing the notes (the PBS server) only sees unreadable scribbles. The only reading key is in your hands (the client). If the key is lost, those notes remain unreadable forever — no warehouse technician can help.

#Client-side Encryption

#The Concept: The Key Lives on the Client

The core PBS principle: the key only exists on the client side. During backup, the client encrypts each chunk with the key before sending it. The server receives, stores, and manages pure ciphertext. The server cannot even verify snapshot contents (which is why verify jobs in episode 9 can only validate chunk integrity, not read them without a key).

The benefit is huge: a PBS admin, an attacker who breaks into the server, or a storage provider who steals the disk will get nothing readable. The data stays safe even if the server is fully compromised.

#Generating the Key (Base64)

The key is created on the client side, not the server:

Generate a keyfile on the client

proxmox-backup-client key generate \
  --keyfile /etc/proxmox-backup/enc.key

proxmox-backup-client key generate produces a base64-formatted key. Optionally, you can create a password-encrypted key (--kdf-iterations for derivation iterations) — safe if the keyfile falls into the wrong hands, but it requires you to remember the password.

#Setting the encryption-key on Backup Tasks

In PVE, the keyfile is attached to the PBS storage. From the CLI, add the encryption-key-file option to the storage:

Set the keyfile on PBS storage in PVE

pvesm set pbs1 --encryption-key-file /etc/proxmox-backup/enc.key

In the PVE web UI: Datacenter → Storage → pbs1 → Edit, fill Encryption Key File with the keyfile path on the PVE node. All backups using this storage are automatically encrypted. For direct proxmox-backup-client, the key is pointed to via --keyfile:

Back up files with encryption

proxmox-backup-client backup etc.pxar:/etc \
  --repository backup@pbs@10.0.1.10:store1 \
  --keyfile /etc/proxmox-backup/enc.key

Important

The keyfile must exist on every client performing backups and every host that will restore. If the keyfile is lost, encrypted snapshots become permanently useless — there is no backdoor, no bypass. Treat the keyfile like the most important root password in your environment.

#Verification: The Server Cannot Read It

How do you prove encryption is really active? Check from the server side that the stored data is ciphertext:

Inspect chunks in the datastore (from the PBS server)

ls -la /var/lib/proxmox-backup/datastore/store1/chunk
xxd /var/lib/proxmox-backup/datastore/store1/chunk/.../....chunk | head

The chunk contents will look random (ciphertext), not readable data. Stronger proof: try a restore without the key from a client — proxmox-backup-client restore will fail with a key-related error because PBS cannot decrypt. Try a restore with the key: the data comes back intact.

#Key Management

#Store Keys Separately in a Safe Place

Rule number one: the key must not exist in only one place. Make several copies:

Primary: on the client (keyfile path).
Offline backup: in a safe physical place or vault (e.g. the team password manager, hardcopy in a safe).
Cross-site: a copy in a different location for disaster recovery.

Every time a key is replaced (rotated), update all copies — old snapshots use the old key, so keep the old key as long as old snapshots exist.

#Without the Key, Restore Is Impossible

This is the most important consequence of client-side encryption: without the key, there is no restore, and no support can help. Make sure the key storage procedure is documented in the team runbook. Before replacing personnel who hold the key, rotate the key and distribute the new one.

Warning

Do not store the keyfile in the same PBS datastore (let alone inside a VM that is backed up to that PBS). The keyfile must live outside the failure domain of the data it protects — otherwise your "safe backup" can be lost in a single incident.

#Key Management Practices

Use a key per environment (dev/staging/prod) to separate the blast radius.
Rotate the key when there are signs of leakage or personnel changes.
Document key locations in the team security document.
Periodically test restore with the key from a keyfile backup — not just from the primary keyfile.

#Closing

Key takeaways:

Client-side encryption: the key is only on the client, the server stores only ciphertext.
Generate a base64 key with proxmox-backup-client key generate --keyfile.
Set encryption-key-file on PVE storage or --keyfile on the client.
Verification: chunks on the server look random, and restore fails without the key.
Store keys in several separate places; without the key, restore is impossible.
Rotate and document keys; test restore using a backup key copy.

In the next episode, episode 8, we will manage the snapshot lifecycle: retention & prune policy — understanding keep-last, keep-daily, keep-weekly, and keep-monthly per backup group, how sync jobs maintain retention on the remote side, and adjusting the policy to your RPO/RTO targets. Storage will grow in balance, not wild!