Backups fail in predictable ways: the job stopped silently weeks ago, the data is there but the schema is not, the encryption key was only on the machine that died, or restoring takes three days and the business needed three hours.
Two numbers first
Recovery point objective is how much data you can afford to lose — which sets backup frequency. Recovery time objective is how long you can be down — which sets the restore mechanism. Agree both with whoever owns the business consequence, then test whether your current setup actually meets them. Most do not, and it is better to know now.
Rehearse the restore
- Restore to a clean environment on a schedule, quarterly at minimum.
- Time it, and compare against your recovery time objective.
- Verify the data afterwards — row counts, recent records, referential integrity, not just that the job reported success.
- Rotate who performs it, so the knowledge is not held by one person.
Ransomware changed the requirements
Attackers look for backups and destroy or encrypt them before triggering the main event, because that is what forces payment. Keep at least one copy immutable or genuinely offline, with separate credentials from production. A backup reachable with a compromised production account is not a backup.
What else must survive
Restoring a database does not restore a service. You also need the application configuration, secrets, DNS, certificates, and the runbook itself. Keep a copy of the recovery documentation somewhere that does not depend on the systems being recovered — a wiki hosted on the infrastructure that is down is useless.
Write it down
The restore procedure must be executable by someone who did not build the system, under pressure, possibly at night. Numbered steps, exact commands, where the credentials live, and who to call. Test the documentation by having someone unfamiliar follow it.