Disaster Recovery Testing: A Practical Guide

Every organisation has backups. Far fewer can say, with evidence, how long it takes to bring a critical service back and what it looks like when it comes back. That evidence only comes from testing.

A disaster recovery plan that has never been executed is a hypothesis. Credentials expire, networks change, applications gain new dependencies, and the person who wrote the runbook moves on. Testing turns the plan into a measured, repeatable procedure.

Short answer: disaster recovery testing means restoring real systems from real backups into an isolated environment, on a schedule, and measuring the result against your recovery time and recovery point objectives (RTO and RPO). Start with a tabletop review, move to regular restore tests of individual systems, and run a full recovery exercise of critical services at least once a year. Record actual recovery times, data loss and every issue found, then fix and retest.

Why untested DR plans fail

DR plans rarely fail because the backup software breaks. They fail because the environment around the backups has moved on since the plan was written. The same issues surface in almost every first test:

Missing dependencies. The application restores, but DNS, directory services, licence servers or a message queue it depends on were never in the plan.
Expired access. Service accounts, API keys, certificates and passwords stored in a vault that itself needs recovering.
Network surprises. Restored machines come up with IP conflicts, wrong VLANs or firewall rules that block the recovery site.
Restore speed nobody measured. Backup jobs run every night; restores of the same data at scale run rarely, and are often slower.
Incomplete or unusable recovery points. A volume excluded by a policy change, or an application backed up without consistency.
A runbook out of date. Steps that reference tools, people or hostnames that no longer exist.

Each of these is cheap to fix during a test and expensive to discover during an incident.

What DORA and NIS2 expect

For EU organisations, testing is no longer a best practice. It is a documented obligation.

DORA (Regulation (EU) 2022/2554), Article 11(6) requires financial entities to test ICT business continuity and response and recovery plans at least yearly, and after substantive changes to systems supporting critical functions. Larger entities must include cyber-attack scenarios and switchovers to backups and redundant facilities.
DORA, Article 12 requires periodic testing of backup, restoration and recovery procedures. When restoring with their own systems, entities must use systems physically and logically segregated from the source.
NIS2 (Directive (EU) 2022/2555), Article 21(2) lists business continuity, including backup management and disaster recovery, among required risk-management measures. It also requires procedures to assess whether those measures are effective, which in practice means testing them.

An auditor will not ask whether you have backups. They will ask for the last test report, the measured recovery times and what you changed afterwards. Read the texts on EUR-Lex: DORA and EUR-Lex: NIS2.

Four types of disaster recovery tests

A mature programme combines all four. Each proves something the others cannot, and each costs more than the one before it.

Test type	What happens	What it proves	Effort and risk	Typical frequency
Tabletop walkthrough	The team talks through a scenario step by step, with the runbook open	Roles, contacts, decision points and gaps in the plan	Low; no systems touched	Every 6 months and after major changes
Restore test	Individual VMs, volumes or files are restored to an isolated environment and checked	Backups are complete, readable and restorable; real restore speed	Low to medium; automated, no production impact	Monthly, or weekly for critical systems
Application recovery test	A complete application with its dependencies is recovered and brought up together	Boot order, dependencies, network mapping and application-level RTO	Medium; needs an isolated network and app owners	Quarterly for critical services
Full DR exercise	Critical services are recovered at the DR site, ideally with a simulated loss of the primary	End-to-end RTO and RPO, people and process under pressure	High; requires planning and a change window	At least yearly; DORA requires yearly testing for financial entities

Start where you are. A team with no testing today gains more from monthly automated restore tests than from one ambitious annual exercise that slips every quarter.

The DR test cycle

Whatever the test type, the value comes from closing the loop. A test that is not measured, fixed and retested only proves that the plan worked once.

Measurement is the stage most teams skip, and the one auditors and executives ask about first.

How to test a disaster recovery plan: a 12-step checklist

Use the same checklist for every test, from a single restore to a full exercise. Consistency is what makes results comparable over time.

Before the test

Define scope and success criteria. Name the services in scope and their target RTO and RPO. Decide what “recovered” means for each: a login works, a transaction completes, a report runs.
Choose the recovery point. Test the latest backup, and occasionally an older one, to prove retention works too.
Prepare an isolated target. Restore into a network segregated from production, so test systems cannot collide with live ones. DORA expects this segregation when you restore on your own systems.
Tell the people who need to know. Application owners, security monitoring and, for larger exercises, management.

During the test

Start the clock at the moment you declare the simulated incident.
Recover in dependency order: infrastructure services first, then databases, then applications.
Validate at application level, not just at boot. Check the newest data timestamp to measure the real data loss.
Log every deviation: a manual step, a missing credential, a wrong IP, a slow restore.

After the test

Stop the clock when the last service meets its success criteria. Calculate actual RTO and RPO.
Clean up the test environment so it does not drift into a shadow production.
Report and fix. Record results, assign owners to every issue and update the runbook.
Retest what failed. A fix that has not been tested is another hypothesis.

The metrics to record

Metric	How to measure it	Why it matters
Actual RTO	Time from declared incident to the last service passing validation	Compares reality with the business target
Actual RPO	Time between the restored data’s newest record and the simulated incident	Shows how much data you would really lose
Restore throughput	Data restored divided by restore time	Predicts recovery time at full scale
Restore success rate	Systems recovered without manual repair, as a share of systems tested	Exposes fragile workloads
Manual steps	Count of actions outside the automated plan	Each one is a delay and a risk under pressure
Issues found and closed	Open and resolved findings per test	Proves the programme improves over time

Making DR tests repeatable with Storware recovery plans

The hardest part of testing is not the first exercise. It is doing it again next month, the same way, without a week of preparation. Storware’s disaster recovery capabilities handle that with recovery plans.

A recovery plan defines in advance which virtual machines to restore, with which restore settings, and to which target platform. It then orchestrates all of those restores as one operation, instead of a long list of individual restore tasks.

Run on demand or on a schedule. The same plan serves a real incident and a recurring test, so the procedure you test is the procedure you would use.
Restore as new machines. Recovered VMs are created alongside the originals, with generated names using a prefix or suffix, so tests never overwrite production.
Replace the previous test automatically. For recurring tests, a plan can restore under the original name and remove the previous test copy first, keeping the test environment clean.
Recover across platforms. Rules are set per target virtualization platform, so a plan can bring workloads up on a different hypervisor than the one they were backed up from.
Pair with isolated copies. Combine plans with immutable or air-gapped backup destinations so the copies you test are the copies an attacker cannot alter. See Immutable and Air-Gapped Backup Security.

Together this turns the restore part of the checklist (steps 5 to 7) from a manual runbook into a repeatable action. Configuration details are in the recovery plans documentation.