A backup you have never restored is only a hope

Nearly every production system has backups switched on. Far fewer have ever been restored on purpose. The gap matters because the questions that decide how bad an incident becomes can only be answered by a real restore: does it work, how long does it take, and how much data is lost between the last backup and the failure?

Two numbers worth writing down

Recovery planning usually comes down to two figures:

• Recovery point objective: how much recent data the business can afford to lose, measured in time.
• Recovery time objective: how long the service can be unavailable while it is restored.

Neither number is technical. They are business decisions, and they should be agreed with whoever owns the risk before anyone designs the backup schedule around them.

What a restore drill involves

1. Pick a realistic failure: a deleted table, a lost server, a corrupted deployment.
2. Restore from backup into an isolated environment, following only the written runbook.
3. Time each step, and note every point where someone had to improvise.
4. Check the restored data against what you expected to recover.
5. Update the runbook with what you learned, then schedule the next drill.

The first drill usually fails somewhere. That is the point of doing it on a quiet afternoon rather than during an outage.

Common surprises

Drills tend to expose the same handful of problems: backups that silently stopped months ago, credentials that only one person holds, restores that take far longer than the business assumed, and configuration that lives outside the backup entirely. None of these are exotic. They are simply invisible until somebody tries.

Make it routine

A drill run once is a snapshot. Run on a schedule, it becomes evidence you can show to a customer or an auditor who asks about recovery. Our Operational Continuity practice includes a restore verification drill for teams who would rather have that evidence before they need it.