PBS Client-Side Encryption: Secure Your Backups Before They Leave Your Server

Your Proxmox Backup Server stores everything your VMs contain. Database dumps, private keys, customer records, credentials. If those backups land on storage you don't physically control, you have a trust problem. Encryption solves it. PBS supports client-side encryption that happens on your Proxmox VE host before a single byte leaves the network. The PBS server receives encrypted chunks. It cannot decrypt them. Neither can anyone with access to the storage underneath it.

Why Encrypt Backups?

If your PBS runs on the same rack as your hypervisors and you trust every link in that chain, encryption is optional. But the moment backups cross a network boundary, the threat model changes.

Third-party storage. Syncing to an offsite PBS means your data sits on infrastructure you don't own. The hosting provider, their staff, law enforcement in their jurisdiction — all can potentially access the raw storage. Client-side encryption makes that access meaningless.

Transit exposure. PBS uses HTTPS for transport, which protects data in flight. But transport encryption terminates at the PBS endpoint. If the remote server is compromised, the data is plaintext on disk. Client-side encryption adds a layer that's independent of the transport.

Compliance requirements. GDPR mandates appropriate technical measures for personal data protection. SOC 2 Trust Service Criteria require encryption of data at rest and in transit. ISO 27001 Annex A.10 covers cryptographic controls. Client-side encryption satisfies all of these at the backup layer.

Zero-trust posture. Assume your offsite PBS gets compromised. With client-side encryption, the attacker gets encrypted chunks. Without the key, they're noise. This pairs well with the immutable backup architecture PBS already provides.

How PBS Encryption Works

PBS encrypts at the chunk level. When the Proxmox backup client (proxmox-backup-client) processes a backup, it splits the data into variable-length chunks, just like an unencrypted backup. But before uploading each chunk to the PBS server, it encrypts the chunk payload using AES-256-GCM.

AES-256-GCM is an authenticated encryption mode. It provides both confidentiality (nobody can read the data without the key) and integrity (any tampering with the ciphertext is detected on decryption). This is the same cipher used in TLS 1.3 and most modern disk encryption implementations.

The encryption key is generated on your Proxmox VE node. It stays there. PBS never receives the key, never stores it, and has no mechanism to request it. The server stores encrypted chunks and encrypted manifests. It can track which snapshots exist and manage retention, but it cannot inspect or verify the actual backup content.

Each encrypted backup includes a key fingerprint in the snapshot metadata. This fingerprint lets PBS verify that all chunks in a backup were encrypted with the same key, without needing the key itself. If you accidentally mix keys across nodes, PBS will flag the inconsistency.

Setting Up Encryption

If you prefer the CLI or want to generate a key outside of the PVE UI:

# Generate a key without passphrase (KDF none)
proxmox-backup-client key create --kdf none /etc/pve/priv/storage/my-pbs.enc

# Or with a passphrase for additional protection
proxmox-backup-client key create /etc/pve/priv/storage/my-pbs.enc

The --kdf none option creates a key without passphrase protection. This is standard for automated backups — the key file itself is the secret. If you add a passphrase (--kdf scrypt), you'll need to provide it every time a backup runs, which breaks unattended operation.

Back Up Your Encryption Key

The paperkey command generates a human-readable, printable version of your encryption key. Print it. Store the paper in a safe. A different building than your servers.

proxmox-backup-client key paperkey /etc/pve/priv/storage/my-pbs.enc --output-format text

This outputs the key as a QR code and a series of encoded text lines. Either format can restore the key.

Additional precautions:

• Multiple geographic copies. Keep printed paper keys in at least two separate physical locations. A fireproof safe at the office and one at home, for example.
• Secure digital copy. Store an encrypted copy of the key file in a password manager or on an encrypted USB drive. Not in the same datacenter as your backups.
• Cluster awareness. In a PVE cluster, /etc/pve/ is replicated across all nodes via pmxcfs. If the cluster is destroyed, the key goes with it unless you've backed it up externally.

Master Key for Key Escrow

For environments with multiple PVE clusters or where centralized key management is a requirement, PBS supports an RSA master key setup. This is optional but worth considering for enterprise deployments.

The concept: you generate an RSA key pair (4096-bit by default). The public key is distributed to all PVE nodes. When a backup is encrypted, the backup key is itself encrypted with the RSA public key and stored alongside the backup metadata. Recovery is then possible using the RSA private key, even if the original AES encryption key is lost.

# Generate the RSA master key pair
proxmox-backup-client key create-master-key

# This creates two files:
# master-public.pem  — distribute to PVE nodes
# master-private.pem — store securely offline, NEVER on PVE nodes

# Import the public key on each PVE node
proxmox-backup-client key change --master-pubkey master-public.pem /etc/pve/priv/storage/my-pbs.enc

The private key (master-private.pem) is your recovery key. It should be stored with the same level of care as the paper key — offline, in a safe, in a separate location. The public key is safe to distribute; it can only encrypt, not decrypt.

With a master key configured, you can recover backups even if a node's local encryption key is lost: provide the master private key during restore, and PBS decrypts the backup key from the metadata, then uses it to decrypt the chunks.

This is the closest PBS gets to an enterprise key escrow system. It's not a full KMS integration, but it eliminates the single-point-of-failure that a lone key file represents.

Encrypted Backups and Sync Jobs

Client-side encryption pairs naturally with offsite sync jobs. When you sync encrypted backups to a remote PBS, the remote server receives encrypted chunks. It has no key. It cannot read your data. This is exactly the trust model you want for third-party offsite storage.

The critical flag is --encrypted-only on sync jobs. When enabled, the sync job skips any unencrypted snapshots and only replicates encrypted ones. This prevents a common mistake: a VM gets backed up without encryption (misconfigured storage, key file missing on one node), and that plaintext backup silently syncs to your offsite target.

proxmox-backup-manager sync-job create offsite-encrypted \
  --remote my-local-pbs \
  --remote-store local-datastore \
  --store offsite-datastore \
  --schedule "daily 06:00" \
  --encrypted-only true

With --encrypted-only true, any unencrypted snapshot in the source datastore is silently ignored during sync. Check the sync job task log for skipped snapshots if you suspect misconfigurations.

Restoring Encrypted Backups

Restoration requires the encryption key to be present on the machine performing the restore. PBS cannot do this for you — it doesn't have the key.

Same cluster, same storage configuration: Restores work transparently. The key is already in /etc/pve/priv/ and shared across cluster nodes via pmxcfs. Select the snapshot, click restore, done.

Cluster migration: You're moving VMs to a new PVE cluster that's connected to the same (or different) PBS. Copy the .enc key file from the old cluster's /etc/pve/priv/storage/ to the new cluster's equivalent path. Once the key is in place, restores work as normal.

Single-VM restore without cluster access: If you're restoring from a bare PVE install or outside a cluster, the PVE restore dialog will prompt for the encryption key. Provide the key file or enter the key data from your paper backup.

Master key recovery: If the original AES key is lost but you have the RSA master private key, provide the master private key during restore. PBS extracts the backup key from the snapshot metadata, decrypts it with the master key, then decrypts the backup data.

Limitations

Wrapping Up

Encryption isn't a feature you toggle on when you feel like it. For any backup leaving your network, it's the baseline. PBS makes it straightforward: generate a key, enable it on your storage, and every backup is AES-256-GCM encrypted before it touches the wire.

The one thing you cannot afford to skip is key management. Generate the paper key. Store it offline. If your environment justifies it, set up a master key pair for escrow. Then move on. The encryption itself is invisible in daily operations.

At remote-backups.com, every PBS datastore we provide works with client-side encryption out of the box. Your data is encrypted on your Proxmox host before it reaches our infrastructure. We never see your keys. We can't decrypt your backups. That's the point.