Disaster Recovery Failover Test Checklist Template

The test mode recorded on the first task, Isolated drill or Live failover, decides which tasks appear in Phases 2, 4, 5 and 6.

• Open the test record and name the test lead, test authority and scribe — with the test mode, the date, who can stop the test and the DR plan owner who signs off
• List the systems in scope in recovery order — each with its RTO and RPO taken from the DR plan, and the application owner who will check it
• Write the objectives and success criteria — for example, orders can be taken at the recovery site within four hours with no more than 15 minutes of data lost
• Choose the scenario and state what is out of scope — loss of the primary site, a cloud region or a storage array, and the systems nobody may touch
• Record the runbook version the team will follow — the test checks the document as well as the technology, so nobody works from memory

The DNS task appears only for a live failover.

• Confirm replication is healthy and inside the RPO for every system — replication lag, the latest consistent recovery point and any paused or failing jobs
• Check the recovery site has the capacity, licences and configuration it needs — quotas, licence keys, patches and firewall rules drift between tests
• Confirm identity, DNS and certificates work at the recovery site — directory services, name resolution and expiring certificates stop more recoveries than servers do
• Shorten DNS TTLs on the records that will move — a day ahead, so users follow the switch in minutes and follow it back at failback
• Raise the change record and freeze unrelated changes — a patch or deployment in the same window makes the results impossible to read
• Brief users, the service desk, on-call staff and suppliers — the window, the expected impact and who to call if something unexpected breaks

The test authority named in Phase 1 records Approved or Not approved on the last task. The checklist halts there, and nothing fails over until they decide.

• Agree the abort criteria and the way back — for example, stop if recovery is not complete at one and a half times the RTO, and how production is restored if it is
• Record a reference point in production before the test — row counts on key tables, the last transaction number and the time it was written
• Confirm every runbook step has an owner on shift with working access — including break-glass accounts and the passwords stored outside the primary site
• Check for open incidents and new risks on the day — a live major incident or a degraded storage array is a reason to postpone
• Approve or postpone the test — the test authority records the decision and the reason, with the readiness checks attached

Stopping writes at the primary and redirecting users appear only for a live failover. In a drill, production keeps running.

• Start the test clock and log the declared start time — every later time is measured from this one
• Stop writes at the primary and record the final replication point — so no transaction lands in both sites and the data loss can be measured
• Bring up the recovery copies in the documented order — identity and databases first, then application tiers, then front ends, logging each start time
• Redirect users and integrations to the recovery site — DNS, load balancers, remote access and the partner endpoints that call in
• Log every departure from the runbook as it happens — the step, the time, what was done instead and who decided
• Record the time each system is declared recovered — when its application owner can use it, not when the virtual machine booted

Application owners picked in Phase 1 run their own checks. The isolation check appears only for a drill.

• Run the functional checks for each system — sign in, open recent records, complete a transaction and run a report
• Measure how current the recovered data is — compare the newest record at the recovery site with the Phase 3 reference point
• Test integrations, scheduled jobs and outbound email — the parts nobody notices are missing until month-end
• Confirm monitoring, backup and security tools cover the recovery site — a system running unwatched and unprotected is not recovered
• Prove the drill environment cannot reach production — no duplicate hostnames on the live network, and no job sending real emails, orders or payments
• Record each application owner’s acceptance — Accepted, or Not accepted with the open issues listed

The first three tasks appear only for a live failover. Every test ends with replication healthy and the temporary resources gone.

• Agree the failback window and announce it — failback is a second change, with its own downtime and its own go decision
• Reverse replication from the recovery site to the primary — every change written during the test has to come home before users do
• Switch users back and confirm the primary holds every change — compare against the final state of the recovery site before reopening
• Confirm replication to the recovery site is healthy again — and take a fresh full backup; DR protection is reduced until both are done
• Remove drill instances, test accounts and temporary access — they hold live data, cost money and widen the attack surface
• Log the time normal operations resumed and tell users — this stops the test clock

Answering No to “All targets met?” adds the retest task. The DR plan owner signs off the report, and the checklist halts until they record a decision.

• Calculate the measured recovery time and data loss for each system — from the logged timestamps, against its RTO and RPO
• Log every issue with an owner and a due date — from the deviation log, the validation checks and the hot debrief held straight after
• Schedule a retest for each missed target — after the fix, and before anyone quotes the RTO to the business again
• Update the runbooks and the DR plan — the order, steps, contacts and timings that turned out to be different
• Write the test report — objectives, timeline, results against targets, issues and lessons learned: the after-action report NIST SP 800-34 asks for
• Sign off the test report — the DR plan owner records Approved or Not approved, with the reason