Who can read your offsite backups?

How client-side encryption works

PBS encrypts on the client — your Proxmox VE host or proxmox-backup-client — before anything is uploaded. Each chunk is encrypted with AES-256-GCM, an authenticated mode: it both hides the contents and detects tampering. The server receives, stores, verifies, and deduplicates ciphertext chunks without ever holding the key.

Everything also travels over TLS, but that's transport. The point of client-side encryption is what's at rest on someone else's disks: opaque chunks that are useless without a key that never left your building. Deduplication still works within your encrypted dataset — identical plaintext chunks encrypt to matching chunks under your key — so you don't trade storage efficiency for confidentiality.

Turning it on

In Proxmox VE, encryption lives on the storage entry: when you add the PBS storage (Datacenter → Storage → Add → Proxmox Backup Server), the Encryption tab lets you auto-generate a key. From the command line:

# generate a client encryption key
proxmox-backup-client key create --kdf scrypt

# back it up as a printable/scannable paper key — do this NOW
proxmox-backup-client key paperkey

Every backup after that is encrypted transparently — jobs, restores, and file-level restore all work exactly as before, because the client holding the key does the decrypting. One caveat: turn it on from the first backup if you can. Encrypted and unencrypted snapshots don't share chunks, so switching later re-uploads a full baseline.

Key management — the part that actually bites

• Lost key means lost backups. Not "call support" lost — mathematically lost. Nobody, us included, can decrypt your chunks without it. This is the price of an honest "nobody else can read them."
• Back up the key somewhere that isn't protected by the backups. The classic failure: the only key copy lives on the PVE host that just died. Print the paperkey, store it in a safe (two safes, ideally), and put a copy in your password manager.
• The master-key option: PBS supports an RSA master key that can recover the encryption key — keep it offline. It's a recovery path, not an excuse to skip the paper copy.
• Rotate deliberately, not casually. A new key means a new full baseline (no shared chunks). Rotate if you suspect compromise, not on a calendar.

What it does — and doesn't — protect against

It protects against: anyone with access to the storage reading your data — a provider's staff, a stolen disk, a breached storage system, a subpoena served on the wrong party. It also blunts double-extortion ransomware: exfiltrated ciphertext isn't leverage.

It does not protect against: deletion. Encrypted chunks can still be pruned or destroyed by someone with the rights to do so — that's what scoped tokens and protected snapshots are for. And it can't help with anything an attacker reads inside your running guests. Encryption is the confidentiality layer of a complete recovery plan, not the whole plan.

What this means on hosted storage

Client-side encryption is what makes hosted backup storage a clean trust proposition: you don't have to take our word for what we can see, because with your key enabled we can't see anything but chunk sizes and timestamps. We store ciphertext on ZFS, verify its integrity, and keep the platform healthy; the contents are cryptographically your business. It works identically on Dynamic and Dedicated plans — the encryption happens on your side of the wire either way.