A successful backup job proves that a backup process completed. It does not prove that a critical service can be recovered to an agreed level, in the right order, by the people available during an incident.

That distinction matters because recovery failures often appear outside the backup platform. The data may be present while identity is unavailable, DNS points to the wrong place, firewall changes are undocumented or an application depends on a service nobody included in the recovery scope.

Backup, restore and recovery are different capabilities

Backup creates and retains a recoverable copy of data or a workload. Its evidence normally includes job status, retention, immutability and repository health.

Restore retrieves that data or workload. Restore tests provide stronger evidence, but they may still validate only an isolated server, database or file set.

Service recovery restores a usable business or technical service. It requires infrastructure, data, identity, connectivity, dependencies, people and decisions to work together within an acceptable timeframe.

A green backup dashboard is useful. It is not a substitute for evidence that this wider chain works.

Start with critical services, not backup jobs

Recovery planning is clearer when the unit of discussion is a service rather than a VM, repository or policy. For each critical service, establish:

  • what users or downstream systems actually require
  • the recovery time and recovery point expectations
  • the application, data and infrastructure components involved
  • the identity, DNS, network and security dependencies
  • who can authorise, execute and validate recovery
  • what evidence demonstrates that the procedure works

This prevents technically successful restores from being mistaken for usable service recovery.

Recovery targets must be connected to evidence

RTO and RPO values are often recorded without showing how they were derived or tested. A stated four-hour RTO has limited value if the most recent exercise restored only the database, excluded identity dependencies or stopped before users validated the service.

For each target, ask:

  1. Who agreed it?
  2. What scope does it cover?
  3. What assumptions does it depend on?
  4. When was it last exercised?
  5. What evidence shows the target is achievable?

Where evidence is incomplete, record that limitation openly. False certainty is more dangerous than a clearly described gap.

Dependencies are where plans become operational

Runbooks frequently describe the primary application and omit the surrounding services that make it usable. Common omissions include:

  • directory services and privileged access
  • DNS records and certificate requirements
  • routing, firewall and load-balancer changes
  • storage presentation and encryption keys
  • secrets, service accounts and external integrations
  • monitoring, alerting and user validation

A useful recovery plan makes these dependencies visible and assigns ownership to the actions that resolve them.

Test the decision-making as well as the technology

Recovery exercises should validate more than a scripted sequence. Teams also need to know who declares the incident, who chooses the recovery point, who accepts data loss, who communicates status and who confirms that service is fit to return.

These decisions are often time-critical. If they first appear during a real incident, the technical runbook is only partially complete.

Build an evidence trail

Useful recovery evidence can include timestamps, screenshots, job output, validation records, exceptions, decisions and follow-up actions. The objective is not paperwork for its own sake. It is to establish what was tested, what was not tested and what must improve before the next exercise.

A concise test record with honest limitations is more valuable than a polished document that implies unsupported assurance.

A practical next step

Choose one important service and compare its recovery assumptions with the available evidence. If the targets, dependencies, procedures and test results do not align, the organisation has identified a useful starting point for improvement.

The Cygnus DR Readiness Checklist provides a structured set of prompts. Once you have identified the important gaps, the DR Assurance Sample Report shows how they can be translated into service findings, recovery priorities and recommended actions.

The Cygnus DR Assurance Review applies that approach to the services and disruption scenarios that matter to your organisation.