Testing and Running Failover

A disaster recovery plan that has never been tested is just a hypothesis. Test failover lets you validate that your VMs boot correctly, applications start, and network connectivity works in the target region — all without disrupting the source environment or breaking ongoing replication. Many organisations discover their DR plans have gaps only when an actual disaster occurs, which is exactly when a broken plan causes maximum damage. Regular test failovers are a compliance requirement for most regulatory frameworks.

ASR supports three types of failover actions. Test failover creates copies of the failed-over VMs in an isolated network (you specify the target VNet) without affecting replication or the source environment. Planned failover is used for scheduled migrations or maintenance — it first syncs any remaining changes then shuts down the source before failing over. Unplanned failover (used during a real disaster) fails over immediately from the latest recovery point without waiting for a final sync.

To run a test failover in the portal: select the protected item, click Test Failover, choose a recovery point (latest crash-consistent, latest app-consistent, or a specific point in time), and select a target virtual network (typically a dedicated isolated test VNet). ASR spins up the VM in the target region using the replica disks. The test VM appears alongside the replica but is completely independent — production is unaffected. After testing, click Cleanup test failover to delete the test VMs.

During failover you select a recovery point from ASR's retention window. The options are: Latest (lowest RPO) — the most current crash-consistent recovery point, minimising data loss. Latest processed — the most recently processed point (may be a few minutes behind). Latest app-consistent — the most recent application-consistent recovery point, which may be older but guarantees clean application recovery. Custom — a specific older recovery point for recovering to a known good state before an incident.

A recovery plan groups multiple protected VMs and defines the sequence and timing of their failover. You can specify which VMs boot first (e.g. database servers before application servers), add manual approval gates to pause failover for human validation, and insert Azure Automation runbooks to run pre- and post-failover scripts (e.g. updating DNS records, configuring load balancers, or sending notifications). Recovery plans can be tested independently with test failover.

A test failover provides the opportunity to measure your actual RTO (Recovery Time Objective). Start a stopwatch when you initiate failover and stop it when the application is fully functional and accessible to users. Typical Azure-to-Azure failover completes in 15–30 minutes for a single VM, but multi-tier applications with dependencies may take longer. Document any steps that add unexpected time (e.g. DNS propagation, application warm-up) and address them before the next test.

After a planned failover (e.g. migrating to a new region), you run Commit to finalise the failover. Committing stops replication back from the source and marks the target VMs as the new primary. Once committed, you can enable re-protection to reverse the replication direction, making the original source region the new DR target. This allows you to fail back to the original region after the incident is resolved.

Failback is the process of returning workloads to the original region after a disaster or planned migration. The steps are: re-protect the failed-over VMs (reversing replication to replicate from the new primary back to the original region), wait for initial sync to complete, then perform a planned failover back to the original region. Failback requires the original source infrastructure to still be intact — if it was destroyed, you may need to rebuild the landing zone before failing back.

After a test failover you must perform Cleanup test failover in the portal to delete the test VMs and their associated disks. Without cleanup, the test VMs continue running and accruing compute costs. The cleanup step also resets the protected item's test failover status, allowing you to run another test in the future. Automating cleanup (e.g. scheduling it for one hour after the test starts via an Automation runbook) prevents forgotten test VMs from running for days.

Every DR test should produce a DR drill report capturing: the date and scenario tested, recovery points used, RTO and RPO achieved, issues discovered, and remediation actions taken. This documentation satisfies auditor requirements for frameworks like ISO 27001 and SOC 2 that mandate regular DR testing. Store drill reports in a secure location accessible to both IT and business continuity teams.

Azure Site Recovery pricing applies per protected instance per month — the fee covers both the replication service and orchestration. You are also charged for storage consumed by replica managed disks in the target region and the cache storage account during replication. Outbound data transfer between Azure regions for replication traffic is charged at normal egress rates (unlike Azure Backup where paired-region egress is free). For on-premises to Azure replication, Windows Server licences for Azure VMs can use Azure Hybrid Benefit to reduce costs.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: test failover validates your DR plan in an isolated network without impacting production, recovery plans sequence multi-VM failover with manual gates and automation runbook steps, and failback returns workloads to the original region by reversing the replication direction after a disaster. Next up we explore Azure CDN for accelerating global content delivery.