PBS architecture: chunk store, dedup, encryption

Why this matters in production

PBS’s design determines what kinds of failures you can recover from, how much storage you need, and what the security model looks like. This lesson teaches the internals so you can reason about PBS confidently.

High-level architecture

flowchart LR
  PVE1[PVE node 1] -->|backup stream| PBS[Proxmox Backup Server]
  PVE2[PVE node 2] -->|backup stream| PBS
  PBS -->|sync| PBSo[Off-site PBS]
  PBS --> DS[Datastore on ZFS]

A PBS deployment has:

• The PBS daemon (proxmox-backup-proxy, proxmox-backup).
• One or more datastores (each backed by a directory or ZFS volume).
• Optional: PBS clients (other hosts, including PVE nodes) push backups to it.
• Optional: sync to a remote PBS for off-site.

The chunk store

PBS stores backups as a set of chunks — fixed or variable-length blocks of data, each identified by a cryptographic hash (SHA-256).

flowchart LR
  A[VM disk image] --> C1[Chunker]
  C1 --> CH[Chunks with hashes]
  CH --> STORE[(Chunk store)]

The chunker:

• Reads the input stream.
• Splits it into chunks using a rolling hash (similar to rsync).
• Each chunk is identified by its SHA-256 hash.
• Identical chunks are stored only once (deduplication).

Fixed-size vs dynamic chunks

PBS uses dynamic-size chunks. A small change in the input shifts the chunk boundaries, which means unchanged regions often remain as the same chunks. This is why PBS achieves very high dedup ratios for VM backups.

Deduplication

Because chunks are addressed by hash:

• Two backups with identical content share chunks.
• Backups of similar VMs (same OS, same applications) deduplicate heavily.
• The dedup ratio is often 10–20× for fleets of similar VMs.

Encryption

PBS supports client-side encryption. The client (e.g., PVE node) encrypts each chunk before sending it to PBS. PBS stores ciphertext + hash; it cannot decrypt without the client’s key.

Two modes:

• Key files: stored in /etc/pve/priv/ (cluster-wide) or in PBS itself.
• Master keys: a key-encryption-key (KEK) encrypts per-backup keys, stored in a separate location.

flowchart LR
  A[VM data] --> C[Chunker]
  C --> CH[Chunks]
  CH --> ENC[Encrypt with key]
  ENC --> STORE[(Encrypted chunk store)]
  ENC --> HK[Hash + index]

Verification

PBS can verify stored chunks against the original hashes. This detects:

• Silent corruption in storage.
• Bit-rot in the chunk store.
• Tampering.

Scheduled verification jobs iterate the chunk store and re-check hashes. The cost is read-heavy I/O during the verification window.

proxmox-backup-manager verify list

Garbage collection

When backups are deleted (or pruned), the chunks they referenced become orphans. Garbage collection removes them, freeing storage.

proxmox-backup-manager gc list

GC runs on a schedule. It can also be run manually:

proxmox-backup-manager gc run <datastore>

Backup verification: a critical capability

PBS can:

• Verify the integrity of stored chunks.
• Restore backups to a separate, isolated network for testing.
• Verify that a backup can actually be restored (not just that the chunks are intact).

The last capability is what makes “tested restore” possible. Run a monthly restore drill.

Production considerations

Common mistakes

• Storing backups on the same ZFS pool as live VM data.
• Forgetting to back up encryption keys.
• Disabling verification “to save I/O.”
• Running GC during peak hours (it is read-heavy).

Key takeaways

• PBS uses chunked, hashed, deduplicated storage.
• Client-side encryption means losing the key loses the backups.
• Verification and restore drills are the difference between “backed up” and “recoverable.”

Knowledge check