Proof
Proxmox restore testing, because a backup is a hypothesis
A backup job that reports success proves that bytes were written. A verify job proves those bytes are still readable. Only a restore proves you can get your business back. These are three different claims, and most estates only ever make the first.
The three levels of proof
- Job success — the backup ran and reported completion. The weakest signal, and the only one most teams watch
- Verify job — PBS re-reads the stored chunks and checks them against their checksums, catching silent corruption
- Live restore — a VM is actually restored and booted, which is the only thing that proves recoverability end to end
What a restore test should produce
If a restore test leaves no artefact, it did not happen as far as an auditor is concerned.
- The VM restored, named, with the restore point it came from
- A boot screenshot with a visible timestamp
- Wall-clock time from starting the restore to the VM being usable
- Any manual step that was required, because that step will be required at 3am too
- A one-page report you can hand to an auditor or an insurer without editing
Why estates skip it
- No spare capacity to restore into, so the test needs planning nobody has time for
- Nobody owns it, so it falls between the infrastructure and application teams
- The last one worked, which is treated as evidence about this quarter
- Fear of what it will find, which is the worst reason and the most common
Questions people ask on this
How often should we test a restore?
Quarterly is a defensible cadence for most mid-market estates, with verify jobs running weekly or monthly in between. Rotate which workload class you test — database one quarter, file server the next — so that over a year you have evidence across the estate rather than four reports about the same easy VM.
Is a verify job not enough?
No, and the distinction is worth being pedantic about. Verify proves the chunks are readable and match their checksums. It does not prove the VM boots, that the application inside it starts, that the database is consistent, or that your team remembers the procedure. Verify is necessary and insufficient.
Do we need spare capacity to test into?
Some, but less than people assume — a single restored VM at a time on a modest target is enough to produce real evidence. Where capacity genuinely does not exist, that is itself a finding worth writing down, because it means a real recovery has nowhere to land either.
Do you run these for us?
On managed plans we run a live restore of a nominated VM each quarter and issue the one-page report described above. On self-run estates we will hand you the checklist so you can do it yourself — it is not a secret and it is not complicated, it just needs somebody to own the date.
Find out when you last actually restored
It is one of the ten questions in the free health check, and it is the one that most often has an uncomfortable answer.