Verified isn't restored: what each check proves

A backup job that reports success has proved one thing: it wrote some bytes somewhere. Whether those bytes become a working Home Assistant on a Tuesday morning is a separate question, and the only way to answer it is to do it.

Most backup setups pile up green checks: the job status, an archive test, a PBS verify job, an off-site comparison. Each one is worth running. None of them answers the question you actually care about.

The trap: "verified" means something different at every layer

The word "verified" shows up all over a backup stack, and it never means "it works." A PBS verify job proves the chunks on disk still match their hashes. zstd -t proves an archive is not truncated. Neither proves the guest boots, the database opens, or the one file you need is actually in there.

Here is what each check really buys you:

Check	What it proves	What it doesn't
Job reports OK	The job finished writing	That the data was good when it was read
`zstd -t` on a vzdump archive	The file is complete and decompresses	That the guest inside it boots
PBS verify job	Chunks match their hashes; no bit rot	That the backup was consistent when taken
`rclone check`	Off-site matches local	That local was any good
A restore drill	The guest starts and the data is there	Only what you looked at

Every layer is worth running; only the last one answers the question.

Keep the cheap checks running

The lower layers are cheap and catch real problems, so leave them on:

Archive test. zstd -t <archive.zst> works on a container's .tar.zst and on a VM's .vma.zst alike. It tells you the file is whole.
PBS verify jobs. Weekly, with "skip verified" on and "re-verify after" set to 30 days. A verify reads every chunk, so it is disk-heavy; schedule it for a quiet morning.
Off-site comparison. rclone check b2:dump /mnt/backups/dump compares what is in the bucket against the source without transferring anything, and rclone cryptcheck does the same through the crypt layer. Run one after the first sync and once a month after that.

Then add the one check that proves something.

The fix: a quarterly restore drill

Four times a year, one evening, four restores. Two rules for every one of them: restore to a new ID, never over the original, and keep the network unplugged until you have looked.

Drill 1: a VM from PBS

Pick the guest that would hurt most to lose. In the Proxmox GUI, open the PBS storage, then Backups, select the newest backup of the guest, Restore, and give it a new ID and a storage. Or from the shell:

qmrestore pbs01:backup/vm/101/2026-10-08T01:30:00Z 9101 \
  --storage local-zfs --unique 1
qm set 9101 --net0 virtio,bridge=vmbr0,link_down=1
qm start 9101

--unique gives the restored VM fresh MAC addresses so it can sit next to the original without a fight, and link_down=1 keeps its network unplugged.

Open the console. Does it boot? Log in. Is last night's data there? For Home Assistant, that means the dashboard loads and the most recent automation you wrote exists. Then clean up:

qm destroy 9101 --purge

Drill 2: a container from a vzdump archive

Same idea with pct restore, from the NAS copy:

pct restore 9143 \
  /mnt/pve/nas-backup/dump/vzdump-lxc-143-2026_10_08-02_30_01.tar.zst \
  --storage local-zfs

This tests the second tool and the second storage at the same time.

Drill 3: a single file from PBS

In the GUI, pick a backup, File Restore, browse into the disk and download one file. Pick something small and recent, like yesterday's Immich database dump. This is the restore you will actually do most often, so it deserves practice.

Drill 4: something from off-site

Pull one archive back from the bucket and test it:

rclone copy b2:dump/vzdump-lxc-143-2026_10_08-02_30_01.tar.zst /tmp/restore-test/
zstd -t /tmp/restore-test/vzdump-lxc-143-2026_10_08-02_30_01.tar.zst

Or restore it the same way as drill 2. If you sync to a friend's PBS instead, restore one guest from their datastore. This is the only drill that proves the copy that survives the house.

Once a year: the full rebuild

Make drill 1 a full rebuild once a year: a fresh Proxmox install on a spare disk or a VM, restore /etc/pve from the host backup, re-add the PBS storage with the saved encryption key, restore a guest.

This is where the surprises live. The storage names in the restored configs may not exist yet on the fresh install, and every guest shows greyed out until you recreate them. Far better to find that out on a spare disk than on the real one.

Home Assistant and OPNsense drills

Home Assistant: create a fresh HAOS VM, and on the onboarding screen choose Restore from backup, upload yesterday's backup and enter the encryption key. Give it fifteen minutes. If the dashboard comes back with your automations, you have proved the whole chain: backup, encryption key, off-site location, restore.

OPNsense: a fresh VM from the ISO, assign interfaces at the console, then restore the encrypted config.xml through the GUI. Keep the new VM's WAN unplugged so you do not end up with two DHCP servers on the house network.

Write it down

A drill nobody wrote down did not happen. Keep a table at the bottom of your backup inventory with the date, what you restored, where it came from, the result and the time taken, plus a notes column.

The notes column is where the real value lives. "Took 38 minutes from B2" tells you what a bad day would look like. "Had to recreate storage names" is a line in next year's rebuild plan.

Put the drill on your calendar as a repeating event with the four steps in the description. Alerts tell you when a job fails loudly; the drill catches what the alerts missed, such as an off-site job that has been quietly failing for weeks.

Checklist: restore testing

A quarterly calendar event with the four drills in it
Every drill restores to a new ID with the network unplugged, then is destroyed
One file-level restore and one off-site restore every quarter
A Home Assistant restore onto a fresh VM done at least once, with the encryption key
A yearly rebuild of a node from the host backup, on spare hardware or a VM
A log with date, source, result and time taken