How to Test Disaster Recovery for Virtual Machines: A Practical Checklist
A disaster recovery plan is only credible if recovery has been exercised and measured. Testing VM disaster recovery means restoring real workloads — one VM, then whole applications — in the planned order, recording actual recovery time and data point, and fixing what broke. The checklist below covers scope, evidence and pass criteria for each step.
Conceptual editorial illustration; not a product interface or measurement result.
Short answer
Test in stages, write targets down before you start, and capture timestamps. A test that passes without anyone recording how long it took has not produced evidence.
- Start with a single-VM restore, then a multi-tier application, then a site-level exercise.
- Include identity, DNS and network mappings — they cause more failed tests than the VMs do.
- Restore with the accounts you would actually have during an incident.
- Record actual RTO and the achieved recovery point, not the target.
- Close every finding with an owner and a retest date.
Why DR testing is now expected, not optional
NIST's OT Backup Quick Start Guide, SP 1339, published in June 2026, is short and direct: create backups regularly, test them, and review them during recovery exercises. The broader IR 8374 Rev. 1 ransomware profile makes the same point for IT environments: recovery has to be planned and tested before it is needed.
In Saudi Arabia, NCA guidance points the same way: the Essential Cybersecurity Controls cover backup and recovery management with periodic checks of recovery effectiveness, and the Business Continuity Policy Template asks for periodic DR plan testing, including live tests for critical systems where possible. For the wider reasoning on why backup alone is not enough, see cyber resilience for virtualized infrastructure.
Tabletop, partial or full: choosing the exercise
Each exercise type answers a different question. Most organizations need all three on a schedule.
| Exercise | What happens | Useful for | Limits |
|---|---|---|---|
| Tabletop | Team walks through a scenario using the runbook; nothing is restored | Finding gaps in roles, contacts, decisions and dependencies | Proves nothing about restore time or data |
| Partial | Selected VMs or one application restored to an isolated or secondary environment | Measuring real restore time and validating data without production impact | May miss cross-application dependencies |
| Full / live | Critical services run from the DR location or platform | Proving the plan end to end, including failback | Higher risk and effort; needs careful change control |
The DR testing checklist: test item, evidence, pass criteria
This is the on-page printable version. Copy it into your own runbook template; adjust pass criteria to your service tiers.
| Test item | Evidence to capture | Pass criteria |
|---|---|---|
| Service criticality | Agreed tier for each service and its owner | Every service in scope has a tier and a named owner |
| Dependencies | Dependency map: databases, identity, DNS, licensing, external APIs | Recovery order documented and reviewed by app owners |
| RPO and RTO | Targets per service, approved by the business | Targets written down before the test starts |
| Backup integrity | Job history, last successful copy, checksum or verification result | Latest copy within RPO and verifiable |
| Restore one VM | Start and end timestamps, steps taken | VM boots and passes basic health checks |
| Multi-tier application | Order of restore, wait states, errors | Application works end to end with restored tiers |
| Network, DNS, identity | IP/VLAN mappings, DNS changes, directory availability | Users and services can authenticate and resolve names |
| Access permissions | Accounts used for recovery and their rights | Recovery completed with designated recovery accounts only |
| Isolated recovery (where applicable) | Isolated network or environment used, copy source | Restore performed without touching production credentials |
| Storage and data validation | Row counts, file checks, database consistency checks | Data matches expected recovery point |
| Application validation | Business test cases run by app owners | Owners sign off that the service is usable |
| Failback / rollback | Steps and time to return to primary | Failback path tested or explicitly scheduled |
| Documentation | Updated runbook and contact list | Runbook matches what was actually done |
| Lessons learned | Issues, manual workarounds, owners, due dates | Each issue has an owner and a retest date |
| Retest | Date of next test and scope | Retest scheduled and failed items included |
What to record during a DR test
Record facts as they happen. Reconstructing a timeline afterwards is how optimistic numbers get into reports.
- Timestamps: declaration, restore start, each VM up, application usable, test end.
- Actual RTO per service: from declaration (or test start) to owner sign-off.
- Achieved recovery point: the timestamp of the data you actually got back, and the gap versus RPO.
- Errors and failures, with the step where they occurred.
- Manual steps and workarounds that are not yet in the runbook.
- Dependencies discovered during the test that were not in the map.
- Owners for each action and each finding.
Common reasons VM DR tests fail
Identity is unavailable because the directory servers were restored last. DNS still points at production. Restored VMs come up on the wrong VLAN. The backup copy exists but the recovery account lacks rights to the target cluster. A database restores but the application tier was restored from a different point in time.
None of these are hypervisor features. They are dependency and process gaps, which is why testing matters more than the feature list. HA and live migration do not help here — the distinction is explained in HA vs DRS vs live migration, and the roles of each protection layer in snapshot vs backup vs disaster recovery.
Setting the targets you test against
A test needs a target to pass or fail against. If your RTO and RPO were set without reference to what the platform and team can do, start with how to set realistic RTO and RPO for virtualized infrastructure. Then use the test to confirm or revise them.
What this means for Saudi organizations
For entities subject to NCA controls, the output of a DR test is evidence: dated records, measured results, findings and closure. Keep them with the BCP documentation and plan the next test before closing the current one. Testing does not by itself demonstrate compliance; it shows whether recovery works.
Where critical systems cannot be failed over live, record why, run partial exercises in an isolated environment, and document the residual risk for management review.
Where VirtuWa fits
Hemaya Backup & DR provides policy-based backup, restore workflows and DR planning for workloads on Asas HV. For environments using third-party backup tools, check compatibility and the engineering validation notes.
VirtuWa does not publish standard recovery times. A structured technical POC is the place to run this checklist against your own workloads and measure the results.
Sources and references
Frequently asked questions
How often should disaster recovery be tested?
On a defined schedule set by service criticality and policy. NCA's Business Continuity Policy Template calls for periodic DR testing and live tests of critical systems where possible; many organizations also retest after major changes.
What is the difference between a tabletop and a full DR test?
A tabletop walks through the plan without restoring anything, testing roles and decisions. A full test runs services from the DR location, proving recovery time, data and failback.
What should be measured in a DR test?
Actual recovery time per service, the achieved recovery point, errors, manual steps, undiscovered dependencies and owner sign-off. Compare these with the agreed RTO and RPO.
Is restoring one VM enough to prove DR?
No. A single-VM restore proves the backup copy works. Applications depend on databases, identity, DNS and networks, which must be restored in order and validated together.
Does VirtuWa provide a downloadable DR checklist?
The checklist on this page is the printable version. VirtuWa engineers can run it with you during a technical POC or DR validation workshop.
Request a DR validation workshop
Work through this checklist with VirtuWa engineers against your own workloads.
RTO vs RPO for Virtualized Infrastructure: How to Set Realistic Recovery Targets
RTO and RPO explained for VM environments: how they differ, why zero targets are rarely sensible, illustrative tier examples, and how to test whether targets are achievable.
Read articleCyber Resilience for Virtualized Infrastructure: Backup Is Not Enough
Why backup alone does not make a virtualized environment resilient. A maturity ladder, failure domains, and a scenario-to-protection table for VM infrastructure.
Read articleVM Snapshot vs Backup vs Disaster Recovery: What's the Difference?
Snapshot vs backup vs disaster recovery: what each one actually protects, why snapshots are not backups, and how to combine them safely.
Read articleHA vs DRS vs Live Migration: What's the Difference?
HA, DRS and live migration solve different virtualization challenges. Learn how they support availability, VM mobility and resource optimization.
Read article