How do I know our backups will actually restore when we need them?

9 November 2026 · 4 min read

A successful backup job is an output, not an outcome. Agree recovery targets with service owners, test restores against them and report the evidence.

In brief

A backup job that reports success only proves that a copy was made. It does not prove that a team can get its work back quickly enough to matter. This article explains why recovery should be treated as a service outcome with a named owner, agreed targets and regular evidence. It draws on John Sansbury's distinction between outputs and outcomes in The Journey to Service Excellence, and on his warning about the watermelon effect, where every dashboard reading is green while the experience underneath is not. The practical steps are to agree recovery targets with each service owner, map everything a service depends on, check that backups cover every important data source, and test restores on a regular schedule, timing them against the targets. It also covers keeping at least one copy of the backups out of reach of the same administrator accounts that run the live environment, and reporting tested restores to leaders rather than job success rates. A short illustrative example shows a finance team whose backup looked healthy for a year but could not return files within the time they needed at month end, and how a change and a second timed test fixed it. The article closes with common mistakes, such as testing only once at go live, and points to service continuity guidance in ITIL 4 and ISO/IEC 20000.

A green backup job tells you that a copy was made. It does not tell you that the business can get its work back, so the only real proof is a restore you have actually carried out, timed and checked against what the service owners need.

That is the question a lot of IT teams are quietly asking at the moment: the console shows "successful" every night, but would we really be able to recover if we had to? The answer is to stop treating backup as a technical job and start treating recovery as a service with an outcome, an owner and evidence.

Why "successful" is the wrong measure

John Sansbury draws a useful line between outputs and outcomes in The Journey to Service Excellence. An output is something the provider produces; an outcome is the result the consumer actually cares about. His payroll example makes it plain: a payslip is an output, being paid is the outcome. A completed backup job is an output. Getting the finance system, the shared drive or last Tuesday's version of a contract back, quickly enough to matter, is the outcome.

This is also a textbook case of what John calls the watermelon effect, where every reading on the dashboard is green but the consumer experience underneath is red. As he puts it, "Just because all the readings are positive does not guarantee fully satisfied consumers." A wall of successful jobs can sit alongside a backup that misses a new data source, cannot be restored granularly, or would be unreachable after a ransomware attack.

Practical steps

Agree what recovery has to achieve, service by service. Sit down with the owner of each important service and agree how much data they could afford to lose and how long they could manage without it. These recovery targets, often called the recovery point and recovery time objectives, belong to the business, not to the backup tool.

Map what each service depends on. John's advice on value streams applies directly: "you can’t just rely on the happy path occurring; instead, you need to understand on what the happy path relies and ensure that you build the necessary resilience into the system to maintain and protect it." For recovery, that means the data, the applications, the credentials, the licences and the people needed to bring a service back.

Check coverage, not just completion. Compare what is actually being backed up with your list of services and data sources. New systems and SaaS platforms are where the gaps usually appear.

Test restores on a schedule. Run small restores often (a single file, a mailbox, an old version) and fuller recovery rehearsals less often for the most critical services. Time them and record the results against the agreed targets.

Protect the backups themselves. Make sure at least one copy is kept separately and cannot be changed or deleted with the same administrator accounts that run your live environment. The UK National Cyber Security Centre's guidance on backing up data is a good plain starting point.

Report recovery evidence, not job status. Replace "jobs succeeded" with "restores tested this month, time taken, and whether it met the target". That gives leaders something honest to make decisions on.

Give recovery an owner. Someone needs to be accountable for recovery as a capability, not just for keeping the backup software running. In ITIL 4 this sits in the service continuity management practice; in ISO/IEC 20000 it sits within the requirements for service continuity and availability.

A short worked example

Here is an illustration rather than a real case. A finance team relies on a shared drive of month end workbooks. The backup has shown green for a year. IT agrees with the finance lead that they could cope with losing half a day of work, and need files back within two hours during month end. A test restore of a single folder from three weeks ago takes four hours because it means pulling a full image first. Nothing was "failing", yet the service could not meet its need. The fix is a change to how that data is backed up so that individual files can be recovered quickly, followed by a second timed test that meets the target. Finance now sees a monthly line in the service report confirming it.

Common mistakes

Treating backup as an IT housekeeping task with no business owner. Testing only that files can be opened, not how long a full recovery takes. Leaving backups reachable with the same credentials an attacker would steal first. Testing once, at go live, and never again. Reporting job success rates to leadership as if they were a measure of resilience.

The short version

A backup is only as good as the restore you have proved. Agree the outcome with the business, test against it regularly and report what you found, good or bad.

If you want to go deeper on outcomes, value streams and honest measurement, John Sansbury's The Journey to Service Excellence covers all three, and it is available to members of ESM's Exchange.

Tags: esm-questions, backup, service-continuity, measurement, itil-4