Introduction

If you've set up Proxmox Backup Server, your VMs and containers are probably in better shape than they've ever been: deduplicated, incremental-feeling, easy to restore. But there's a question most people never ask until something goes wrong: what happens to that data on the wire and on disk? By default, a PBS datastore stores your backup chunks in plain, readable form. Anyone with access to the datastore — a compromised PBS host, a rogue admin, a stolen drive, or a cloud provider hosting your S3-backed datastore — can read the contents of every VM disk and container filesystem you've ever backed up.

Proxmox Backup Server has an answer to that: client-side encryption. The backup is encrypted before it ever leaves the machine being backed up, using a key the backup server itself never sees. PBS stores and deduplicates encrypted chunks it cannot read. This guide covers what that actually buys you, how to turn it on from both the Proxmox VE GUI and the command line, how the master-key and paperkey system works so a lost laptop doesn't mean lost backups, and the mistakes that turn "encrypted" into "permanently gone."

This guide assumes you already have Proxmox Backup Server set up and added as storage in Proxmox VE — if not, that's its own guide. We're using Proxmox VE 9.x and Proxmox Backup Server 4.x below; the encryption workflow has been stable since PBS 2.x, so everything here applies to 8.x/3.x installs too.

What You Will Learn

  • What client-side encryption actually protects against, and what it doesn't
  • How to enable encryption for a PBS storage from the Proxmox VE GUI
  • How to generate and manage encryption keys with proxmox-backup-client
  • How the master-key and paperkey system lets you recover a key without storing the passphrase anywhere digital
  • How to verify a backup is actually encrypted, and how to restore one
  • How encryption interacts with deduplication and garbage collection
  • The key-management mistakes that lead to permanently unrecoverable backups

What Client-Side Encryption Actually Does

Every backup chunk PBS stores is normally just the deduplicated, compressed content of your VM disk or container filesystem, addressed by a hash of its plaintext. With encryption enabled, proxmox-backup-client (or, when triggered from Proxmox VE, the underlying backup process running on the PVE host) encrypts each chunk with AES-256 in GCM mode using a key that lives only on the client side, before the chunk is ever transmitted to the PBS server.

The PBS server ends up storing ciphertext it cannot decrypt. It can still deduplicate identical encrypted chunks against each other — because the same plaintext, encrypted with the same key, produces the same ciphertext and the same chunk digest — and it can still run garbage collection and verification jobs on the encrypted data. What it can no longer do is open a backup and read your data, because it was never given the key.

That's the threat model this protects against: a PBS server (or its disks, or its backups of itself) being read by someone who isn't you — a cloud host, an attacker who compromised the backup server without compromising the machines it backs up, or physical theft of the datastore's storage media. It does not protect against someone who has already compromised the machine being backed up, since at that point they can just read the live filesystem directly.

Two Ways to Turn It On

Proxmox gives you two entry points that end up doing the same underlying thing: the Proxmox VE web interface, which is the path most homelab and small-business users will actually use, and proxmox-backup-client directly, which gives you finer control and is what you'll use for master-key setup regardless of which path you start from.

Method 1: Enabling Encryption from the Proxmox VE GUI

If you've already added a PBS datastore as storage in Proxmox VE, turning on encryption for it takes a few clicks:

  1. In the Proxmox VE web interface, go to Datacenter → Storage.
  2. Select your existing PBS storage entry and click Edit.
  3. Open the Encryption Key tab.
  4. Choose Autogenerate to have Proxmox VE generate a new AES-256 key for you, or Upload key if you already have a .json key file from another install.
  5. If autogenerating, you'll be prompted for a passphrase to protect the key file at rest. Set one you'll actually remember, or store it in a password manager immediately — there is no "forgot password" link.
  6. Click Create.

Proxmox VE writes the resulting key to /etc/pve/priv/storage/<STORAGE-ID>.enc on the cluster filesystem, which is only readable by root and is automatically replicated to every node in the cluster the same way the rest of /etc/pve is. That matters: it means any node in the cluster can run backups and restores against this storage using the same key, without you copying files around by hand.

Once this is set, every backup job that targets this storage is encrypted automatically — there's no per-job toggle. You'll see a small padlock icon next to encrypted snapshots in the Backups view on both the Proxmox VE and Proxmox Backup Server GUIs, which is the easiest way to confirm it actually took effect.

Method 2: Managing Keys with proxmox-backup-client

The GUI path above is really a thin wrapper around the same key file format used by the standalone proxmox-backup-client tool, and understanding the CLI version makes the master-key section below make sense. To create a key manually:

proxmox-backup-client key create /root/pbs-encryption.key

This creates a password-protected AES-256-GCM key file and prompts you for a passphrase used to derive the key-encryption key (KDF) that wraps it at rest. If you'd rather not be prompted for a password on every backup — common on an automated backup job with no human present — you can skip password protection on the key file itself:

proxmox-backup-client key create /root/pbs-encryption.key --kdf none

Be clear-eyed about that trade-off: --kdf none means anyone who can read the key file can use it, full stop. It's appropriate for a key file sitting in a root-only directory on a machine you already trust, not for something you're emailing to yourself.

To actually use a specific key file for a manual backup run outside the PVE-managed storage flow:

proxmox-backup-client backup root.pxar:/ --keyfile /root/pbs-encryption.key \
  --repository backup-user@pbs!token@pbs.example.lan:datastore

You'll be prompted for two separate passwords in this flow: one to authenticate to the PBS repository, and a second to unlock the encryption key itself (skipped if you used --kdf none). For scripted or unattended runs, both can be supplied without prompts using environment variables:

  • PBS_PASSWORD — the repository/API token password
  • PBS_ENCRYPTION_PASSWORD — the key file's passphrase
  • PBS_PASSWORD_FILE / PBS_ENCRYPTION_PASSWORD_FILE — read the value from a file instead of an env var, so it doesn't show up in ps output or shell history

Prefer the _FILE or _FD variants over plain environment variables on any host where other users or processes might be able to inspect the environment of a running process.

Master Keys and Paperkey: Encryption Without a Single Point of Failure

Here's the problem the setup above doesn't solve: if the passphrase protecting your key file lives only in your head, and you get hit by a bus (or, more realistically, you change laptops and forget to migrate your password manager export), your backups are gone. Not "hard to restore" — gone. There is no admin override, no Proxmox support ticket that gets your data back. PBS encryption has no backdoor by design.

The master-key system exists specifically to give you a second, independent recovery path that doesn't depend on remembering a passphrase at all. It works like this:

  1. Generate an RSA master keypair, ideally on a machine that's never connected to the internet, or at least somewhere you trust more than your daily-driver laptop: 
    proxmox-backup-client key create-master-key
    This produces two files: master-public.pem and master-private.pem. The private key is the one that matters — treat it like a root CA key.
  2. Import the public half onto every machine that will be doing backups: 
    proxmox-backup-client key import-master-pubkey /path/to/master-public.pem
    This gets stored at ~/.config/proxmox-backup/master-public.pem for that user.
  3. Back up as normal. With a master public key imported, every backup snapshot automatically includes an extra file, rsa-encrypted.key, which is your symmetric backup encryption key re-encrypted against the master public key. You don't have to do anything differently day to day — it just rides along with each snapshot.
  4. Recover a lost key using the master private key and that rsa-encrypted.key file pulled from any snapshot: 
    proxmox-backup-client key import-with-master-key /root/recovered.key \
  --master-keyfile /path/to/master-private.pem \
  --encrypted-keyfile /path/to/rsa-encrypted.key
    This reconstructs your original backup encryption key without you ever needing to remember its passphrase.

The last piece is getting the master private key itself somewhere durable and offline. PBS has a built-in tool for exactly this:

proxmox-backup-client key paperkey --output-format text --path /path/to/master-private.pem > paperkey.txt

This renders the private key as a QR code plus human-readable text, meant to be printed and stored somewhere physical — a safe, a safety deposit box, wherever you'd keep the deed to a house. It's deliberately low-tech: a piece of paper doesn't suffer bit rot, doesn't get bricked by a firmware update, and can't be remotely wiped.

In practice, a sane setup for anything beyond a single-host homelab looks like: generate the master key once, print the paperkey and lock it away, import the public key on every host that backs up to this datastore, and stop thinking about it. If a laptop dies with the only copy of a key's passphrase, you scan the paperkey back in and recover.

Verifying a Backup Is Actually Encrypted

After enabling encryption, don't just trust that it worked — confirm it. In the Proxmox VE GUI, open the node or VM's Backup tab; encrypted snapshots show a small padlock icon next to the size and date. In the Proxmox Backup Server GUI, open the datastore's content view and the same padlock indicator appears per snapshot.

From the command line, listing snapshots on the PBS side shows the encryption fingerprint for each one:

proxmox-backup-client snapshot list --repository backup-user@pbs!token@pbs.example.lan:datastore

An encrypted snapshot reports a Crypt mode of encrypt along with a fingerprint of the key used to protect it; an unencrypted one shows none. If you just flipped on encryption for existing storage, remember that only new backup runs going forward are encrypted — every prior snapshot on that datastore stays exactly as it was created. Encryption isn't retroactive.

Restoring an Encrypted Backup

Restores work the same as any other Proxmox VE restore as long as the encryption key is present on the node performing the restore — which it will be automatically if you set encryption up through Datacenter → Storage, since the key file replicates cluster-wide. Pick the snapshot in the GUI, click Restore, and it decrypts transparently.

Doing it from the CLI with proxmox-backup-client directly requires pointing at the key explicitly:

proxmox-backup-client restore vm/100/2026-07-16T10:00:00Z root.pxar /target/path \
  --repository backup-user@pbs!token@pbs.example.lan:datastore \
  --keyfile /root/pbs-encryption.key

If the key file is missing or the passphrase is wrong, the restore fails outright — there is no partial or best-effort decryption. This is also why the file-level restore tool supports the same --keyfile option: browsing an encrypted snapshot's contents requires the key just as much as a full restore does.

Encryption, Deduplication, and Garbage Collection

A reasonable worry: does encrypting backups wreck the deduplication that makes PBS worth using in the first place? Mostly no, with one caveat. Because chunk encryption is deterministic for a given key, the same plaintext chunk encrypted with the same key always produces the same ciphertext and the same stored chunk digest — so backing up the same VM every night still dedupes against itself normally, and identical VMs sharing the same encryption key still dedupe against each other.

The caveat: deduplication only works within a shared key. Two VMs backed up with two different encryption keys will never deduplicate against each other, even if their disks are byte-for-byte identical, because the ciphertext each key produces is different. If you're chasing maximum space savings across a fleet of similar VMs, backing them all up under one shared key (with the master-key system providing your recovery path) gets you more deduplication than giving each VM its own key.

Garbage collection and periodic verification jobs on the PBS side work exactly the same whether chunks are encrypted or not — GC only needs chunk digests and reference counts, not plaintext, and PBS verification checks chunk integrity, not decryptability.

Common Mistakes

  • Losing the key with nothing else to fall back on. This is the one that actually happens. A key file with a KDF-protected passphrase that only exists in someone's head, on a laptop that later dies, with no master key set up, means every encrypted backup on that datastore is permanently unreadable. Set up the master key and paperkey before you need them, not after.
  • Backing up the key file to the same place it protects. Storing your only copy of the encryption key inside the backup it encrypts is circular — if you ever need to restore because the source machine is gone, the key went with it. Keep the key (or at minimum the master private key / paperkey) somewhere entirely separate from the systems it protects.
  • Assuming encryption is retroactive. Turning on encryption for a storage doesn't touch backups already sitting on the datastore. If you need old data encrypted too, that means a fresh backup run after enabling it, and eventually pruning the old plaintext snapshots.
  • Using --kdf none on a shared or lightly-secured host. Convenient for unattended jobs, but it means file permissions on the key are the only thing standing between anyone with root (or a backup of that key file) and your data.
  • Mixing keys across nodes without realizing it. If you set encryption up per-node with the CLI instead of through Datacenter → Storage, each node can end up with its own key, silently breaking both deduplication between nodes and the ability to restore a VM's backup from a different node than the one that created it.

Frequently Asked Questions

Does client-side encryption slow down backups?

There's a measurable but usually small CPU cost from AES-256-GCM encryption on the client side, and modern CPUs with AES-NI instruction support handle it well enough that it's rarely the bottleneck — network throughput or storage I/O on either end is far more likely to be the limiting factor.

Can I encrypt backups that already exist on a datastore?

No. Encryption is applied at backup time, per snapshot. Existing unencrypted snapshots stay unencrypted; only backups run after you enable encryption get the protection. To fully migrate a VM's backup history to encrypted storage, you'd need to run a new full backup and eventually prune the old unencrypted snapshots.

Does this work with an S3-backed PBS datastore?

Yes — client-side encryption happens before data ever reaches the datastore backend, so it applies identically whether the datastore sits on local disk, ZFS, or an S3 bucket. It's arguably more important with an S3 backend, since you're trusting a third party with the storage layer.

Can different VMs use different encryption keys on the same datastore?

Yes, technically — each backup job or client can supply its own key file. In practice, this only makes sense if different VMs have different owners or trust boundaries; otherwise it costs you cross-VM deduplication for no real security benefit, since anyone with access to the datastore already can't read any of it regardless of which key protects which VM.

What if I forget the encryption key's passphrase but still have the key file?

You can change a key's passphrase if you still know the current one (proxmox-backup-client key change-passphrase), but if the passphrase itself is forgotten, the key file alone is useless — the passphrase is what unlocks it. This is exactly the scenario the master-key and paperkey system exists to prevent; without one set up in advance, a forgotten passphrase means the same permanent data loss as losing the key file entirely.

Conclusion

Client-side encryption turns Proxmox Backup Server from "trusted because it's mine" into "trusted because the server literally cannot read it," which matters a lot more the moment your datastore lives on someone else's disk, whether that's an S3 bucket, a colo you don't fully control, or just a backup target you'd rather not have to fully trust. The GUI setup takes minutes. The part worth taking seriously is the master-key and paperkey system — set it up before your first encrypted backup, not after you've already lost a key, because there is genuinely no recovery path Proxmox or anyone else can offer once that happens.