The restore you never tested

Ask most teams whether they have backups and the answer is yes. Ask when they last restored one and the room goes quiet. A backup that has never been restored is a hope. A restore that has been timed is a control, and the time is the number that matters.

Two numbers that define recovery

Recovery point objective (RPO) is how much data you can afford to lose, measured in time. A daily backup gives you an RPO of up to 24 hours. Continuous replication gives you minutes.

Recovery time objective (RTO) is how long you can be down. Nobody knows their real RTO until they have restored under pressure and timed it.

On managed estates we record both for every restore test, and the first test usually surprises the client. A 41-minute restore sounds fine until you learn the previous estimate, never tested, was ten minutes.

How we run the test

Quarterly on the Enterprise tier, twice a year on Professional. The test restores a production database and one application into an isolated environment, from the backup copy that is separated from production credentials, following the runbook as written. Someone who did not write the runbook runs it. The clock starts when the ticket is opened and stops when a smoke test passes.

The report records RPO achieved, RTO achieved, every step where the runbook was wrong, and what we changed. It goes in the monthly report so the client sees the number trend.

Why the backup must be separated

Ransomware operators target backups first. If the credentials that reach production also reach the backups, both are encrypted together. Immutable storage, a separate account and a separate set of credentials are not optional, and a restore test is the only way to prove they are configured.

What to do this month

Pick your most important database. Restore it somewhere isolated. Time it. Write down what went wrong. That single afternoon tells you more about your resilience than any policy document, and it is the first thing we do on every managed services onboarding.