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

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.