The Backup Is a Claim. The Restore Is the Evidence.

Every cloud team has a backup screen. Green ticks, a reassuring count, maybe a little graph that slopes gently upward. It is the comfort blanket of infrastructure. But a backup is a claim. The restore is the evidence. And in the UK, where boards are increasingly asked to sign off on operational resilience and regulators expect personal data to survive a bad day, the gap between the two is where careers get uncomfortable.

Start with a business promise, not a console

Do not begin by picking a workload because it is easy to clone. Begin with a sentence someone in the business has actually said out loud. Something like: the order system must be back within four hours, and we cannot lose more than fifteen minutes of customer records. That is your target. Now find the workload that represents it.

You are not testing everything. You are testing a credible sample. Choose one service that matters, one that has dependencies, and one where a mistake would be embarrassing but not fatal. A read-only reporting service is a soft start. A payments path is a brave one. The point is to prove the process, not to win an award for heroics.

Pick a target that can fail safely

A restore drill should not become the incident. Use an isolated account, a separate network, and credentials that cannot touch production. No live DNS. No shared queues. No clever shortcuts that depend on the very systems you are pretending have gone away.

This is also where UK data protection expectations deserve a proper look. If you are restoring personal data into a test environment, you have not left UK GDPR behind. Keep the test environment under the same access controls, logging and retention rules as production. Where you can, use synthetic or minimised data. If you must use real records, write down why, who approved it, and when it will be deleted. Auditors love a tidy answer. They also love catching the one you did not write down.

Measure the clock, not the confidence

A restore job finishing is not the same as a service being usable. Your real recovery time objective starts when someone decides to invoke the plan and ends when a named user can complete a named task. That means DNS, secrets, configuration, dependencies and a smoke test that actually proves something.

Break the drill into phases: decision, access, restore, configuration, validation. Time each one. The restore phase often looks quick. The bit where nobody can find the break-glass credentials is where the afternoon goes.

For recovery point objective, compare the timestamp of the last recoverable data with the moment you started the test. Do not accept the backup tool's summary as gospel. Check it against the business promise. If the target was fifteen minutes and the evidence says forty, you have found something more useful than a green tick.

The awkward middle: people, keys and dependencies

The person who designed the backup is rarely the person on call at 2am. Test with the rota, not the architect. Watch where they hesitate. That hesitation is a runbook gap.

Check the boring things: who can approve a restore, where the encryption keys live, whether the provider support tier actually covers what you think it covers, and whether an immutable backup is genuinely immutable. If your plan depends on a single engineer remembering a portal password, that is not a plan. It is a folk story.

What evidence looks like

Keep it to one page. Scope. Date. Participants. Actual RTO and RPO against targets. Data protection notes. What broke. Who owns the fix. When it will be retested. Attach the logs, but lead with the summary.

Finance wants to know what the test cost and what risk it retired. The board wants to know whether customers will be harmed and whether the regulator will be interested. Your auditors want a trail that shows the claim was tested, not just asserted. A single, signed-off restore report does more for all three than another dashboard screenshot.

Do not let the drill become the outage

Schedule it. Tell the people who need to know. Use rate limits. Avoid production credentials. Have abort criteria written down before you start. If the test starts interfering with live services, stop. A failed drill in a safe environment is a successful finding. A failed drill that takes down the website is a different kind of meeting.

Make it a habit, not a performance

Rotate the workload. Retest after major changes. Track the trend in a simple internal scorecard: how many workloads have a current restore test, how close actual RTO came to target, how many gaps closed. The goal is not a perfect result. It is a credible claim. And credible claims are built from evidence you can point to when the room goes quiet.

A backup you have never restored is a rumour with a retention policy. Run the drill. Write it down. Then do it again next quarter.