How PBS Encryption Affects Deduplication

You enabled encryption on your Proxmox Backup Server datastore. Your dedup ratio dropped. Now you're wondering if encryption "breaks" deduplication. It doesn't. But your key management strategy determines how far deduplication can reach. This post explains exactly why.

How PBS Deduplication Works

Proxmox Backup Server uses content-addressable storage. Every backup is split into variable-length chunks using a content-defined chunking (CDC) algorithm. The chunking boundaries are determined by the data itself, not by fixed offsets. This means inserting 10 bytes at the start of a file doesn't shift every chunk boundary downstream.

Each chunk gets a SHA-256 hash. If that hash already exists in the datastore, PBS skips the upload. The existing chunk gets a new reference instead. One chunk, stored once, referenced by hundreds of snapshots.

This chunking and hashing happens on the client side, inside the proxmox-backup-client process on your Proxmox VE node. The client checks with the server which chunks already exist before uploading. Only new, unique chunks cross the wire.

Deduplication in PBS is per-datastore. Chunks are not shared across datastores. Two datastores on the same PBS instance maintain completely separate chunk stores. This matters when designing your datastore layout and planning multi-tenant architectures.

How PBS Encryption Works

PBS uses AES-256-GCM for client-side encryption. The encryption key lives on your Proxmox VE node at /etc/pve/priv/storage/<STORAGE-ID>.enc. The PBS server never sees the key.

The encryption pipeline looks like this:

1. The backup client splits data into chunks (CDC algorithm)
2. Each chunk is encrypted with AES-256-GCM using your key
3. The encrypted chunk is hashed (SHA-256)
4. The hash is checked against the datastore's chunk index
5. If the hash is new, the encrypted chunk is uploaded

The critical detail: PBS uses deterministic encryption for a given key. Same plaintext chunk plus same key produces the same ciphertext every time. This is what makes deduplication possible with encryption enabled.

For the full setup walkthrough, see our PBS client-side encryption guide.

The Key Factor: Same Key = Dedup Works

This is the core insight most people miss. Encryption doesn't destroy deduplication. Key diversity does.

When every node encrypts with the same key, identical plaintext chunks produce identical ciphertext. Identical ciphertext produces identical SHA-256 hashes. Identical hashes mean PBS deduplicates them. The dedup ratio stays the same as without encryption.

When nodes use different keys, the same plaintext chunk produces different ciphertext per key. Different ciphertext means different hashes. PBS treats them as unique chunks. Deduplication across those nodes is gone.

The "Dedup Across VMs" column assumes VMs on the same node (same key). VMs on different nodes with different keys follow the "Across Nodes" column.

When Different Keys Make Sense

Not every environment should share a single key. Sometimes isolation is the priority, and the storage overhead is acceptable.

Multi-tenant / MSP environments. If you manage backups for multiple clients on the same PBS infrastructure, each client needs their own encryption key. Client A should never be able to decrypt Client B's data, even theoretically. Per-client datastores with per-client keys is the standard approach. See our MSP multi-tenant guide for the full architecture.

Regulatory compartmentalization. Some compliance frameworks require cryptographic separation between data classes. Healthcare and finance environments may need different keys for different data tiers, even within the same organization.

Zero-trust internal boundaries. If your organization treats each department or business unit as a separate trust domain, per-unit keys enforce that boundary at the backup layer.

In all these cases, you accept reduced cross-boundary dedup as the cost of true data isolation. Within each key boundary, deduplication still works normally.

Practical Recommendations

Single Organization, Multiple PVE Nodes

Share the encryption key across all nodes. In a PVE cluster, this happens automatically. The key at /etc/pve/priv/storage/<STORAGE-ID>.enc lives inside pmxcfs, the cluster-aware filesystem. Every node in the cluster has access to the same key.

# Run on each node - the fingerprint should match
proxmox-backup-client key show /etc/pve/priv/storage/my-pbs.enc

For standalone PVE nodes (not in a cluster) backing up to the same PBS datastore, manually copy the .enc key file to each node. Keep the path identical so backup jobs reference the same key.

Multi-Tenant Environments

Use separate datastores per client, each with their own encryption key. Accept per-tenant deduplication only. The storage overhead is the price of proper isolation. Don't try to share keys between tenants to save disk space.

Monitor Your Dedup Ratio

Check the dedup factor in the PBS web interface under Datastore > Summary. The "Deduplication Factor" shows how effectively chunks are being shared.

proxmox-backup-manager datastore list --output-format json-pretty

If your dedup ratio drops after enabling encryption, check whether all nodes are using the same key. A sudden drop usually means one node generated a new key instead of using the shared one.

Wrapping Up

Encryption doesn't break Proxmox Backup Server deduplication. Key management does. Same key across all nodes gives you the same dedup ratios as unencrypted backups. Different keys per node or per tenant limits dedup to each key boundary. For single-org setups, share the key. For multi-tenant environments, accept the overhead. Either way, monitor your dedup factor in the PBS UI and investigate any unexpected drops.