Proxmox Backup Server: Deduplicated, Encrypted VM Backups for Production

Why Backups Need More Than a Full Copy

In a production Proxmox VE cluster you often have dozens of VMs that share the same base OS, libraries, and application stacks. Backing each one up as a full image quickly consumes storage and bandwidth. The real problem is how to keep the data safe while keeping the cost and operational overhead low.

Proxmox Backup Server (PBS) – The Architecture That Solves It

PBS is a dedicated backup appliance that sits on a separate node or storage device. It stores data in a chunk‑based deduplication store. Every backup is split into 4 MB fixed chunks; if a chunk already exists in the store it is referenced instead of written again. The store is backed by a file system such as ZFS, LVM‑thin, or an NVMe array. Because the same chunk can belong to many VMs, the effective size of a repository can shrink 60–90 % for typical workloads.

All data is encrypted client‑side with AES‑256‑GCM. The encryption key is derived from a user‑provided passphrase or a randomly generated key that is kept in the Proxmox VE keyring. The PBS server never sees the plain data; losing the key renders the backup unreadable.

Key Components

• Repository – the storage location (/store in the example) where chunks and metadata live.
• Chunk Store – the physical file system that holds the deduplicated data.
• Catalog (SQLite) – a lightweight database that indexes chunks, jobs, and retention.
• Prune Job – a scheduled cleanup that removes old chunks based on retention policies.

Creating a Backup Job with Encryption

Below is a minimal example that shows the command you would run on a Proxmox VE node to back up VM 100 to a PBS repository called /store. The --crypt-mode encrypt flag forces client‑side encryption.

# Run on Proxmox VE host (root or user with backup permissions)
proxmox-backup-client backup vm:100 \\
  --repository user@pbs:/store \\
  --crypt-mode encrypt \\
  --compression lz4 \\
  --max-parallel 4

After the first run you will see a full backup. Subsequent runs only send changed chunks, which dramatically reduces the amount of data transmitted over the network.

Where the Key Lives

The key for the job is stored in /etc/pve/priv/backup/ on the Proxmox VE node. It is protected by the node’s root password and can be exported to a password manager for disaster recovery. If you lose the key file and have no passphrase backup, the data is gone forever.

Retention Policies and Prune Jobs

PBS supports granular policies: keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, and keep-yearly. You set them in the backup.conf file or via the web UI.

# Example policy for 7 daily, 4 weekly, 12 monthly, 1 yearly
policy {
  keep-last 1
  keep-daily 7
  keep-weekly 4
  keep-monthly 12
  keep-yearly 1
}

Prune runs are I/O intensive because they rewrite the chunk index and reclaim space. Use the --dry-run flag to preview what will be removed:

proxmox-backup-manager prune --dry-run

Schedule the prune in a maintenance window or set a lower I/O priority with ionice to avoid saturating your storage during peak hours.

Restore Options – Full VM, Cross‑Node, and File‑Level

Restoring a VM is as simple as pointing the Proxmox VE node to the PBS repository. PBS can restore to the original node, a different node, or even a different storage type (ZFS to LVM‑thin, etc.). The restore process re‑assembles the required chunks and writes them to the target storage.

For a quick file‑level recovery you can mount a snapshot via FUSE without launching a full VM:

# Mount snapshot of VM 100 taken on 2024‑01‑15
proxmox-backup-client mount \\
  --repository user@pbs:/store \\
  --snapshot vm/100/2024-01-15T03:00:00Z \\
  /mnt/restore

After mounting, you can copy or edit individual files directly. Unmount when done:

fusermount -u /mnt/restore

Synthetic Full Restores

PBS’s catalog keeps a chain of incremental changes. When you request a full restore, PBS can synthesize a full snapshot from the last full backup plus all incremental deltas, without re‑reading every chunk from the store. This speeds up restores and reduces I/O.

Trade‑Offs and Practical Limitations

• Guest‑side Encryption: If a VM’s disks are encrypted with LUKS or BitLocker, the ciphertext is random and deduplication becomes ineffective. Prefer PBS‑level encryption.
• I/O Load During Prune: On HDD‑backed stores, prune can saturate disk IOPS. Use SSD or NVMe for the chunk store or schedule prune during low‑usage periods.
• Key Safety: PBS does not escrow keys. Store the key file in a secure password manager and keep an offline backup of the passphrase.
• Off‑Site Replication: PBS does not replicate automatically. Use rsync or zfs send to copy the chunk store to a secondary site and verify integrity manually.
• Catalog Size: Extremely large repositories (>100 TB) may slow down the SQLite catalog. Consider splitting repositories by tenant or site in PBS 3.x.

Checklist for Production Adoption

1. Deploy PBS on dedicated hardware with ECC RAM and a resilient storage backend (ZFS RAID‑Z2 or NVMe).
2. Configure a backup job with --crypt-mode encrypt and store the key securely.
3. Set a retention policy that balances compliance and storage cost.
4. Schedule prune jobs during maintenance windows and monitor I/O.
5. Test restores quarterly on a staging cluster to verify catalog integrity and key availability.
6. Implement off‑site replication of the chunk store and verify checksums.
7. Document key recovery procedures and store passphrases in a password manager.

By following this pattern you get the storage savings of deduplication, the security of client‑side encryption, and the flexibility of instant file‑level restores—all while keeping operational complexity manageable.