The backup you have never restored

Backups fail quietly

Backup jobs report success while excluding a table, capturing a database mid-write, or writing to storage nobody has checked in a year. Every one of those looks identical to a working backup until the day it matters.

The only test is a restore

Restore into a scratch environment and confirm the application runs against it. Everything short of that — file sizes, job logs, dashboards — tells you a process ran, not that the data is usable.

You do not have backups. You have files you believe are backups, until you have restored one.

Measure how long it takes

The drill tells you your actual recovery time, which is usually several times the estimate once you include finding credentials, provisioning, and reconnecting services. Knowing the real number changes what you promise customers.

Check what is missing, not just what is present

Uploaded files, secrets, queues, and third-party state are routinely outside the database backup. A restored database with no attachments is a working application showing empty pages — the reconciliation-first thinking applies here too.

Backups need to survive you

If an attacker or a mistaken command can delete both the system and its backups, you have one copy. Separate credentials and immutable or offsite retention are what make the second copy real.

Put the drill on a schedule

Twice a year, with the result written down. This is the same class of control as a canary that proves a silent path still works — the value is in running it before you need it, not in intending to.