PBS has been backing up every VM, container, and physical Windows PC in this homelab for months — daily, unattended, mostly invisible when it's working. This is the honest verdict after actually needing it for real recoveries, not just watching green checkmarks: where it earns real trust, and two sharp lessons that came from things going wrong in ways a fresh install would never warn you about.
The core value proposition holds up completely: real deduplication and compression across backups (not just within one), incremental-forever storage that doesn't balloon the way naive full backups do, and a restore experience that's genuinely simple — browse snapshots, pick one, go. It backs up more than just Proxmox's own VMs and containers too; with the right client, a physical Windows PC can land in the same datastore (see our full PBS setup guide for that whole story, including the real permission gotchas). Running it for months across a genuinely mixed fleet — Linux containers, Windows machines, cloud droplets — it hasn't once failed to actually have the data when asked for it.
keep-last=1-style retention policy doesn't just clean up old backups — it can
delete the second-most-recent one the instant a new one lands, if that backup doesn't happen to
sit on a day/week/month/year retention boundary. This isn't a bug; it's the policy working exactly as
configured. It's also exactly the kind of thing that bites you at the worst possible moment.
Here's how, for real: mid-recovery on a VM that needed rolling back, a manual "just to be safe" backup
was taken before attempting the rollback. That backup completing triggered the fleet's keep-last=1
policy — and it immediately, permanently deleted the exact backup the rollback needed, minutes
after it had been taken. Checked the datastore directly afterward: the snapshot directory was genuinely
gone, not just delisted. No offsite copy existed yet either. The fix going forward was widening the
policy (multiple keep-last/daily/weekly/monthly slots instead of one), but the specific backup lost that
day stayed lost.
The lesson generalizes past this one policy: "I'll take a quick backup first, just to be safe" is not automatically a free safety net if your retention policy is aggressive — check what a new backup landing will actually do to the ones already there before assuming it's harmless. And a related, separate trap from the same incident: restoring an old backup can silently undo real, meaningful events that happened after it, even when the restored system looks perfectly healthy on every visible check. Before restoring anything stateful, ask what happened between the backup's timestamp and now — a healthy heartbeat after restore doesn't mean nothing was lost.
The practical rule this earns: once a restore or any operation that mutates a VM/container's config or disk is running, let it finish. Don't send it a cancel signal assuming "worst case, nothing happens" — and if one does get cut off for any reason, check the resulting config immediately rather than assuming things are back to how they were before you started. They might not be.
PBS Community Edition has no true WORM/immutable-storage mode — nothing stops someone (or something) with real access to the datastore from deleting a backup outright, retention policy or not. That's a real gap if your threat model includes a compromised backup server itself, not just protection against accidental deletion or a ransomware event on the systems being backed up. The honest mitigations available at this tier: scope any remote-sync credential to write-only (see our offsite replica guide for the real setup), and understand that's a meaningfully lower bar than genuine immutability — don't assume upgrading to a paid tier of the same tool closes this gap either; check the specific product's actual feature list rather than assuming "paid" always means "more secure."
PBS earns its keep as the backup backbone of a real, actively-used homelab — the dedup/compression story is genuinely good, restores are simple when you need them, and it scales to a mixed fleet of VMs, containers, and even physical Windows PCs without becoming its own maintenance burden. But treat two things as non-negotiable operational discipline rather than "the software will handle it": know exactly what your retention policy does to the backup that already exists before a new one lands, and never assume cancelling a running restore is free. Both lessons here came from real incidents, not hypotheticals — and both would have been invisible right up until the moment they mattered.