Azure Site Recovery: A Comprehensive Guide

Azure Site Recovery is a cloud-based disaster recovery as a service (DRaaS) solution that helps protect your on-premises and cloud-based applications and services from outages and data loss. It's designed to ensure business continuity by replicating and recovering your workloads to a secondary location.

Azure Site Recovery supports a wide range of workloads, including virtual machines, physical servers, and even entire datacenters. This makes it a versatile solution for businesses of all sizes and complexity levels.

With Azure Site Recovery, you can create a disaster recovery plan that's tailored to your specific needs and budget. This includes choosing the right replication and recovery options, setting up failover and failback scenarios, and configuring alerting and monitoring.

Azure Site Recovery (ASR) is a disaster recovery as a service (DRaaS) offered by Azure. It's designed for cloud and hybrid cloud architectures.

ASR ensures data replication is near-constant, keeping copies in sync. This is achieved through a data replication process that happens continuously.

The application-consistent snapshot feature of ASR guarantees that data is in a usable state after a failover. This means you can rely on ASR to keep your data accessible.

ASR supports replication of various scenarios, including:

Note that ASR also supports replication of VMs in Hyper-V and VMware to a secondary site, but these scenarios are being deprecated and will no longer be supported by March 2023.

Azure Site Recovery offers a cost-effective solution for disaster recovery, with no compute, network infrastructure, facility rental, or software licensing fees required during ongoing protection. This means you only pay for the resources you consume during a failover event, making it a budget-friendly option.

The service also provides a high level of data resilience, with a minimum of three copies of your data available in locally-redundant storage (LRS) to protect against data center failures. For further protection, you can choose to use geo-redundant storage (GRS) to safeguard against regional outages.

Azure Site Recovery supports a heterogeneous workload, allowing you to protect Windows and Linux workloads hosted on physical servers, VMs in VMware/Hyper-V, and machines in third-party hosting platforms/cloud. This means you can easily replicate your workloads to Azure and bring them online in a matter of minutes.

The service also offers app-consistent replication, capturing in-memory data and transactions along with disk data to ensure that your recovery points are application-consistent. This is achieved through VSS for Windows and application custom scripts for Linux.

Here are some of the key benefits of Azure Site Recovery:

One of the real advantages of Azure Site Recovery is its integration with the Azure admin portal, requiring little effort to configure beyond the agent installation. This makes it a seamless addition to your disaster recovery strategy.

When planning a DRaaS strategy with Azure Site Recovery, there are several factors to consider. RTO and RPO goals, storage (IOPS and storage account), capacity planning, network bandwidth, network reconfiguration, and daily change rate are all important aspects to keep in mind.

The Azure Site Recovery Deployment Planner can help analyze your source environment for VMware and Hyper-V environments and plan for capacity and scale in the target Azure environment.

To ensure a smooth replication process, it's essential to review the support Matrix to understand the prerequisites and Azure Site Recovery limitations while replicating VMs and physical machines to Azure.

Network planning is also crucial, as customers can choose to retain existing IP addresses, but that would require failover of the entire subnet in addition to the machine. Alternatively, a new network range from Azure can be used if that works for the application architecture after failover.

It's also important to verify the kinds of workloads that can leverage app-agnostic protection, and to review the list of supported operating systems, the 4 TB limit for managed disks, and the 8 TB limit for disks on storage on each protected VM.

Azure Site Recovery supports replication from various source environments, including VMware, Hyper-V, physical servers, and Azure VMs. These environments have different requirements, such as additional resources needed for VMware VMs.

To prepare the source environment, you'll need to install the ASR Provider software on the local computer and set the configuration server to manage replication. You can also prepare the target environment in Azure by creating a Recovery Services Vault and storage and network accounts.

Replication settings include the virtual machines to be replicated, replication frequency, and target Azure region. You can define a replication policy based on your application, workload, or recovery point objective (RPO) requirements. A replication policy defines recovery-point retention, crash-consistent recovery points, and app-consistent recovery points.

To configure replication, you need to define the replication policy, including the recovery-point retention, crash-consistent recovery points, and app-consistent recovery points. The replication policy should align with your application, workload, or recovery point objective (RPO) requirements.

You can define a replication policy based on your needs, but the default settings are 24 hours for recovery-point retention, 5 minutes for crash-consistent recovery points, and 4 hours for app-consistent recovery points. You can adjust these settings to suit your requirements.

The replication policy also determines how often ASR creates snapshots of the VM disk, which can impact the server's resources. You can set the frequency to 1 hour or more for app-consistent recovery points, but be aware that this can add load to the server.

To replicate data to the cloud, you'll need to set up Azure resources, including a Recovery Services vault and virtual network. You'll also need to prepare the local environment by installing the ASR Provider software and setting up the configuration server.

The replication settings include the target Azure region, storage account, and virtual network. You can select a virtual machine or physical server to replicate and specify the replication settings, such as the target region and storage account.

Here are the key items you can define for the target environment during replication setup:

After configuring replication, it's essential to test the process to ensure it works as expected. You can do this by initiating a test failover, which simulates a disaster recovery scenario without impacting the production environment.

Multi-VM consistency is a powerful feature that allows multiple interdependent VMs to be replicated together, ensuring shared crash-consistent and app-consistent recovery points.

A replication group can contain a maximum of 16 VMs, so it's essential to plan ahead and determine which VMs need to be part of the group.

To enable multi-VM consistency, you must set up the replication group during replication setup, and all VMs in the group must be failed over at the same time.

This feature is quite resource intensive, so it's recommended to only enable it in scenarios where shared snapshots are crucial.

All VMs in the replication group must communicate with each other over port 20004, so make sure to configure any firewalls or network security groups to allow this traffic.

Implementing Azure Site Recovery involves several steps, but don't worry, it's a manageable process.

To start, you'll need to configure replication, which is the heart of Azure Site Recovery. This involves setting up the replication process to ensure that your data is safely backed up and can be recovered in case of a disaster.

After you have configured replication, it's essential to test the process to ensure that it works as expected. You can do this by initiating a test failover, which simulates a disaster recovery scenario without impacting the production environment.

A test failover creates a VM in a test network defined by you, with the replicated data. It's recommended that you set up an isolated test network without connectivity to the primary network to avoid accidental writes from test applications to the primary database or other unexpected issues.

Implementing Azure Site Recovery involves several steps. Here’s an overview of the process.

To start, you need to install the Site Recovery Provider, which is a crucial first step. This software is required to configure replication settings.

Configure replication settings, including the virtual machines that you want to replicate, the replication frequency, and the target Azure region. This is a critical step in ensuring your data is properly replicated.

You'll also need to set up Azure resources, including creating an Azure Recovery Services vault as the management basis for the ASR. This will help you manage your replication settings.

To prepare your local environment, install the ASR Provider software on the local computer and set the configuration server to manage replication. This will enable you to configure replication settings.

Configure replication settings by creating protection groups to define which computers and their locations are replicated. You'll also need to specify replication settings such as target Azure region, storage account, and virtual network.

Test and Failovers are crucial steps in the implementation and testing process of Azure Site Recovery (ASR). You can initiate a test failover to simulate a disaster recovery scenario without impacting the production environment.

A test failover creates a VM in a test network defined by you, with the replicated data. This allows you to make changes to the test VM without affecting the primary server or the replication.

You can perform test failovers to validate your VM and its workload failover as needed in the secondary region. This is useful for application or database upgrade testing or for compliance auditing reasons.

Test failovers can be done either through a recovery plan or manually for each VM through the Azure console.

A planned failover brings the VM online in the secondary region and allows changes to the VM to be committed to disk. Replication from the primary site is stopped during this process.

Here are the three types of failovers:

After a planned failover, don't forget to reprotect the machines after they have failed over. Once your source site is up, you can failback the VMs using the process server, master target server, and a failback policy.