A Backup Is Not a Recovery Plan—Set RTO and Test the Failback Path

A disaster recovery test must prove more than the existence of restorable data. For every in-scope workload, define the maximum acceptable outage and data loss, then run a timed exercise that validates replication, dependency order, network access, application integrity and the return to the primary environment.

The result should be an evidence-backed pass or fail, not a statement that a backup completed. A complete test starts with a tabletop review, progresses through an isolated recovery drill and ends only after failback succeeds, protection resumes and the application owners accept the resulting data state.

Turn business impact into RTO and RPO

Place applications into recovery tiers according to business impact. Record the service owner, technical owner, dependent systems, acceptable degraded mode and the business process that determines whether the service is usable. This inventory defines the scope of a workable recovery plan; a list of servers does not.

Assign each application a recovery time objective, measured from the declared start of the incident until the business service passes its acceptance checks. Assign a recovery point objective that specifies the oldest acceptable recoverable data. India’s Ministry of Electronics and Information Technology defines RTO as tolerated application downtime and RPO as data-loss tolerance; its guidance says near-zero RTO requires failover services, while near-zero RPO requires continuous replication.

Do not copy one target across the entire estate. An identity service required by other workloads may belong in an earlier recovery tier than a revenue application that depends on it. Document the clock’s start and stop events so the team cannot declare success when virtual machines have booted but users still cannot transact.

Build the recovery dependency map

For each recovery group, map the full path from stored data to a usable service. Include compute capacity, images and configuration, storage, replication components, encryption keys, secrets, identity providers, certificates, load balancers, firewalls, routing, DHCP, DNS, monitoring and external integrations. Identify which dependencies must already operate at the recovery site and which the runbook creates during the event.

Convert that map into a boot sequence. Validate routing, name resolution, time synchronization and identity before services that depend on them; make databases ready before application services; switch user traffic only after the application path passes its checks. Add a readiness test after each stage because a running process is not necessarily a usable dependency.

Before the live drill, confirm that the recovery environment has enough compute, storage performance, addresses and network bandwidth for the tested load. Verify replication health, the timestamp of the newest recoverable point, access permissions and whether the recovery team can operate when primary-site identity or communications are unavailable.

Move from tabletop review to live failover

Use the same scenario, scope and acceptance criteria across three progressively stronger exercises:

1. Tabletop: walk through incident declaration, decision authority, contacts, runbook steps, security controls and communications. Record unclear ownership and unavailable dependencies as failures to correct.
2. Isolated recovery: restore or start replicas without directing production traffic. Confirm that systems can communicate inside the recovery network without creating duplicate jobs, outbound messages or conflicting writes.
3. Controlled failover: execute the approved traffic switch, validate the service through a user-relevant path and keep it operating long enough to create data that must later survive failback.

Start one test clock at the event defined in the plan. Capture timestamps for declaration, recovery initiation, infrastructure readiness, database availability, application startup, traffic switching and final business acceptance. Separately record the newest consistent recovery point and compare its age with the RPO.

Product runbooks are inputs to the exercise, not proof that recovery works. NetApp’s JetStream deployment documentation covers protected domains, recovery appliances, replication storage, destination networking, boot order, failover and failback; for proof-of-concept trials, it recommends manually running the cycle from protection through failover and failback.

Set measurable acceptance criteria

Write the pass conditions before the drill. The acceptance record should answer all of the following:

• Did every critical workload become usable within its RTO, measured to business acceptance rather than machine startup?
• Was the recovered data consistent, and was its age within the RPO?
• Did recovery groups start in the documented order without hidden manual dependencies?
• Did routing, firewall rules, load balancing, DHCP and DNS work from the intended user and administration networks?
• Could users, service accounts and administrators authenticate with the primary identity environment unavailable?
• Did application owners complete defined reads, writes, transactions and reconciliation checks?
• Did monitoring, logging, alerting, backup and security controls operate in the recovery environment?
• Were commands, approvals, elapsed times, exceptions and manual interventions captured for the runbook update?

Specify objective evidence for each item: timestamped logs, replication status, DNS answers from named networks, transaction identifiers, database consistency output and owner sign-off. Record a missed target as a failed control even if engineers eventually restore the service. That result exposes a capacity, automation, documentation or dependency gap that a successful backup report cannot reveal.

AWS Well-Architected guidance on DR validation calls for regular testing of failover and failback against RTO and RPO targets, including the identification of bottlenecks that could increase recovery time or data loss.

Test failback as a separate recovery event

Failback is not cleanup after the real test. It introduces another replication direction, a service interruption and the possibility of conflicting writes. Before returning, verify that the primary environment is trustworthy and correctly configured, decide how writes made at the recovery site will be synchronized, and define who can authorize the final traffic change.

Run the return in a controlled order: coordinate or pause writes, complete reverse replication, verify consistency, start primary-side dependencies, switch traffic, execute the same application checks and confirm that monitoring and backup policies are active. If the business has approved a separate failback objective, measure the return against it.

The exercise passes only when accepted recovery-site writes exist in the primary environment, users reach the intended endpoints, data validation succeeds and normal protection has resumed in the correct direction. Assign an owner and deadline to every gap, update the runbook with the commands and timings observed during the exercise, and retest failed controls.

Also read:

• What is A Data/Disaster Recovery Plan?
• 5 Essential Elements of an Effective Disaster Recovery Plan for Businesses
• How To Create a Disaster Recovery Plan For Your Business?