fbpx
Search
Close this search box.

Disaster Recovery Plans in Azure Site Recovery: A Practical Guide

a banner that reads, "how to use Azure Site Recovery for Disaster Recover Plans"
A disaster recovery plan is a documented, structured approach with instructions for responding to unplanned incidents.
Share This Post

A disaster recovery plan includes measures to minimize the effects of a disaster, enabling an organization to maintain or quickly resume mission-critical functions. It outlines procedures for dealing with sudden disruptions such as natural disasters, cyberattacks, or any event that could cause the loss of data or infrastructure.

In the Azure cloud, a common way to plan and automate disaster recovery processes is Azure Site Recovery (ASR). ASR is a service provided by Microsoft that ensures business continuity by orchestrating the replication, failover, and recovery of virtual machines and physical servers. It enables organizations to protect their applications and data from disruptions by replicating them to another location, whether that be within the same data center, to a secondary site, or to Azure cloud.

This service supports a broad range of operating systems and workloads, offering flexible replication options and integrated recovery plans. ASR simplifies the disaster recovery process by automating the replication and failover tasks. It provides a reliable recovery point objective (RPO) and recovery time objective (RTO), ensuring minimal downtime in the event of a disaster.

This is part of a series of articles about Azure disaster recovery

In this article:

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:

  1. 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.
  2. 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.
  3. 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).
  4. 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.
  5. 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.
  6. 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:

  1. Navigate to Recovery Plans: In the Recovery Services vault, choose Recovery Plans (Site Recovery) and then +Recovery Plan.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Add a Group to the Plan

To add additional groups to your recovery plan, follow these steps:

  1. Customize the Plan: Under Recovery Plans, right-click the plan and select Customize. By default, all machines are initially placed in Group 1.
  2. 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.
  3. 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

To customize a recovery plan with scripts or manual actions, follow these steps:

  1. 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.
  2. 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.
  3. 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.
  4. Test the Plan: Run a test failover to ensure that the script or manual action functions as expected.

Here are 5 tips that can help you better utilize Azure Site Recovery (ASR) for disaster recovery plans:

Tips from the Expert
Picture of Adam Bertram
Adam Bertram
Adam Bertram is a 20-year veteran of IT. He’s an automation engineer, blogger, consultant, freelance writer, Pluralsight course author and content marketing advisor to multiple technology companies. Adam focuses on DevOps, system management, and automation technologies as well as various cloud platforms. He is a Microsoft Cloud and Datacenter Management MVP who absorbs knowledge from the IT field and explains it in an easy-to-understand fashion. Catch up on Adam’s articles at adamtheautomator.com, connect on LinkedIn or follow him on X at @adbertram.

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 DR drill is a simulation exercise designed to verify the effectiveness of your disaster recovery plan. This drill aims to ensure that your organization can restore data and services within the stipulated recovery time objective (RTO) and recovery point objective (RPO). 

The RTO defines the maximum acceptable duration of time that your IT systems can be offline, while the RPO sets the maximum acceptable amount of data loss measured in time. For example, an RPO of one day means you should have daily backups and be able to restore data up to the last backup.

An image of Failover test success from Azure
Source: Azure

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:

  1. 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.
  2. Access Disaster Recovery Settings: In the resource menu, scroll to Operations and choose Disaster Recovery. A new pane called Replicated items will appear.
  3. 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.
  4. 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.
  5. 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.
A screenshot from Azure's Disaster recovery panel
Source: Azure

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.

A screenshot from Azure showing a Test failover
Source: Azure

Here’s how to manage these tests:

  1. Create a Recovery Plan: Include multiple VMs in a single recovery plan. This plan allows for flexible testing policies and scenarios.
  2. 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.
  3. 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 disaster recovery solutions are capable of handling actual disaster scenarios.

Disaster Recovery for Azure VMs with N2WS

N2WS provides robust disaster recovery solutions for Azure virtual machines (VMs) and disks, ensuring minimal downtime and data protection. It offers a comprehensive, centralized console for managing backup and recovery operations across both Azure and AWS environments. 

N2WS provides the following key capabilities for Azure users:

  • Quick setup and central monitoring: Deployment of N2WS is straightforward, allowing users to set up from the Azure Marketplace within minutes. This ease of deployment is complemented by a centralized monitoring system for overseeing backup operations across different cloud environments.
  • Customizable backup policies and rapid recovery: N2WS allows for the automation of backups with customizable policies and retention schedules. This flexibility enables users to set backup intervals as frequently as every five minutes, ensuring that data is consistently protected. In case of a disaster, N2WS facilitates near-instant, one-click recovery, significantly reducing recovery time objectives (RTO).
  • Real-time alerts and comprehensive reporting: N2WS includes real-time alert features that notify users about the status of their Azure backups. Additionally, the platform offers detailed, digestible reports that can be shared with executives and other stakeholders.
  • File-level recovery and cross-cloud restore: N2WS supports file-level recovery, allowing users to browse through multiple backup generations and restore individual files or folders as needed. The platform also offers cross-cloud restore capabilities, enabling data to be copied from AWS into Azure. This feature ensures a comprehensive disaster recovery plan that can protect data across different cloud environments.
  • Multi-cloud flexibility and efficiency: Version 4.0 of N2WS brings enhanced multi-cloud flexibility, allowing users to manage Azure and AWS resources seamlessly. This centralization reduces the complexity associated with using multiple tools for different clouds, streamlining backup management and improving overall efficiency.
  • Recovery Scenarios: With N2WS, you can run disaster recovery drills and send reports to team leaders automatically. You can also orchestrate a complete failover, restoring any number of resources in the order you’ve specified, in just a few clicks.

Learn more about N2WS for Azure backup and disaster recovery

Next step

The easier way to recover Azure workloads

Allowed us to save over $1 million in the management of AWS EBS snapshots...

N2WS vs AWS Backup

Why chose N2WS over AWS Backup? Find out the critical differences here.

N2WS in comparison to AWS Backup, offers a single console to manage backups across accounts or clouds. Here is a stylized screenshot of the N2WS dashboard.