PBS has been backing up every VM, container and physical Windows PC in this homelab for months. Daily, unattended, mostly invisible when it works. This is the honest verdict after needing it for real recoveries, not just watching green checkmarks. Where it earns trust, and two sharp lessons that came out of 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 does not balloon the way naive full backups do. A restore experience that is genuinely simple. Browse snapshots, pick one, go. It backs up more than Proxmox's own VMs and containers too. With the right client a physical Windows PC lands in the same datastore. Our full PBS setup guide covers that whole story, including the real permission gotchas. Months across a genuinely mixed fleet of Linux containers, Windows machines and cloud droplets, and it has not once failed to have the data when asked for it.
keep-last=1 style retention policy does not just clean up old
backups. It can delete the second-most-recent one the instant a new one lands, if that
backup does not sit on a day, week, month or year retention boundary. This is not a bug. It is the policy
working exactly as configured. It is also exactly the kind of thing that bites you at the worst possible
moment.
Here is how, for real. Mid-recovery on a VM that needed rolling back, a manual "just to be safe" backup was
taken first. That backup completing triggered the fleet's keep-last=1 policy. It immediately and
permanently deleted the exact backup the rollback needed, minutes after it had been taken. I 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, with multiple keep-last, daily,
weekly and monthly slots instead of one. 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 a free safety net if your retention policy is aggressive. Check what a new backup landing does to the ones already there before you assume it is harmless. The same incident carried a second trap. Restoring an old backup can silently undo real events that happened after it, even when the restored system looks perfectly healthy on every visible check. Before you restore anything stateful, ask what happened between the backup's timestamp and now. A healthy heartbeat after a restore does not mean nothing was lost.
The rule this earns is simple. Once a restore, or any operation that mutates a VM or container's config or disk, is running, let it finish. Do not send it a cancel signal assuming worst case nothing happens. If one does get cut off for any reason, check the resulting config immediately. Do not assume things are back to how they were before you started. They might not be.
PBS Community Edition has no true WORM or immutable-storage mode. Nothing stops someone, or something, with real access to the datastore from deleting a backup outright, retention policy or not. That is a real gap if your threat model includes a compromised backup server itself, rather than just accidental deletion or ransomware on the systems being backed up. The mitigations at this tier are honest but limited. Scope any remote-sync credential to write-only, which our offsite replica guide covers in full. Understand that is a meaningfully lower bar than genuine immutability. Do not assume a paid tier of the same tool closes the gap either. Check the product's actual feature list instead of assuming "paid" means "more secure".
PBS earns its keep as the backup backbone of a real, actively used homelab. The dedup and compression story is genuinely good. Restores are simple when you need them. It scales to a mixed fleet of VMs, containers and physical Windows PCs without becoming its own maintenance burden. Treat two things as non-negotiable 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. Never assume cancelling a running restore is free. Both lessons came from real incidents, not hypotheticals, and both were invisible right up until the moment they mattered.