The restore test nobody runs

Every organisation has backups. Few have restored recently. The gap between the two is one of the most widespread and least visible risks in IT.

Why the test never happens

It is never urgent. It ties up scarce people for a full day. It produces no visible result when it succeeds. And it carries a perceived risk — "what if the test breaks something". Every quarter it is pushed to the next one for individually good reasons.

What the test almost always reveals

The real time is longer than the stated time. The continuity plan says four hours. The real restore takes eleven, because transfer time from cold storage was never measured, or because index rebuilds take several hours at production volume.

Something is missing. Almost always the same things: secrets, certificates, scheduler configurations, or access rights. The database is restored, the application does not start.

Nobody knows how to run the procedure. It was written by someone who has left, it references tools that have changed version, and it assumes access the on-call person does not have.

The real recovery point is not the stated one. The backup runs at two in the morning, which means maximum data loss is not one hour as documented, but twenty-four hours minus the time of the incident.

How to run the test

In an isolated environment, never in production, on a separate network so a restored application cannot write into a live system.

Timed, from trigger to functional availability verified by a business user — not the moment the database responds, but the moment someone confirms the data is there and correct.

By someone who did not write the procedure. That is what makes the test useful: it measures the procedure, not its author's knowledge.

With a realistic scenario. Restoring last night's backup is the easy case. Restoring the one from eleven days ago, because a corruption went unnoticed for a week, is the case that reveals the real problems.

What to do with it

The number the test produces replaces the one in the continuity plan. If the real time is eleven hours and the business needs four, you have a gap to address, and you know it before the incident rather than after.

Sometimes the gap is acceptable and it is the plan that was too ambitious. Revising it upwards is a legitimate outcome: an honest continuity plan is worth more than a flattering one.

A sensible frequency

Once a year for standard applications, once a quarter for critical ones, and systematically after a major architecture or backup provider change.

Record the date of the last successful test in your security documentation. It is a question every serious vendor questionnaire asks, and "we have backups" does not answer it.