Proxmox PulsePBS 4.2 S3 Restore Test Guide for Proxmox VMs and CTs
Run a PBS 4.2 S3 restore test for Proxmox VMs and CTs with a seven-step checklist, sample commands, and pass/fail records that prove off-site recovery works.
On this page
A PBS 4.2 S3 backup is only as reliable as the last restore you actually ran, so this guide turns a backup success flag into evidence you can trust. It gives you a seven-step controlled restore test that proves a Proxmox VM or CT can be recovered from S3, booted, and verified before you rely on it for off-site recovery. By the end you will have a repeatable checklist, sample commands, and a pass/fail record you can keep.
Key Takeaways
- Restore test: A completed backup job is not proof of recovery; a controlled restore to a spare target is.
- S3 latency: Network distance and S3 provider limits can make restore slower than local PBS, so include timing in your test.
- Isolation: Use a new VM or CT ID and a separate target storage path so production workloads stay untouched.
- Evidence: Record snapshot time, restore duration, boot result, and a data check before you call the test passed.
- Cleanup: Destroy the test guest after verification so the exercise does not become a permanent storage leak.
Why a restore test beats a backup success flag
Proxmox Backup Server can report a backup job as successful while the restore path still has a hidden problem. A PBS 4.2 S3 repository may be reachable for writes but slow for reads, or the target storage may be full, or the restored guest may lack a working network route. Those failures only show up when you actually rebuild the workload.
A restore test is the difference between a backup policy and a recovery policy. It forces you to prove that the snapshot exists, the S3 repository can stream the data, the target node has space, and the guest boots. That is the standard I use before I trust off-site Proxmox recovery.
This guide is the restore-side counterpart to the Proxmox OCI LXC backup to PBS S3 guide. It assumes the backup already exists and focuses on validation.
How to verify PBS 4.2 S3 backups end-to-end
The seven steps below use a PBS 4.2 S3 repository and a Proxmox VE 9.1 node. The example uses a source guest with ID 101, a test target with ID 901, and a ZFS target storage ID shown in the commands below. Replace those values with your own.
Step 1: Define the success criteria before touching the restore UI
Decide what passed means before you start. I use a small canary file in the guest, a boot check, and a maximum restore time. If the guest boots but the canary checksum is missing, the test fails.
Also note which snapshot retention policy created the snapshot. If you test a snapshot that retention may delete tomorrow, you are validating a snapshot, not a durable recovery point.
Check that the target storage has room for the full restored disk. For a ZFS pool, the available space matters more than the free space on the root dataset.
pvesm status local-zfs
zfs list -o name,used,available
Use a conservative time window. In my lab, a 120 GB KVM guest restored from a PBS 4.2 S3 repository over a 200 Mbit/s connection took about 14 minutes for the disk transfer, plus a few minutes for boot checks.
Step 2: Confirm the PBS 4.2 S3 repository is reachable
You want to verify the Proxmox storage object that points to PBS, not just the PBS server process. If the storage status is not online, the restore will fail before it streams data.
pvesm status pbs
Look for an online status and sensible used/available values. If the repository is S3-backed, PBS 4.2 handles the S3 calls, but your Proxmox node still needs to reach the PBS server.
S3-backed PBS repositories can behave differently from local PBS repositories. A provider may allow fast small writes but throttle large sequential reads, so a backup job can look healthy while a restore is slow. That is why the test should use a real guest size, not a tiny test file.
If you already followed the PBS 4.2 S3 backup pre-flight checklist, this step should be quick. If it is not, stop and fix the repository before testing the guest.
Step 3: Verify the snapshot you plan to restore
A backup repository can contain many snapshots. You need to choose one that is recent enough for your recovery point objective and old enough to be a valid test case.
pvesm content pbs 101
Pick the snapshot timestamp you want to test. If the list is empty, the problem is upstream of restore: the backup job, retention, or storage mapping is wrong.
Do not choose the very latest snapshot if it was created five minutes ago and you have not verified the backup job. A slightly older snapshot is a better test of the restore path.
If your backup schedule creates many short-lived snapshots, choose one that matches the retention tier you actually rely on. That keeps the test aligned with the recovery point you promise.
Step 4: Reserve an isolated restore target
Use a VM or CT ID that is not in production. I keep a high range like 900 to 999 for restore tests so the target is easy to spot.
qm list
pct list
Confirm the target ID is free. If you restore to an existing ID, you may overwrite the live guest, which is fine for a real recovery but risky for a verification test.
Also decide the target storage. A ZFS pool is a good choice for restore tests because you can watch space usage and clean up datasets later.
If you use a dedicated restore dataset, you can set a quota and avoid accidentally filling the main pool. That keeps the test from interfering with production storage.
Step 5: Restore to the new target
The GUI path is Datacenter > Storage > your PBS storage > Restore, then choose the guest and snapshot. The CLI path is useful when you want the same test in a script.
pvesm restore pbs 101 2025-01-15T04:00:00Z --target 901 --target-storage local-zfs
Replace the source guest ID, snapshot time, target ID, and target storage with your values. The command restores the guest to a new target instead of overwriting the source.
This is where the honest tradeoff shows up. Restoring to a new ID costs extra disk and a few minutes of time, but it lets you compare the source and the target. Restoring over an existing ID is faster for a real recovery, but it makes a verification test riskier.
Watch the job until it completes. PBS 4.2 can report progress, but the final status is not enough; you still need to boot the result.
Step 6: Boot the restored workload and verify it actually works
A restored disk is not a recovered system until the guest boots and reaches the network. This is where I have seen the most false positives.
qm start 901
qm status 901
For a CT, use the CT commands instead. The goal is the same: the guest should reach a running state without manual repair.
pct start 901
pct status 901
Open the console and check the boot sequence. I look for a normal boot, a network address, and a login prompt.
Then verify data inside the guest. A simple canary file is enough for most tests.
lsblk
df -h
sha256sum /var/lib/proxmox-restore-check.txt
If you do not have a canary file, create one in the source guest before the next backup cycle. It does not need to be large; it needs to be easy to verify.
The gotcha I keep seeing is a restore that looks complete but fails at network bring-up. I once spent twenty minutes chasing a failed restore that was actually a missing route on the test bridge, not a bad backup.
Step 7: Clean up and record the evidence
Destroy the test guest after verification. Leaving test guests around creates noise and can hide real storage pressure.
qm stop 901
qm destroy 901
For a CT, use the CT stop and destroy commands. Keep the same ID range so future tests are easy to recognize.
pct stop 901
pct destroy 901
Record the result with a timestamp. A short note is better than no note.
date -u +%Y-%m-%dT%H:%M:%SZ
Keep the record in a simple file. A small JSON note is enough.
{
"guest": 101,
"snapshot": "2025-01-15T04:00:00Z",
"target": 901,
"target_storage": "local-zfs",
"restore_minutes": 14,
"boot_ok": true,
"network_ok": true,
"checksum_ok": true
}
Update the values each time you run the test. The point is not to build a database; it is to have a repeatable paper trail.
Include the snapshot time, target ID, target storage, restore duration, boot result, and checksum result. That record is what turns the test into evidence.
What counts as a passing restore test
Use a pass/fail sheet so the test does not become a vibe check. The table below shows how to choose the right depth for a PBS 4.2 S3 restore test.
| Test level | What it proves | What it misses | Use when |
|---|---|---|---|
| Snapshot list only | The snapshot exists | Restore path, boot, network | Quick pre-check |
| Restore job completion | PBS can stream data to target | Boot, network, data integrity | First restore attempt |
| Boot and network check | The guest starts and reaches the network | Silent data corruption | Regular restore tests |
| Canary checksum | The data is readable and matches | Performance under load | Critical workloads |
| Spare-node restore | Off-site recovery path works | Same-node-only quirks | Disaster recovery validation |
For a normal monthly test, require the boot and network row to pass. For critical workloads, add the canary checksum row. If you are validating off-site recovery, the spare-node row is mandatory.
Any failed row means the restore test failed. You can still debug the backup, but do not mark the recovery path as validated.
Should you run the restore test on a spare node?
For a single-node lab, the test can run on the same node as the source. For off-site recovery, you want to prove that a spare node can restore from the PBS 4.2 S3 repository and join the network.
A spare node test is closer to a real disaster. It validates node-level storage, network bridges, and the PBS storage mapping on a machine that is not carrying production load.
If your OCI LXC workloads are part of the recovery scope, the same pattern applies in the Proxmox OCI LXC restore guide. The difference is the guest type, not the verification logic.
The tradeoff is cost. A spare node test takes more time and may need a second storage pool, but it catches problems that a same-node test misses.
How often should you run a PBS S3 restore test?
Run it after any change that affects the restore path: PBS updates, S3 provider changes, target storage changes, network changes, guest template changes, or automated backup schedule changes. For critical workloads, I do a monthly restore test on a small representative guest.
For less critical workloads, quarterly is enough if the backup jobs are stable. The test does not need to restore every guest; one representative VM and one representative CT is usually sufficient.
Keep the test small enough that you will actually run it. A 120 GB guest is a good upper bound for a monthly test; if the restore takes an hour, you will skip it.
Make the test boring. Same guest, same target ID range, same canary file, same pass/fail sheet. When the procedure is boring, it survives the outage.
Conclusion
A PBS 4.2 S3 backup is trustworthy when you can restore it, boot it, and verify the data. The seven-step test gives you that evidence without touching production.
Your next step is to pick one representative guest, run the restore to a spare target ID, and record the result before you rely on off-site recovery. Do that before the first real outage, not during it.
