Proxmox Backup Server restore testing: what the new PBP tool automates, and what it still leaves to you

Proxmox Backup Server restore testing just got a dedicated open source tool. PBP (Proxmox Backup Proofing), published on GitHub by Breadth Security and announced on r/Proxmox on 24 October 2026, restores each guest's newest Proxmox Backup Server backup into a temporary guest on an isolated bridge, boots it, checks it from inside and writes the verdict into the backup's notes. It is Apache 2.0 licensed and one day old.

The GitHub organisation was created on 23 October 2026, the repository on 24 October, and all 13 releases up to v0.8.2 appeared the same day because the GitHub repo mirrors a private Gitea instance where development happens. The tool is written in Go. The project website names no individuals, so treat it as an early project for a lab.

Why a verify job is not a restore test

A Proxmox Backup Server verify job reads the stored backup data and confirms it is intact, and the PBS documentation recommends reverifying every backup at least monthly because physical drives degrade over time.

That answers one question: are the bytes on disk the bytes that were written? It says nothing about whether the backup boots and serves. The guest config may reference a disk excluded with backup=0, the bootloader may be damaged, a filesystem may come up read-only, or a service may depend on a mount that was never backed up. Only a restore shows that. The PBP README's framing: trust the existing verification, then prove the backup supports your disaster recovery plan.

What PBP does on each run

PBP is a small daemon that runs in a container or on a Debian host, on a cron schedule that defaults to 02:00 every day. The README lists eight steps.

Preflight checks the API token, SSH, the node helper, the Proxmox VE version and the restore storage, confirms that the proof bridge is really isolated, and cleans up anything a crashed run left behind. Discovery picks the newest backup of each guest across your PBS storages, skipping guests you exclude by VMID, range or tag. A backup that already carries a "PBP PROVEN" line is skipped unless you set reproof to true. Templates are skipped because they cannot start, and a capacity gate skips a guest when the backup does not fit in the restore storage or the node lacks free RAM.

Then the safety steps. PBP marks the backup protected so pruning cannot remove it mid-proof, restores it to the next free VMID in a range you reserved, tags the copy pbp, moves every NIC onto the isolated bridge, sets onboot to 0 and removes host passthrough devices. Anything it cannot make safe becomes an ERROR and the guest is never started.

The copy boots with a default timeout of five minutes. Inside, PBP checks the system state, failed systemd units, a read-write root filesystem, service profiles and any per-guest checks you define. Linux VMs are inspected through the QEMU guest agent, containers through pct exec, and Windows VMs by confirming that automatic-start services are running. Built-in profiles cover postgresql, mariadb and mysql, nginx and apache, docker, redis, sshd and cron. Units that only fail without a network, such as wait-online, chrony and cloud-init, are on a built-in ignore list.

Teardown always runs. The temporary guest and its disks are destroyed, the backup's original protected value is restored, the verdict goes into the backup's notes, and one summary notification is sent through your Proxmox node.

Five verdicts, and only one blames the backup

PBP records PROVEN, FAILED, BOOTED, SKIPPED or ERROR. Only FAILED means the backup has a problem. BOOTED means the guest reached running but PBP could not look inside, typically a VM without the guest agent or an unprivileged container without nesting enabled. SKIPPED and ERROR mean not proven yet.

One detail I like: when a failed unit can be traced to something the backup does not hold, such as a mount on a disk marked backup=0, PBP does not count it as a failure. It lists it under "not covered by backup" instead. That tells you a service depends on a disk your backup job is skipping, which no verify job can show.

What you need before PBP can run

Proxmox VE 9.0 or newer and Proxmox Backup Server 4.0 or newer. On the node that runs the proofs you need a PBS storage holding the backups, a restore storage with room for your largest guest, an isolated bridge with no ports and no IP, a free VMID range (the example config reserves 990000 to 990049), sudo, and a root shell once to run pbp node setup.

PBP itself needs a host that reaches the node's API on port 8006 and SSH on port 22: any machine with Docker and Compose, or a Debian-based host for the .deb package on amd64 or arm64. For production the README asks you to run PBP outside the node or cluster it checks, so its health check still fails visibly when the node is down. Running it on the node is supported for a single-node lab.

PBP never logs in to the node as root. It uses an API token with a narrow role, and SSH only as an unprivileged pbp user locked to one restricted helper command. TLS to the API is verified by fingerprint or CA file, with no option to skip it. Releases are signed.

How a homelab or small business admin would run it

The guided path has six steps: clone the repository or install the .deb, choose the VMID range and create the bridge on the node, run pbp setup on the PBP host, run the two lines it prints on the node as root, paste the reply block back, and start the daemon with docker compose up -d or systemctl start pbp.

After that, pbp check runs preflight without restoring anything, pbp run proofs every guest now, and pbp run --guest 105 proofs a single guest. Each run writes its own log folder with one file per guest; the last 30 are kept.

In a homelab with a handful of guests the default nightly schedule is fine. A small business with 30 or 40 guests should think about restore storage and RAM on the node, since a copy of a large guest competes with production. The dedicated proofing node option fits here: copies restore and boot on separate hardware, and production nodes need no helper, token or bridge.

What PBP cannot tell you yet

A boot and a passing service check prove more than a verify job and less than a full recovery drill. Application data is only checked if you write a per-guest command for it. A VM without a working guest agent, or one whose agent refuses guest-exec, gets a BOOTED verdict. By default the copy also restores onto a production node and uses its RAM and storage, so a nightly restore of your largest VM is load to schedule on purpose.

It is also a day old. The README states that PBP is written by traditionally trained developers using specification-driven, AI-assisted tooling, and the r/Proxmox post asks for feedback. Try it on a lab node first and watch the issue tracker for a few weeks before you let it near a cluster that pays the bills.

Where it fits in a Proxmox backup plan

In my Proxmox backup strategy for 2026, verification and restore tests are separate line items, and PBP automates the second one. It pairs with PBS on its own hardware and with offsite copies, which it does not touch. If your datastore sits on a NAS, the Synology iSCSI notes explain why restore speed matters in a nightly test. To compare PBS with other open source backup tools, use the open source backup Ledger or ask the backup advisor.