Database XP / Operating

A backup you have not restored is a hypothesis

The job succeeding proves the job ran.

Backup jobs report success and organisations treat that as assurance. What it establishes is that a process ran and produced a file. Whether that file can be restored, how long a restore takes, and whether the result is consistent are separate questions that only a restore answers.

The failures are undramatic and common: a backup that silently excludes a large object, a file written to storage that filled, an encryption key nobody has, or a format written by a version no longer installed anywhere.

The test worth institutionalising is a restore to a separate environment on a schedule, followed by a query that checks something real. Not the whole system, one meaningful check, which is enough to establish that the data is there and readable.

The other figure that matters and is rarely known is how long a full restore actually takes. That number determines the real recovery time, and it is usually discovered during an incident when somebody is asking how long.

The other backup property worth verifying is consistency across related tables. A backup taken without a consistent snapshot can capture one table before a transaction and another after it, producing a restore that is internally contradictory in ways that only appear when somebody runs a join months later.