I had a 600 GB vzdump tarball that took 2 hours to verify and 4 to restore, and that's when I finally moved to PBS. For about a year before that I'd been doing the thing every Proxmox admin does at some point: nightly vzdump --mode snapshot --compress zstd to an NFS share on a Synology, ZFS snapshots on the local pool, and a vague feeling that this was "good enough." It was not good enough. The tarballs ballooned, the NFS share filled up, and the one time I actually had to restore a VM (a kernel update on a Plesk box went sideways), I sat there for four hours watching a progress bar and questioning my life choices.
A weekend later I had Proxmox Backup Server running on a small box in the corner. Now it's the thing I trust more than any other piece of my infra. Writing it down before I forget the ten-minute version.
TL;DR
# 1. Boot PBS ISO on a separate box (or VM on a separate host), install like Debian.
# 2. On PBS: create a datastore on a ZFS pool.
# 3. On PVE: Datacenter -> Storage -> Add -> Proxmox Backup Server.
# Paste fingerprint from `proxmox-backup-manager cert info`.
# 4. First backup:
vzdump 101 --storage pbs --mode snapshot
# 5. Set a prune policy + weekly verify. Done.
What PBS gives you that vzdump doesn't
vzdump produces a tarball (or an LZO/zstd compressed one). Each backup is a complete copy of the VM. If your VM is 50 GB and you keep 14 dailies, you're storing ~700 GB. Compression helps, but the tarball is still opaque — you cannot pull a single file out of it without restoring the whole thing into a temp location.
PBS does five things that fundamentally change the deal:
- Content-addressed deduplication. PBS chunks every disk image into ~4 MB blocks, hashes each chunk, and stores it once. If three VMs all run Ubuntu 22.04, the OS chunks exist on disk exactly once. My backup datastore for ~30 VMs sits at about 1.8 TB of "logical" data on 380 GB of actual chunkstore. Roughly 5x dedup ratio, sometimes higher.
- Incremental forever. After the first backup, only changed chunks get uploaded. A nightly backup of a quiet 200 GB VM takes 30 seconds and writes maybe 200 MB of new chunks. There is no "full + incremental + differential" dance — every backup is a full restorable snapshot from PBS's point of view, but the network and disk cost is incremental.
- Verify. PBS can re-read every chunk of a backup and check the SHA-256 against the index. If a disk goes flaky and silently corrupts a chunk, verify tells you. vzdump tarballs? You get a checksum on the whole thing, which is fine, but verifying it means reading the whole tarball, which on slow NFS is brutal.
- Client-side encryption. You generate a key, the chunks get encrypted before they leave the PVE host. If your PBS box gets stolen or the offsite sync target is compromised, the chunks are useless without the key. vzdump-to-NFS gives you exactly zero of this.
- Namespaces and granularity. Multiple PVE clusters, multiple tenants, prune policies per namespace. And you can mount a VM backup and pull individual files out — no full restore needed. This is the killer feature and I'll come back to it.
Install: bare metal or a VM somewhere else
PBS is a Debian-based distro with its own ISO, separate from PVE. Two reasonable options:
Option A: small dedicated box. I use a refurbished HP MicroServer Gen10+ with four 4 TB drives in ZFS RAIDZ1. ~$400 all in. This is the right answer if you have the rack space.
Option B: VM on a host that is not part of the PVE cluster you're backing up. Read that again. PBS-as-a-VM on the same node it's backing up is a pretend backup — see gotcha #1. If you only have one Proxmox box, put PBS on an old NUC, a Pi 4 with a USB SSD (slow but works for small datastores), or a cheap Hetzner dedicated server.
Install is uneventful: download the ISO from enterprise.proxmox.com (it's free, the "enterprise" naming is misleading), boot, click through, pick a disk for the OS. If you're on ZFS, the installer will set up the boot pool for you. The data pool — where the chunkstore lives — should be a separate ZFS pool you create after install:
zpool create -o ashift=12 backup mirror /dev/sdb /dev/sdc mirror /dev/sdd /dev/sde
zfs set compression=zstd backup
zfs set atime=off backup
proxmox-backup-manager datastore create main /backup/datastore
ext4 works too, but you give up snapshots, scrub, and compression. Don't do that unless you have to.
Wire PBS to PVE
On the PBS web UI (port 8007), create a user — backup@pbs with a strong password — and give it the DatastoreBackup role on your datastore. Grab the fingerprint:
proxmox-backup-manager cert info | grep Fingerprint
On the PVE side: Datacenter → Storage → Add → Proxmox Backup Server. ID pbs, server IP, datastore name, username backup@pbs, password, paste the fingerprint. Tick "Encryption" and let PVE generate a key — and download it immediately. Save it in your password manager. Lose it and your backups become noise.
If you also want to back up things that aren't VMs — say, a Plesk server's /var/www, or a bare-metal nginx box — install proxmox-backup-client (it's in the PBS apt repo) and run it directly:
proxmox-backup-client backup www.pxar:/var/www \
--repository backup@pbs@pbs.local:main
This is the same protocol PVE uses, same dedup, same encryption. I back up a couple of non-Proxmox boxes this way and it works great.
First backup, first restore, file-level restore
In the PVE UI, pick a VM, Backup → Backup Now, storage pbs, mode snapshot, compression off (PBS handles it). First run takes a while — it's uploading every chunk. Subsequent runs are quick.
Restore: in the PBS storage view in PVE, find the backup, click Restore. You can restore to a new VMID, which is what you want for testing — never overwrite the original on the first try.
The thing that sold me on PBS is file-level restore. Click a backup, click File Restore, and PBS spins up a tiny helper VM that mounts the disk image read-only and lets you browse it in the web UI. Click a file, download it. I have used this maybe 20 times to recover a config someone deleted, and every single time it has felt like a cheat code compared to "restore the whole 80 GB VM to a temp slot and SSH in."
Prune policy and verify
A prune policy is a set of "keep" rules. Mine:
keep-last: 3
keep-daily: 7
keep-weekly: 4
keep-monthly: 6
That's about 20 backup points across half a year, and thanks to dedup the storage cost is laughably small. Set it per-datastore in the PBS UI, then schedule a daily prune job and a daily garbage collect (GC actually frees the chunks no longer referenced by any backup).
Verify: schedule it weekly. PBS reads every chunk of every backup and re-hashes. On a healthy ZFS pool with ~2 TB of chunks it takes a few hours and runs in the background. If it ever fails, you find out before you need that restore.
Gotchas
- PBS on the same host you're backing up is not a backup. If the host dies — power supply, mobo, fire, ransomware on the hypervisor — you lose the VMs and the backups. PBS must live on different hardware. A VM on a separate node in the same cluster is acceptable; a VM on the same node is theater.
- The chunkstore on slow disks is unusable. GC and verify are random-IO heavy. SMR drives, USB-2 enclosures, single old spinning rust — you'll watch a verify take 24 hours and the box's load average sit at 30. Mirrored 7200 RPM CMR drives are the floor. SSD or NVMe for the chunkstore is great if you can afford it.
- Lose the encryption key, lose the backups. There is no recovery, no master key, no Proxmox support phone number that can decrypt them. Print the key, put a copy in a fireproof box, store another in a password manager, store another with someone you trust. Three copies. I'm not joking.
- 3-2-1 still applies. PBS in your basement is one copy. Set up a sync job to a second PBS — Hetzner, a friend's house, an OVH box — and you get offsite. Sync is incremental and encrypted in transit, and the second PBS only ever sees encrypted chunks if you set it up that way. Without offsite, a house fire is still a total loss.
A few related posts on this site if you want adjacent context: my Proxmox cloud-init template post covers the VM side of the equation, and the restic-to-S3 writeup is what I use as a complement for non-Proxmox stuff — laptops, dev boxes, anything where pulling in the PBS client is overkill.
Why I run it
I run PBS because the day I needed it, it worked. A VM I'd been ignoring for months ate its own filesystem during a botched apt upgrade, and 11 minutes after I noticed I had it back from the previous night, file-level-restored two configs from a backup three weeks old to compare what had drifted, and was back to ignoring the VM. Total time including the "let me actually read what PBS is doing" tab: under 15 minutes.
vzdump tarballs are fine for a homelab where you'll happily rebuild from scratch. The moment you have anything you cannot afford to lose four hours rebuilding, PBS pays for itself the first time you use it. Set it up, set up the offsite sync, write down the encryption key in three places, and forget about it until the day you need it.
