PBS 4.2 S3 Restore Test for Proxmox VE 9.2 Upgrade

If you are preparing a Proxmox VE 9.2 upgrade, a targeted PBS 4.2 S3 restore test is the quickest way to prove that your backup chain still works before you change the hypervisor and immediately after it. Run one small VM and one small container restore from the same PBS S3 datastore on both sides of the upgrade, and you get a clear pass/fail signal for authentication, storage access, object-store latency, and guest boot behavior.

Key Takeaways

• Before upgrade: Establish a baseline while Proxmox VE is still on the known-good version.
• After upgrade: Restore the same PBS S3 backup to prove VE 9.2 can still read it.
• Keep it small: One 8 to 12 GiB VM and one small container are enough for a meaningful test.
• Measure time: Record restore duration and boot time, not just success or failure.
• Use disposable IDs: Restore to spare IDs so production resources stay untouched.

Why PBS 4.2 S3 Restore Tests Matter for VE 9.2

A successful backup job is not proof. It only proves that Proxmox VE wrote data to Proxmox Backup Server and that PBS accepted it. A restore test proves the reverse path: VE can authenticate to PBS, list the S3-backed datastore, fetch chunks, rebuild the disk or archive, and boot the result.

VE 9.2 can touch parts of that path even when PBS 4.2 stays unchanged. Package updates may replace the Proxmox Backup client library, storage plugin, TLS trust store, network stack, or QEMU/KVM bits that affect VM restore and boot. An S3 endpoint that was reachable yesterday can fail after a certificate, proxy, firewall, or DNS change.

A backup job also writes manifests, chunk files, and index files in a different order than a restore reads them. Restore validates more of the chain, including object listing, chunk integrity, target storage allocation, and guest startup. Those are separate failure modes.

If the PBS S3 datastore sits behind an object store, latency can also change without PBS throwing an obvious error. A restore that used to take three minutes can take fifteen because the client is negotiating TLS per object or fetching many small chunks. If you have not already mapped normal behavior, the PBS 4.2 S3 Backup Monitoring with Datacenter Manager view can help separate queue time from object-store latency.

What Counts as a Targeted Restore Test?

Targeted does not mean a full datacenter disaster recovery drill. It means a repeatable restore that exercises the parts most likely to break during a VE 9.2 upgrade.

Pick the right candidates

• One KVM VM with virtio disk, guest agent, and a normal Linux boot path.
• One systemd LXC container, because container restore tests archive unpacking, device nodes, and systemd startup.
• One resource that restores to a target storage type you actually use, such as local-lvm or local-zfs, because target selection can fail before PBS is even involved.
• One resource that lives in a PBS namespace if you use namespaces, not only the default namespace.

Pick small but not trivial. I like an 8 to 12 GiB VM and a 4 to 8 GiB container. That is large enough to expose slow object fetches, but small enough that the whole test fits inside a normal maintenance window.

Define the pass/fail bar

A restore only passes if the restored resource starts and answers basic checks. For the VM, confirm it reaches the login console or that the guest agent reports useful network data. For the container, confirm systemd reports a running state.

Before you touch anything, record the package versions.

dpkg-query -W -f='${Package} ${Version}\n' proxmox-ve 2>/dev/null || true
dpkg-query -W -f='${Package} ${Version}\n' proxmox-backup 2>/dev/null || true
dpkg-query -W -f='${Package} ${Version}\n' proxmox-backup-client 2>/dev/null || true

This gives you the package versions on either side of the test. If the post-upgrade restore fails, you can compare those lines and see whether the VE storage package, PBS client, or PBS server package changed.

How to Run the Pre-Upgrade PBS S3 Restore Test?

Run this while VE is still on the old version. The goal is to prove PBS 4.2 S3 restore works before VE 9.2 enters the picture. If you need a starting point for automation, the PBS 4.2 S3 Restore Test Script for Repeatable Proof covers the same idea in a smaller scope.

Step 1: Create a known backup

Use your own VM and container IDs. The examples below assume your PBS storage is named pbs-s3.

vzdump 100 --storage pbs-s3 --mode snapshot --compress zstd
vzdump 101 --storage pbs-s3 --mode snapshot --compress zstd

If your storage name differs, use the name shown in the VE storage view. The important part is that both resources land in the same PBS S3 datastore you will test after the upgrade.

Step 2: Confirm PBS can see the S3 backend

On the PBS shell, check the remote and datastore.

proxmox-backup-manager remote list
proxmox-backup-manager datastore list

If the remote or datastore is missing, fix that before restoring. A VE restore failure can be a PBS visibility problem, not a VE upgrade problem.

Step 3: Find the backup IDs

From the VE node, list the PBS storage content.

pvesh get /nodes/$(hostname)/storage/pbs-s3/content --output-format json

Copy the newest backup volume ID for each test resource. It looks like a storage name, a backup path, and an ISO timestamp.

Step 4: Restore to disposable IDs

Use IDs that are not in use. I reserve 91xx for restore tests so they are easy to spot and destroy.

qmrestore pbs-s3:backup/vm/100/2026-02-15T00:00:00Z 9100 --storage local-lvm
pct restore 9101 pbs-s3:backup/vm/101/2026-02-15T00:00:00Z --storage local-zfs

If your target storage is different, change the target storage name. Do not skip this step. A restore that fails because the local ZFS pool is full or the LVM thin pool has no free space is still a real restore failure, even if PBS was healthy.

Step 5: Start and validate

qm start 9100
pct start 9101
qm status 9100
pct status 9101
pct exec 9101 -- systemctl is-system-running

If the container returns running, the archive restored and systemd came up. If it returns degraded, that may still pass for a homelab, but write down the failing unit. A post-upgrade test that suddenly returns degraded is a signal, not a joke.

For the VM, check that the guest agent reports an IP address or that you can reach a known service. The disk restored is not enough if the guest cannot boot cleanly.

Step 6: Clean up

qm destroy 9100
pct destroy 9101

Destroying the test resources keeps the node tidy, but keep the backup in PBS until the post-upgrade test is done. Do not let a retention policy delete the test backup before you have restored it on VE 9.2.

Time the restore from the first command until the resource is running. In one 1 GbE lab, a 12 GiB VM took 4 minutes 12 seconds and an 8 GiB container took 2 minutes 5 seconds. Those numbers were boring, which is exactly what you want.

What Changes After the VE 9.2 Upgrade?

After the upgrade, reboot the node and repeat the restore. For the wider upgrade path, the Proxmox VE 9.2 Upgrade Checklist for Homelabs covers package checks and maintenance windows.

Upgrade commands

apt update
apt dist-upgrade
reboot

Once the node is back, capture versions again.

dpkg-query -W -f='${Package} ${Version}\n' proxmox-ve 2>/dev/null || true
dpkg-query -W -f='${Package} ${Version}\n' proxmox-backup-client 2>/dev/null || true

Restore the same backup, not a fresh one

This is the key part. Restore the same PBS S3 backup you restored before the upgrade. If the pre-upgrade restore passed and the post-upgrade restore of the same backup fails, the problem is almost always VE 9.2, PBS client changes, storage config, TLS trust, or network behavior.

If you take a new backup after the upgrade and restore that, you have changed two variables at once. You no longer know whether the upgrade broke the restore path or whether the new backup was written differently.

Then test a new backup

Once the old backup restores cleanly, take a new PBS S3 backup and restore it once. That proves the upgrade did not break the write path either. You now have two restore proofs: old backup reads correctly, new backup writes and reads correctly.

Gotcha: first restore may be slow

In one lab, the first post-upgrade S3 restore took nearly twice as long as the pre-upgrade baseline. The cause was not broken backup data. The PBS client was establishing new TLS sessions and the object store was serving cold metadata. The second restore was back to normal. Treat the first run as a warm-up, but still record it.

The honest tradeoff is where to restore. Restoring to the same node is fast and uses local storage you already understand, but it can hide a broken network path to a spare node. Restoring to a spare node proves more, yet it costs time, capacity, and another place for a failure to hide. For a VE 9.2 upgrade, I do same-node first for speed, then one spare-node restore if the node is part of a cluster.

If the PBS S3 datastore itself lives on ZFS, the ZFS Scrub Schedule and ARC Health for PBS 4.2 S3 Backups is worth reviewing before you blame the VE upgrade.

How to Compare the Before and After Results?

A pass/fail table is enough. You do not need a dashboard. Write the numbers in a note and keep them with the upgrade ticket.

Check	Pre-VE 9.2	Post-VE 9.2
PBS S3 auth and listing	0.8s	0.9s
12 GiB VM restore to local-lvm	4m 12s	4m 38s
8 GiB CT restore to local-zfs	2m 05s	2m 11s
VM guest agent IP visible	12s after boot	14s after boot
CT systemd state	running	running

A small delay is normal. A doubling or tripling of restore time is not. If the post-upgrade VM restore fails with a target storage error, the PBS S3 restore may never have started. Check target storage before chasing object-store latency.

If the post-upgrade restore fails, check three things in order: can VE see the PBS storage, can PBS see the S3 remote, and can the target storage accept a new disk or container. This sequence prevents you from blaming S3 when the real issue is a full local ZFS pool.

When Should You Stop Testing and Start Upgrading?

You can stop when the pre-upgrade test passes, the post-upgrade restore of the same backup passes, and the new backup restore passes. If any step fails, pause the upgrade and fix the restore path. A failed restore test is cheaper than a failed upgrade weekend.

For homelabs, this whole flow can fit in 30 to 45 minutes per node if the PBS S3 datastore is healthy. The time is worth it because the test gives you something a backup log cannot: proof that a resource can be brought back to life.

Conclusion

A targeted PBS 4.2 S3 restore test before and after Proxmox VE 9.2 turns backup success into actual bootable proof. The next step is to pick one small VM and one small container, run the pre-upgrade restore today, and repeat the same backup restore after the upgrade.