A Backup Is Only a Restore
How do you know your backups work?
The idea
A backup has no value until it has been restored successfully, and restores fail for reasons backups do not reveal.
In the real world
Nightly archives run for a year, then turn out to exclude the database.
Going deeper
A backup job reports on whether it ran, not on whether its output is usable. Between those two things sit every common failure: a database excluded by a path change, a file written while being modified, an archive that decompresses but is missing tables, encryption whose key nobody kept.
The only test that covers all of it is performing the restore. Doing it once also produces the number you actually need in an incident, which is how long recovery takes — usually far longer than people assume, because it involves finding the archive, provisioning somewhere to put it, and discovering what else was never included.
Where it stops applying
Full restore drills are expensive and rarely justified monthly. A partial restore of the most critical dataset, done occasionally, catches most of the failure modes at a fraction of the cost.
Why it matters
It moves your confidence from whether the job ran to whether you could actually recover.
Try this today
Restore one backup into a scratch environment and time how long it takes.
Test yourself
Backups have run nightly without error for a year. Why is that not evidence you can recover?
Show the answer
A successful job proves the copy was written, not that it contains what you need or that it can be read back. Missing tables, silent truncation and unusable formats all produce green ticks. Only a completed restore tests the thing you actually care about.
Learn this in the feed Answering from memory, then again days later, is what makes it stick.