Client-side encryption on Proxmox Backup Server: who really holds your keys

Most teams ask the wrong question about backup encryption. They ask “are my backups encrypted”, tick the box, and move on. The question that actually decides whether encryption protects you is a different one: who can decrypt them. On Proxmox Backup Server the answer is unusually clean, and it has consequences that catch people out on the day they need a restore.

This is not a how-to. If you want the click-by-click setup, our documentation covers enabling client-side encryption from Proxmox VE. This is about the key model behind it: what it buys you, what it demands of you, and where it stops.

Client-side means the server never sees plaintext

Proxmox Backup Server encrypts on the client. Each chunk of a VM is encrypted on your Proxmox VE host with AES-256-GCM, and only the ciphertext leaves your network. The PBS datastore stores blocks it cannot read. Deduplication and verification still work, because they operate on the encrypted chunks and their authenticated hashes, not on the plaintext.

The practical meaning is that the operator of the backup server is outside your trust boundary. Whoever runs the PBS host, whether that is your own storage team or a managed provider like Cloud-PBS, holds only unreadable blocks. There is no admin panel, no support tool, no legal request that turns those blocks back into your data, because the key that would do it never reached the server.

The zero-access model, and its one hard rule

That property is worth stating plainly because it is the whole point: with client-side encryption enabled, nobody but you can read your backups. Not the datastore admin, not the hosting provider, not an attacker who compromises the PBS host, not a subpoena served on the provider.

The hard rule that comes with it: there is no recovery path for a lost key. No master key, no vendor override, no reset link. This is not a limitation Cloud-PBS could lift if it wanted to. The absence of a backdoor is exactly what makes the guarantee real. A vendor who can recover your key for you when you lose it is a vendor who can also hand it to someone else.

So the encryption key becomes the single most valuable object in your backup chain. A ransomware actor who encrypts your production and your local PBS still cannot touch an offsite encrypted copy. But you cannot touch it either if the key lived only on the machine that got encrypted.

Treat the key like it is the backup

The key is 32 bytes. Losing it is trivial and permanent, so it deserves the same 3-2-1 thinking you apply to the data itself: more than one copy, in more than one place, at least one of them offline and off the machine that produced it.

Concretely, when Proxmox VE generates the key it offers three ways to keep it, and they are not exclusive:

• A password manager. The easiest and, for most teams, the right default. The key rides your existing secret-management discipline and survives the loss of any single host.
• An offline copy on removable media, placed somewhere physically separate. This is your defense against a compromise of the systems that hold the online copy.
• A printed paperkey. The most robust against digital disaster and the most painful to use under pressure. Good as a last-resort vault copy, poor as your only copy.

The failure mode to design against is the one where the key and the data share a fate. If the key lives on the PVE host and that host is the thing you are restoring from bare metal, you have encrypted yourself out of your own backups. Keep the key somewhere the disaster cannot reach. The steps to bring a key back onto a rebuilt host are in restoring your encryption key.

Rotation and scope

Encryption is opt-in per storage, which means you can run different keys for different datastores, or leave a low-sensitivity datastore unencrypted for the small performance and simplicity gain. A backup pushed before you enabled encryption stays in its original form; turning encryption on does not retroactively encrypt what is already there.

Rotation is coarser than with, say, TLS certificates. Because a snapshot is decryptable only with the key it was written under, rotating to a new key does not re-encrypt old snapshots. In practice you rotate by starting a new key going forward and retaining the old one for as long as snapshots written under it are inside your retention window. Do not delete a retired key until the last backup that used it has aged out.

Encryption is not immutability

The most common confusion we see is treating encryption as ransomware protection. It is not, on its own. Encryption controls who can read a backup. It does nothing to stop someone with datastore access from deleting it. A ransomware actor rarely wants to read your backups; they want to destroy them so you have to pay.

The control that stops deletion is immutability, an append-only or object-lock copy that cannot be removed before a retention period elapses, which is the “1” in a serious 3-2-1 setup. Encryption and immutability are complementary, not substitutes. Encryption keeps a thief from reading; immutability keeps a vandal from erasing. A backup strategy that is worth the name has both.

Where Cloud-PBS sits in this

Cloud-PBS is a managed cloud backup server, and the encryption model is precisely why a managed provider can be trusted with your data at all. Your key is generated on your Proxmox VE host and never transits our infrastructure. We store ciphertext in the region you choose, we run the verification and garbage collection on blocks we cannot read, and we could not produce your plaintext under any circumstance. That is not a policy we promise to follow. It is a property of where the key lives.

If you want to turn it on, the step-by-step guide takes about two minutes. The part that deserves your attention is not the toggle. It is deciding, before you flip it, exactly where your key will live so that a bad day never separates you from it.