Everyone's backups work until the first real restore. Then the dashboard goes green, the ticket gets escalated, and someone discovers the datastore was a single consumer SSD that had been silently corrupting chunks for a year and a half. Eighteen months of nightly PBS jobs, zero restore tests, and a retention policy that had pruned the last known-good snapshot three weeks before the incident.
This is for senior sysadmins and security engineers running Proxmox VE in production who already have PBS installed and want to stop treating it as a checkbox. After reading, you'll understand what PBS "incremental" actually means at the storage layer, how to size and lay out a datastore that survives an audit, and how to build an automated restore-test harness that proves your guests boot — because PBS proves nothing of the sort.
Scope: PBS 3.x/4.x, PVE 8.x, and working familiarity with proxmox-backup-client, proxmox-backup-manager, qm, and pct. If those mean nothing to you, this article will hurt.
:::note[TL;DR]
- PBS "incremental" is content-defined chunk dedup across the whole datastore — not a disk delta. Design storage for it.
- Client-side encryption is non-negotiable; the key lives with you, not on the PVE host.
- Verification checks chunk hashes against indexes. It does not prove your VM boots. Restore testing does.
- Automate restore-to-scratch-VM on a schedule, emit Prometheus metrics, and page on failure — or you have rumors, not backups. :::
Prerequisites
- Proxmox VE 8.x cluster with
qemu-guest-agentinstalled in every guest you intend to back up. - Proxmox Backup Server 3.x/4.x with at least one ZFS-backed datastore.
- A dedicated restore-test PVE node (or an isolated bridge/VLAN on an existing node) with scratch VMID range reserved (e.g., 9000–9099).
-
proxmox-backup-client,jq, andcurlon the restore-test node. - Prometheus + Alertmanager (or your equivalent) reachable from the PBS host.
Why PBS Incremental Is Not Your Old rsync Script
If you think "incremental" means "diff of the VM disk," you will size your datastore wrong and then wonder why GC is rewriting indexes into a full filesystem. PBS incremental is a property of the storage layer, not a delta of the guest.
Chunking, Dedup, and What "Incremental" Actually Means Here
PBS splits every backup stream into variable-length chunks using content-defined chunking (a rolling hash, not fixed-size blocks). Each chunk gets hashed, and if the hash already exists in the datastore, the chunk is not written again — only the new per-snapshot index file references the existing chunk. Dedup is global: across snapshots, across guests, across time. That's the feature.
It's also a footgun. One corrupted chunk can invalidate every snapshot that references it, which is why verification and ZFS checksums are not optional. The index file per snapshot is small; the chunk store is the thing you protect.
What Gets Sent Over the Wire vs. What Lives on Disk
On the PVE side, the dirty bitmap tracks changed extents since the last backup. Those extents get chunked and hashed, and only chunks whose hashes are absent from the datastore are uploaded. First backup of a 500 GB VM is expensive; the second is cheap only if the guest churns slowly. A database writing 200 GB/day will not be cheap, no matter what the marketing deck said.
Datastore Creation With Sensible Defaults
⚠️ TRUNCATED VERSION
This is an abbreviated cross-post. Full article (all config files, architecture diagrams, images): valtersit.com
🛠️ Partner Tools for Developers
ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.
Top comments (0)