Restore Test

A restore test is the exercise of taking a backup and actually rebuilding a working system from it, on a schedule, deliberately, before anyone needs to. It exists because a backup is not a thing you have; it is a claim about a thing you could do, and the claim is unverified until someone tries. The failure modes are dull and extremely common. The job has been writing zero-byte files since a credential expired and nobody read the success message closely. One table was excluded by a filter added years ago for a reason nobody remembers. The data restores but the service will not start, because the configuration, the secrets and the schema version were never part of what was being copied. The restore works and takes eleven hours, which is fine as an engineering result and unacceptable against what the business assumed. A test is only worth running if it measures the thing you will care about, which is not whether files exist but how long a person takes to get to a working system and what is missing when they arrive. That means restoring into a clean environment rather than over the top of a running one, with someone following the written procedure rather than the person who built it working from memory, and finishing with an explicit check that the restored data is current and complete rather than merely present. Write down the elapsed time and the point the data was recovered to, because those two numbers are the only honest version of a recovery promise. And run it on a cadence, since every one of the failure modes above is introduced by an ordinary change made by someone who had no idea the backup depended on what they touched. A restore test also answers a question that has nothing to do with hardware: whether anyone still has the access required to perform it. Recovery procedures written years ago routinely assume a person, a key or an account that no longer exists, and that gap only ever surfaces on a day when nobody has time to discover it.