A backup you have never restored is a belief, not a backup

We have never met an organisation with no backups. We have met a great many that had never restored one.

The distinction matters because a backup job reports on the wrong thing. A green tick means a file was written. It does not mean the file contains what you think, that you have the credentials to read it, that anyone knows the procedure, or that the restore fits inside the window your business can survive.

#The two numbers to agree first

Recovery Point Objective — how much data you can afford to lose, measured in time. Nightly backups mean an RPO of up to 24 hours. If losing a day of orders is unacceptable, nightly backups were never the right design, regardless of how reliably they ran.

Recovery Time Objective — how long you can be down. This one is routinely underestimated, because people time the restore command and forget everything around it: noticing, deciding, finding credentials, provisioning somewhere to restore to, restoring, verifying, and repointing DNS.

Both numbers are business decisions with cost implications, not technical ones. They should be agreed with whoever owns the consequences, in writing, before the architecture is designed — because they largely determine it.

#Test the restore, on a schedule

Put it in the calendar like any other operational task:

1. Provision a scratch environment from your infrastructure code.
2. Restore the most recent backup into it, timing the whole thing.
3. Run a verification query — row counts on key tables, and the most recent record in each.
4. Have someone who did not build the system follow the written runbook.
5. Record how long it took and what was unclear.
6. Destroy the environment.

Step four is the one people skip, and it is the one that finds the real problems. The person who built the system can restore it from memory. That person may be on holiday, or may have left.

#What the first test usually finds

In our experience, roughly in this order: the backup does not include something everyone assumed it did — uploaded files, environment configuration, or the contents of a secret store. The restore takes several times longer than anyone estimated. The runbook references a system that no longer exists. And the credentials needed to perform the restore are stored in the system that is down.

That last one is worth its own sentence. If your password manager, your runbook or your recovery credentials live inside the environment you are recovering, you do not have a recovery plan.

#Keep it boring

Point-in-time recovery on a managed database service is worth paying for. It converts "restore last night's dump" into "roll back to 14:32", which is a meaningfully different conversation during an incident.

Retention should be layered — frequent recent points, sparser older ones — and at least one copy should live somewhere with different credentials from the primary. Ransomware that reaches your production account will reach your backups too if they share a key.

#The uncomfortable question

Ask your team: when did we last restore from backup into a working environment, and how long did it take?

If the answer is a date, you are in good shape. If the answer is a description of the backup schedule, you have just found the most valuable work available to you this quarter.