Azure Site Recovery Features

Azure Site Recovery (ASR) can provide quick, simple, and cost-effective means to design and deploy a functional disaster recovery plan.  ASR can work with many on-premises technologies as well as within Azure.  Microsoft has tested out many crucial business applications to ensure ASR can provide failover capabilities.  In addition, you will find that ASR provides great flexibility and integration to test and implement your disaster recovery plan with little to no disruption in services.  In this article we will review the supported workloads of ASR as well as several of the key features and capabilities that come with the solution.

Supported Workloads

ASR can replicate and protect the following types of servers to Azure or a secondary site:

  • Hyper-V (System Center Virtual Machine Manager required to replicate Hyper-V to secondary site).
  • VMWare (requires VMWare Tools installed on VMs)
  • Physical server
  • Azure to another Azure region

ASR supports many workloads.  The servers must also meet Azure VM requirements.  The following list is primarily for VMWare and physical servers.  ASR supports any Hyper-V VM guest OS that is supported by Azure.

  • Windows operating system
    • 64-bit Windows Server 2016 (Server Core, Server with Desktop Experience)
    • Windows Server 2012 R2
    • Windows Server 2012
    • Windows Server 2008 R2 with at least SP1
  • Linux operating system
    • Red Hat Enterprise Linux: 5.2 to 5.11, 6.1 to 6.9, 7.0 to 7.4
    • CentOS: 5.2 to 5.11, 6.1 to 6.9, 7.0 to 7.4
    • Ubuntu 14.04 LTS server (supported kernel versions)
    • Ubuntu 16.04 LTS server (supported kernel versions)
    • Debian 7/Debian 8 (supported kernel versions)
    • Oracle Enterprise Linux 6.4, 6.5 running the Red Hat compatible kernel or Unbreakable Enterprise Kernel Release 3 (UEK3)
    • SUSE Linux Enterprise Server 11 SP3, SUSE Linux Enterprise Server 11 SP4
  • Active Directory and DNS
  • Web Apps (IIS and SQL)
  • Exchange
  • SharePoint
  • System Center Operations Manager
  • Windows File Server
  • SAP (non-cluster)
  • Oracle
  • Remote Desktop and VDI
  • Dynamics AX
  • Citrix XenApp\XenDesktop

Replication Policies

Recovery Time Objective (RTO) in ASR means the period when a failover starts to the time the process completes and a virtual machine is running in Azure.  Recovery Point Objective (RPO) is the maximum time of acceptance for data loss.  With ASR, you create replication policies to define specific settings that affect both RTO and RPO.  Replication policies are used to define certain parameters to obtain your desired RTO and RPO.  Replication policies are similar across supported types with some differences.  With Hyper-V you must specify a copy frequency of either 30 seconds or 5 minutes for recovery points.  With VMWare, physical machines, and Azure replication is continuous.  Additionally, you must specify retention of the recovery points.  Hyper-V allows for up to 24 hours, while all others can allow up to 72 hours of retention.  Finally, you need to select App-consistent snapshot frequency.  App-consistent snapshots capture disk data, all data in memory, and all transactions in process.  The following shows a sample policy for Hyper-V and VMWare.


ASR replicates data to an Azure storage account using a public endpoint rather than a VPN connection or using ExpressRoute public peering. Replication over a site-to-site VPN is not supported.

Failover and Failback

To be very clear the first thing to know regarding failover and failback…they are not automatic.  You must manually initiate a failover or failback from the Azure portal or Site Recovery PowerShell.  You can develop an automation task, but that involves using the ASR Software Development Kit (SDK).  There are three types of failovers, Test failover, planned failover, and failover.  A test failover validates your configuration and should be done during setup of ASR prior to any actual failover.  A planned failover is for known downtime or testing the execution of a DR plan.  There is minimal downtime and zero data loss.  A regular failover is due to an unplanned outage and data loss should be anticipated, but minimal.   A typical failover usually takes up to 10 minutes to complete, with some exceptions such as Physical or Linux servers.  When failing over, you can select a specific recovery point, whether it is the latest for the lowest RPO, latest, app-consistent, or custom for specific point in time.   Failbacks can take several hours depending on the circumstances. If the virtual machine already exists and the failover was not for an extended period, failback should be quick. If the VM no longer exists and needs recreated, the data needs to be downloaded to the failback location, which could take hours depending on size and connection speed.

Probably the most important task after failover or failback is to ensure the machine is configured with the correct network and IP address. You have two options for the IP address, use the same IP or a different. Using a new IP address, public or private, is the simplest method and in most cases just requires a DNS update. However, some complex scenarios may require the same IP address be used. If you wish to retain the same IP address you are required to failover the entire subnet the machine is on and update appropriate routing. In either case, you can pre-configure the Azure Virtual network and IP settings of a machine in ASR. In some scenarios, Azure Traffic Manager can be combined with ASR to further reduce RTO and network changes required.

For physical machines, planned failover is not supported. Also, when failing back you must fail back to an on-premises VMWare VM. You cannot fail back to an on-premises physical machine.

Recovery Plans

A recovery plan provides custom automation to failover and failback tasks.  You can group several servers together based on dependencies, such as Multi-tier web app, SQL AlwaysOn group, or Exchange DAG, so in a failover event all machines will failover together.  In addition, you can specify specific tasks, such as shut down, or even apply pre-failover or post-failover PowerShell scripts or Azure Automation runbooks to be run against each machine.



ASR can provide all the capabilities of any 3rd party tool or even a secondary datacenter location. Yet no additional infrastructure is required, failover and failback can occur with a single click, and its features are designed to best meet your RTO and RPO per your Business Continuity and Disaster Recovery Plan. Our next article will go over the planning and capacity requirements for ASR. Contact Enabling Technologies to allow us to see how we can assist with your BCDR goals. You can also check out our other Azure offerings at our Azure page on our website.


Work with our team of experts who have “been there, done that” experiences to help you navigate your IT challenges. Contact us at to schedule time with our team. 

Last updated on July 27th, 2023 at 01:37 pm