Skip to content
Editor’s note: Updated the article to cover recent market trends as of 2026.
What Is an Azure Site Recovery Plan?
An Azure Site Recovery (ASR) recovery plan sets which machines failover together and in what order, so a multi-tier application comes back cleanly instead of piecemeal. This guide covers how to create, customize, and test those plans, the operational layer of your Azure disaster recovery strategy and architecture.
In this article:
- Azure Disaster Recovery Trends and New Developments
- How Do Disaster Recovery Plans Work in ASR?
- Quick Tutorial #1: Creating
- Quick Tutorial #2: Testing
Azure Disaster Recovery Trends and New Developments
Azure disaster recovery planning is evolving from basic VM replication toward broader cloud resilience management. Microsoft now positions resiliency as a unified practice that includes zone resilience, high availability, backup, disaster recovery, and ransomware protection, rather than treating disaster recovery as a standalone process. This reflects a larger shift in Azure environments: organizations are expected to continuously assess their protection posture, monitor risks, and recover workloads across multiple failure scenarios.
Important developments include:
- The growing integration between Azure Site Recovery and Azure Monitor: Azure Site Recovery now surfaces built-in alerts through Azure Monitor for critical events such as unhealthy replication, failover failures, and agent expiration. These alerts can be viewed through Azure Business Continuity Center, Azure Monitor, or Recovery Services vaults, and routed to notification channels such as email, ITSM tools, webhooks, and SMS. This makes disaster recovery more operational and proactive, helping teams identify replication or recovery issues before an actual outage occurs.
- Security as a larger part of Azure disaster recovery strategy: Azure Site Recovery supports disaster recovery for trusted launch virtual machines, which are designed to help protect workloads against advanced and persistent attack techniques. This is especially relevant as more disaster recovery plans account not only for infrastructure failures and regional outages, but also for cyber incidents such as ransomware, compromised boot chains, and unauthorized changes to critical systems.
- The move toward centralized business continuity visibility: Azure’s resiliency tools are increasingly focused on giving organizations a single view of their protection estate, including backup, disaster recovery, security level, monitoring, reporting, and recovery readiness. For enterprises running distributed or hybrid environments, this helps standardize recovery planning across workloads and reduces the risk that individual systems are protected inconsistently.
How Do Disaster Recovery Plans Work in ASR?
Azure Site Recovery simplifies disaster recovery by automating the replication, failover, and failback of virtual and physical machines. The process begins with setting up the source environment, where the machines to be protected are identified and configured for replication.
Here’s an overview of the workflow:
- Initial replication: Once machines are selected for protection, ASR performs an initial replication. This involves copying the entire data set from the source to the target location. The target can be another Azure region or an on-premises data center. This step ensures that the secondary site has an up-to-date copy of the source environment.
- Continuous data replication: After the initial replication, ASR continuously synchronizes changes from the source to the target location. This continuous replication ensures that the target environment remains current and reduces data loss in the event of a failover.
- Replication policies: Administrators can configure replication policies to define the frequency of recovery points, retention periods, and bandwidth usage. These policies help manage the replication process and ensure it aligns with the organization’s recovery point objective (RPO).
- Failover process: During a failover, ASR orchestrates the process of switching operations from the primary site to the secondary site. This can be initiated manually or automatically based on predefined criteria. The failover process involves starting the replicated machines in the target environment and ensuring they are operational.
- Failback process: Once the primary site is restored, ASR can reverse the replication direction, enabling the data and operations to be moved back to the original site. This failback process is critical for returning to normal operations and involves synchronizing changes from the secondary site back to the primary site.
- Testing and validation: ASR allows for non-disruptive test failovers, which enable organizations to validate their disaster recovery plans without affecting production environments. These tests help ensure that the recovery plan works as expected and meets the defined RPO and RTO.
Quick Tutorial #1: Creating and Customizing Recovery Plans in Azure Site Recovery
Create a Recovery Plan
To create a recovery plan in Azure Site Recovery, follow these steps:
- Navigate to Recovery Plans: In the Recovery Services vault, choose Recovery Plans (Site Recovery) and then +Recovery Plan.
- Specify Plan Details: In the Create Recovery Plan window, provide a name for the plan. Choose a source and target based on the machines included in the plan, and select Resource Manager for the deployment model. Ensure the source location has machines enabled for failover and recovery.
- Select Failover Source and Target Options:
- Azure to Azure: Select the appropriate Azure region for both source and target.
- VMware to Azure: Select the configuration server for the source and Azure for the target.
- Physical machines to Azure: Select the configuration server for the source and Azure for the target.
- Hyper-V to Azure: Select the Hyper-V site name for the source and Azure for the target.
- Hyper-V (managed by VMM) to Azure: Select the VMM server for the source and Azure for the target.
- Select Virtual Machines: Under Select items virtual machines, choose the machines or replication group to add to the plan, then click OK. Machines are added to the default group in the plan.
- Finalize the Plan: Select OK to create the recovery plan.
When creating a recovery plan, take note of the following considerations:
- Recovery plans can be used for both failover to Azure and failback from Azure.
- Machines included in the plan must be enabled for failover and recovery.
- Plans can include VMware VMs and Hyper-V VMs managed by VMM.
- All VMs in a recovery plan must replicate into a single subscription. For different subscriptions, create separate recovery plans.
⚠️ NOTE: The default plan boots every VM at once. For a multi-tier app, customize the boot order so the tiers come up in sequence. That’s where Groups come in.
Add a Group to the Plan
To add additional groups to your recovery plan, follow these steps:
- Customize the Plan: Under Recovery Plans, right-click the plan and select Customize. By default, all machines are initially placed in Group 1.
- Add a New Group: Click +Group to add a new group. Groups are numbered sequentially as they are added, with a maximum of seven groups allowed.
- Move Machines to Groups: Select the machine you want to move, click Change group, and then choose the new group. Alternatively, right-click the group name, select Protected item, and add machines to the group. Note that each machine or replication group can belong to only one group within a recovery plan.
Customize the Recovery Plan
Add steps to a group when a boot alone isn’t enough. A manual action pauses the plan for a human check. A script action runs an Azure Automation runbook, for example to attach a load balancer, assign a public IP, or run a health probe before the next group starts.
To customize a recovery plan with scripts or manual actions, follow these steps:
- Integrate Scripts: If replicating to Azure, integrate Azure automation runbooks into the recovery plan. For Hyper-V VMs managed by System Center VMM, create a script on the on-premises VMM server and include it in the plan.
- Adding Actions: In the recovery plan, select the step where you want to add the action. Specify whether the action should occur before (pre-action) or after (post-action) the machines in the group start after failover. Click Insert action, then choose Script or Manual action.
- Define manual action or script:
- Manual Actions: Provide a name and instructions for the manual action. The person running the failover will follow these instructions. Specify whether the manual action applies to all types of failover (Test, Failover, Planned failover), then click OK.
- Script Actions: For failover to VMM script, type the relative path to the share where the script is located. For Azure Runbooks, specify the Azure Automation Account and select the appropriate runbook script.
- Test the Plan: Run a test failover to ensure that the script or manual action functions as expected.
A good recovery plan mirrors your application’s real dependency order, so the app comes back usable, not just powered on.
Here are 5 tips that can help you better utilize Azure Site Recovery (ASR) for disaster recovery plans:
- Implement incremental backup strategies: Use incremental backups to minimize storage costs and reduce the time required for the initial replication. Incremental backups capture only the changes made since the last backup, ensuring efficient use of resources.
- Leverage Azure Automation for advanced scripts: Utilize Azure Automation to create advanced scripts that can be integrated into your recovery plans. These scripts can automate complex tasks such as configuring network settings, updating DNS records, or triggering custom notifications.
- Optimize bandwidth usage for replication: To avoid bandwidth bottlenecks during replication, configure throttling settings within ASR. This helps maintain network performance for other critical business operations while still ensuring data replication occurs smoothly.
- Utilize network security groups (NSGs) in failover sites: Ensure that your failover sites have properly configured NSGs to control inbound and outbound traffic. This adds an extra layer of security and helps prevent unauthorized access during a failover event.
- Plan for post-failover validation: After a failover, conduct thorough validation to ensure all systems are operating correctly. This includes verifying application functionality, data integrity, and performance benchmarks. Plan for potential adjustments and fixes that may be necessary to achieve full operational status.
Quick Tutorial #2: Testing Your Azure Disaster Recovery Plan with DR Drills
What Are Disaster Recovery Drills in ASR?
Azure Site Recovery actively prompts users to conduct disaster recovery drills via the Site Recovery dashboard, helping maintain readiness for real disaster events.
A test failover proves the plan works without touching production. Run drills on a schedule (quarterly is a common cadence), always into an isolated network, and write down what broke and what you fixed. An untested plan tends to fail the one time you need it.
Create a Failover Test
Creating a failover test involves setting up an isolated virtual network to avoid impacting your production infrastructure. Here’s a step-by-step guide:
- Open the Target VM: Navigate to the virtual machine (VM) you want to test, such as a VM named “patient-records”. Filter resources by type to find virtual machines, and select the relevant VM from the list.
- Access Disaster Recovery Settings: In the resource menu, scroll to Operations and choose Disaster Recovery. A new pane called Replicated items will appear.
- Initiate Test Failover: Wait until the status field shows Protected, then click on Test Failover from the top menu bar. Choose your virtual network from the Azure virtual network drop-down and click Test failover.
- Validate the Test: Monitor the progress on the Site Recovery jobs page by checking the Notifications icon. Once the failover is complete, verify that the VM appears under Virtual Machines in the recovery region. Ensure the VM is running correctly, is appropriately sized, and mirrors the source VM.
- Cleanup After Testing: After validating the test, delete the replicated VM by selecting Cleanup test failover on the Disaster Recovery pane. Add notes about the test outcome and check the box for Testing is complete to finalize the cleanup. Then click OK.
Enable Flexible Failover for Multiple Machines
Azure Site Recovery allows you to perform DR tests for multiple VMs simultaneously. You can create recovery plans encompassing various VMs, enabling you to test different infrastructure combinations as needed.
Here’s how to manage these tests:
- Create a Recovery Plan: Include multiple VMs in a single recovery plan. This plan allows for flexible testing policies and scenarios.
- Run Failover Tests: Execute the failover tests as often as necessary, ensuring each VM and combination is adequately tested. Track the execution of these tests via the failover dashboard.
- Cleanup After Tests: Similar to single VM tests, clean up after completing the failover tests. Use the test cleanup option available for the entire recovery plan to ensure all components return to their original state.
By conducting these drills and tests, organizations can ensure their cloud disaster recovery solutions are capable of handling actual disaster scenarios.
Operational tips
- Match groups to dependencies. Boot order is the difference between an app that works after failover and a set of running VMs that can’t reach each other.
- Automate the fiddly post-failover steps (public IPs, load balancers, DNS) with runbooks, so recovery doesn’t hinge on someone remembering them under pressure.
- Keep the test network isolated and reuse it, so drills stay repeatable and safe.
- Watch RTO and RPO per tier. Site Recovery replicates continuously, so RPO is usually seconds to minutes; your RTO is mostly boot order plus post-failover steps.
- Pair Site Recovery (regional failover) with backup (Azure Backup or N2W) for the data-loss and ransomware cases replication alone can’t fix.
Frequently asked questions
A recovery plan groups the machines that fail over together and sets the order they come back in, so a multi-tier app recovers in the right sequence. You can add manual steps, scripts, or Azure Automation runbooks to it.
Use the test failover option in Azure Site Recovery. It spins up your replicated VMs in an isolated network in the secondary region, so you can verify recovery while production keeps running. Clean up the test resources when you’re done.
Failover brings your workloads up in the secondary region. Commit finalizes that failover. Failback returns them to the primary region once it’s healthy again. Each maps to an az site-recovery command you can automate.
Yes, and the tooling splits by task. You can create and update the plans themselves with the Azure CLI (az site-recovery recovery-plan). You run the failovers with PowerShell (the Az.RecoveryServices cmdlets) or the REST API, usually inside an Azure Automation runbook, since the CLI has no failover command. To make it easier, a backup and DR tool like N2W handles the whole cycle, running cross-region recovery and test drills on a schedule.
Disaster Recovery for Azure VMs with N2W
ASR is a powerful solution when low-RPO, region-level failover is truly required, but it is not designed to be the universal protection model across an entire Azure estate.
This is where N2W complements ASR by providing a broader, more cost-aligned recovery strategy for the rest of the environment. By combining replication for Tier 0 and Tier 1 workloads with N2W’s policy-driven backup, long-term retention, immutable storage, and point-in-time recovery, customers achieve a more complete and resilient disaster recovery posture.
In practice, ASR ensures rapid failover where it matters most, while N2W ensures everything else is protected, recoverable, and optimized for cost, compliance, and cyber resilience.
N2W provides robust disaster recovery solutions for Azure virtual machines (VMs) and disks with a comprehensive, centralized console for managing backup and recovery operations across both Azure and AWS environments.