A backup job can finish successfully while the organization remains unable to recover the service that depends on it.
The green status is real but narrow. It usually reports that software copied selected data to a destination and completed its configured checks. It says nothing by itself about omitted data, missing credentials, unreadable encryption keys, incompatible software, restoration time, or whether users can complete a business transaction after the data returns.
Backup, restore, and recovery are different claims
A backup is a protected copy of selected data and metadata from a defined point or period. Its controls include scope, frequency, retention, immutability where required, encryption, separation, monitoring, and access. A backup result should state what was copied, when, from where, to where, and which integrity checks ran.
A restore is the operation that reads a backup and writes its contents into a usable target. A restore test asks whether the organization can locate the right version, obtain the required keys and permissions, transfer the data, reconstruct it in a compatible environment, and verify integrity. A successful restore is stronger evidence than a successful backup. It is still not service recovery.
Recovery returns an agreed service capability after disruption. It includes data restore when needed, plus infrastructure, configuration, identity, secrets, network paths, dependencies, deployment artifacts, operating procedures, validation, and authority to make decisions. Recovery ends according to business acceptance criteria, not when one component starts.
Replication and high availability solve other problems. Replication can copy deletion or corruption quickly. High availability can keep a service running through some component failures. Neither replaces versioned, protected backups or a recovery process for the failure scenarios outside its design.
The recoverable unit is the service
A database rarely operates alone. The service may require identity providers, DNS, certificates, secrets, queues, object storage, configuration, container images, network policies, third-party endpoints, and a known startup order. If any critical dependency is unavailable or restored to an incompatible state, the data can be intact while the service remains unusable.
The recovery inventory should therefore map business capabilities to technical dependencies and data sets. It should identify the source of truth for configuration, the location and protection of keys, ownership across teams, and dependencies controlled by vendors. Infrastructure as code improves repeatability only for resources and configuration actually represented and maintained as code.
Scope must also match the failure. A test that restores one table proves something about that table. It does not prove recovery from account compromise, region loss, ransomware, operator deletion, software incompatibility, or corruption that remained undetected through several backup cycles. Different scenarios exercise different controls.
Testing must produce evidence
A credible test begins with a scenario, a known starting state, and acceptance criteria. The team should not quietly repair the environment before the clock begins or use undocumented access that would be unavailable during a real incident. Controlled assistance is legitimate, but it must be recorded because it changes what the test demonstrates.
Evidence should include the backup version selected, integrity results, recovery environment, timestamps for material steps, errors and workarounds, people and privileges used, data reconciliation, dependency checks, business transaction results, residual degradation, and final acceptance. A screenshot of a green dashboard is not enough to reproduce or evaluate the result.
Restore tests can run more frequently than full service exercises. Automated sampling can detect unreadable copies early. Component tests can verify keys, artifacts, and runbook steps. Periodic end-to-end exercises then determine whether those parts assemble into a working capability. The layers complement one another; a small test should not be reported as a larger one.
A passed test is evidence for the tested version, scenario, team, and conditions. It is not permanent certification. Changes to data volume, architecture, vendors, permissions, staff, or procedures can invalidate the result. Recovery evidence needs an owner, an age limit, and a retest trigger.
Strategy turns evidence into readiness
A recovery strategy connects business priorities to technical controls. It defines which services return first, acceptable data loss, required recovery order, degraded modes, decision authority, communication, and the conditions for returning to normal operation. Those choices determine backup scope and frequency; backup tooling should not determine the strategy by default.
Protection should be proportional to impact. Not every workload needs cross-region copies or minute-level recovery. Every workload does need an explicit decision about what loss and downtime the organization accepts, who approved it, and which evidence supports the claimed capability.
The most useful review question is not “do backups exist?” It is “for the agreed scenario, can the authorized team recover the complete service from protected sources and demonstrate the acceptance criteria?” That question can be answered with test records. Without them, the plan remains an unverified design.
Key takeaway. A backup is a protected copy, a restore returns that copy to a target, and recovery returns an accepted service capability. Each claim requires different evidence. A recovery strategy is credible only when tests show that people, dependencies, procedures, and data can meet defined acceptance criteria under a stated scenario.
Source notes
These current official sources define contingency planning, storage resilience, recovery testing, and ransomware-oriented backup controls.
- Contingency planning. NIST defines coordinated plans, procedures, technical measures, recovery priorities, testing, training, and plan maintenance. Source: NIST SP 800-34 Rev. 1, Update 1, updated 2023.
- Storage resilience. NIST covers data protection, isolation, restoration, testing, and recovery considerations for storage infrastructure. Source: NIST SP 800-209, 2020.
- Ransomware resilience. CISA recommends offline or cloud-to-cloud backups, protection of backup data, and regular testing of availability and integrity. Source: #StopRansomware Guide.
Discuss this article
Thoughtful comments, corrections, and notes from real-world practice are welcome. Discussion is managed through GitHub.
This space is intended for meaningful technical discussion, useful corrections, and field experience. Spam, personal attacks, low-effort comments, and vendor pitches may be removed.