Azure Site Recovery (ASR) is Microsoft’s business continuity disaster recovery (BCDR) service hosted in Azure. Azure Site Recovery is used to protect computing resources in Azure and on-premises. This article will address ASR use cases with Azure Virtual Desktop (AVD) and when it may or may not be necessary.

Recovery Objectives

Understanding Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) is helpful when considering BCDR solutions. The RTO indicates the amount of time it takes to recover a system. Some high-priority systems may require near real-time failovers and a low RTO. The RTO for other low-priority systems may be hours or even days.

The RPO indicates how much data can be lost in the event of a failure and relates to the frequency of data protection or backup jobs. High-priority systems such as order processing may need a low RPO to prevent any data loss in the event of an outage. Low-priority systems may have a longer RPO.

The RPO and RTO are the north stars for BCDR planning. Together they establish the requirements for how systems are protected. A short RPO and RTO for critical systems requires different backup infrastructure and data replication than those needed to maintain systems with longer RPO and RTO. The cost to implement a short RPO and RTO is generally higher than required for a longer RPO and RTO. Organizations often implement a multi-tiered protection strategy due to the cost of implementing low RPO and RTO solutions.

When to Use ASR with AVD?

Azure Site Recovery is a cloud-based BCDR solution that provides low RPO and RTO. When used with AVD, it can protect session hosts in near real-time. This is accomplished by replicating session host data to a secondary recovery region. If session hosts in the primary region become unavailable, the session hosts can be quickly recovered to a second region where they are available to the clients.  

Not every implementation requires the low RPO and RTO provided by ASR. Azure Virtual Desktop has different configurations available, and the BCDR strategy will depend on the host pool configuration and the RTO requirements of the host pool. Learn more about disaster recovery optimizations for AVD here.

The configuration options for an AVD host pool include pooled multi-user, pooled single-user, and a personal host pool.  The two main categories of pooled and personal host pools should be considered when evaluating ASR.

Pooled Host Pools

Users are not assigned to a specific desktop with a pooled host pool. Users log into any available session host to access remote desktop or remote app services. The user profile is stored on FSLogix and connected to each user session at log in. 

Session hosts in a pooled host pool have no unique data. They can be removed and recreated without impacting user data because their profiles are hosted in FSLogix. In the event of an outage with session hosts on a pooled host pool, ASR may have little advantage over simply rebuilding session hosts in an alternative Azure region.

Another option for pooled host poos is to build a “stand-by” pool in a failover region. This configuration creates session hosts in the primary and failover regions. The session hosts in the failover region are deallocated and brought online if the primary becomes unavailable. 

Personal Host Pools

A personal host pool creates a one-to-one relationship between the user and the session host.  A personal host pool uses a single-user OS. The users log into the same desktop every time they connect to AVD.  Because the user logs into the same computer, FSLogix for profiles is not required, although it can be used. 

Using ASR with personal host pools depends on the deployment scenario. For example, an organization may use a personal host pool with a standardized image, locked down so the user can’t make changes and FSLogix to store user profiles. In this scenario, the session host has no unique data and could be rebuilt in a recovery region like a pooled host pool.

Session hosts in a personal host pool are assigned to a user. FSLogix can be used but is not required as the user logs into the same session host. In addition, some organizations may allow users to modify the session hosts, adding software or utilities to the user’s session host. In this scenario, the session hosts have unique data that can’t be quickly recreated in a failover region.  Recreating the session host would include deploying a new session host, installing applications, and rebuilding the user profiles. These steps would significantly increase the RTO.

Azure Site Recovery is a good option for session hosts in a personal host pool that stores unique user data and custom configurations. With ASR, the session hosts are replicated to a recovery region and brought online rapidly if they become unable in the primary region.

Image Management

Always replicate custom images when using a rebuild strategy in a failover region. Some organizations use customized images with applications and settings specific to the environment. Images are only available to deploy session hosts in the region the images are stored. It’s not possible to build a session host in East US 2 if the image is in Central US, for example. 

Replicating the image to a failover region is an important step for BCDR planning.  If the primary region is unavailable, the image must be available in the recovery region to deploy new session hosts. Azure Compute Gallery is an Azure service used to store and replicate images. 

FSLogix Profiles

FSLogix user profiles are another consideration for BCDR planning with AVD. Azure Site Recovery protects servers, not storage accounts. Currently, there is no native Azure feature to replicate Azure Files Premium or Standard storage account with large file support enabled to a failover region.  Consider using Cloud Cache to maintain multiple copies of the profile data at the primary and recovery region or Azure NetApp Files to replicate a copy of the profiles to a secondary region.

Summary

Azure Site Recovery is a good option for systems that require low RPO and RTO including AVD host pools that can’t be quickly rebuilt at a recovery region.  However, not all deployments require protecting Azure Virtual Desktop with ASR.  Rebuilding session hosts may be suitable for pooled host pools with no unique data where FSLogix is used for user profiles.