A mid-sized shop I worked with ran 18 months of "successful" nightly backups. Every job exited 0. Every dashboard was green. Then ransomware hit, they reached for the backups, and discovered the datastore had been silently corrupting chunks for months — the underlying disk had been throwing write errors that the verify jobs (which they'd never scheduled) would have caught. Eighteen months of green checkmarks, zero recoverable data. The post-mortem was short: nobody had ever restored a single VM.
Proxmox Backup Server (PBS) is genuinely good infrastructure. The content-addressed chunk store deduplicates well, the QEMU dirty-bitmap integration makes incrementals cheap, and the verify tooling exists. But "backup job exited 0" is not a restore test, and PBS won't test restores for you unless you build the pipeline. This guide covers both halves: getting the incremental/dedupe model right, and automating the restore verification that nobody wants to do manually.
This is written for the sysadmin or platform engineer who already has PBS running (or is about to) and wants it to survive contact with an actual incident. By the end you'll have a working restore-test script, sane GC/prune retention, an encryption key strategy that doesn't brick your recovery, and the five alerts that precede data loss.
:::note[TL;DR]
- PBS incrementals rely on QEMU dirty bitmaps — a lost bitmap means a full backup, so schedule with headroom, not at 99% of the window.
- Prune marks, GC reclaims. If GC never runs outside the backup window, your datastore fills up and you find out at 3 AM.
- The encryption master key is a single point of total loss. Escrow it offline or you have no backups, only ciphertext.
- "Verify" checks chunk integrity, not recoverability. Automate a full VM boot test on an isolated bridge — that's the only proof that matters.
- Pull-sync to offsite from the offsite side. A compromised primary should never be able to delete your offsite copy. :::
Prerequisites
- Proxmox VE 8.x and Proxmox Backup Server 3.x (check the official docs for current versions — the API surface is stable but flags evolve).
- A PBS datastore with at least one backup job configured and one snapshot present.
- Root or
DatastoreAdminaccess on both PVE and PBS. -
proxmox-backup-clientinstalled on any host that will run restore tests (it ships with PVE). - An isolated bridge or VLAN on your PVE cluster for boot tests — no uplink, no DHCP to production.
- A Prometheus + Alertmanager stack if you want the monitoring section to be more than reading comprehension.
Why PBS Beats Your rsync/ZFS-send Script (And Where It Doesn't)
PBS is a content-addressed, chunk-based deduplicating store — not a file copier. It splits VM disk images into fixed-size chunks, hashes them, and stores each unique chunk once. A second VM with the same OS install dedupes against the first almost entirely. That's the whole value proposition, and it's why the "I'll just rsync the raw disks" crowd has an RTO measured in days, not hours: raw disk copies don't dedupe, don't do incrementals without snapshot gymnastics, and restore at disk speed.
Fixed chunks, dirty bitmaps, and what "incremental" actually means
⚠️ 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)