Common questions about Azure-to-Azure disaster recovery

This article answers common questions about disaster recovery of Azure virtual machines to another Azure region, using the Azure Site Recovery service.

Learn about cost for Azure VM disaster recovery.

Every instance that's protected with Site Recovery is free for the first 31 days of protection. After that period, protection for each instance is at the rates summarized in pricing details. You can estimate costs using the Azure pricing calculator.

Yes. Even though Azure Site Recovery is free during the first 31 days of a protected instance, you might incur charges for Azure Storage, storage transactions, and data transfers. A recovered VM might also incur Azure compute charges.

1. Understand the Azure virtual machine disaster recovery architecture.
2. Review support requirements.
3. Set up disaster recovery for Azure virtual machines.
4. Run a disaster recovery drill with a test failover.
5. Run a full failover to a secondary Azure region.
6. Fail back from the secondary region to the primary region.

The Site Recovery team, and the Azure capacity management team, plan for sufficient infrastructure capacity. When you start a failover, the teams also help ensure that virtual machine instances protected by Site Recovery deploy to the target region.

Yes. Site Recovery supports disaster recovery of virtual machines that have Azure Disk Encryption (ADE) enabled. When you enable replication, Azure copies all the required disk encryption keys and secrets from the source region to the target region, in the user context. If you don't have required permissions, your security administrator can use a script to copy the keys and secrets.

• Site Recovery supports ADE for Azure virtual machines running Windows.
• Site Recovery supports:
  • ADE version 0.1, which has a schema that requires Microsoft Entra ID.
  • ADE version 1.1, which doesn't require Microsoft Entra ID. For version 1.1, Azure virtual machines must have managed disks.
  • Learn more about the extension schemas.

Learn more about enabling replication for encrypted virtual machines.

See the support matrix for information about support for other encryption features.

When you allow Site Recovery to manage updates for the Mobility service extension running on replicated Azure virtual machines, it deploys a global runbook (used by Azure services), via an Azure Automation account. You can use the automation account that Site Recovery creates, or select to use an existing automation account.

Currently, in the portal, you can only select an automation account in the same resource group as the vault. You can select an automation account from a different resource group using PowerShell.

Yes, you can delete it if you don't need it.

No, it won't have any impact on the ongoing replication because the server is already protected through Azure Site Recovery.

Yes, you can replicate Azure virtual machines to any subscription within the same Microsoft Entra tenant. When you enable disaster recovery for virtual machines, by default the target subscription shown is that of the source virtual machine. You can modify the target subscription, and other settings (such as resource group and virtual network), are populated automatically from the selected subscription.

Yes, you can exclude disks when you set up replication, using PowerShell. Learn more about excluding disks.

For replicated virtual machines with managed disks, you can add new disks, and enable replication for them. When you add a new disk, the replicated virtual machine shows a warning message that one or more disks on the virtual machine are available for protection.

• If you enable replication for the added disks, the warning disappears after the initial replication.
• If you don't want to enable replication for the disk, you can dismiss the warning.
• If you fail over a virtual machine with added disks, replication points show the disks available for recovery. For example, if you add a second disk to a virtual machine with one disk, a replication point created before you added shows as 1 of 2 disks.
• If you perform an OS Disk swap, you're required to perform disable and enable replication, since Site Recovery doesn't support swapping the OS disk.

Site Recovery doesn't support hot remove of disks from a replicated virtual machine. If you remove a virtual machine disk, you need to disable and then reenable replication for the virtual machine.

Replication is continuous when replicating Azure virtual machines to another Azure region. Learn more about the replication process.

You can't use Site Recovery to replicate non-zoned virtual machines within a region. But you can replicate zoned machines to a different zone in the same region.

You can replicate and recover virtual machines between any two regions.

No, but virtual machines need access to Site Recovery URLs and IP ranges. Learn more.

Yes, you can replicate the app, and keep the disaster recovery configuration in a separate resource group.

For example, if the apps have three tiers (application/database/web) in different resource groups, you need to enable replication three times, to protect all tiers. Site Recovery replicates the three tiers into three different resource groups.

No, this is unsupported. If you accidentally move storage accounts to a different resource group and delete the original resource group, then you can create a new resource group with the same name as the old resource group, and then move the storage account to this resource group.

The Azure portal displays logical Zones. In the datacenter, actual physical zones are mapped to these logical zones, and the mappings vary by subscription. For example, Subscription A's Zone 1 may map to Physical Zone 1, while Subscription B's Zone 1 may map to Physical Zone 2. Therefore, you see different mapped zones for different subscriptions in the same region. In Site Recovery, the source and target zones must have different physical zones.

In case the source and target zones are the same, you can't view zone for target configuration while enabling zonal replication.

Azure Site Recovery supports both 512 and 4096 sector size disks in public preview.

Azure Site Recovery supports live resync. Once resize is completed, resync of Replica disk is performed by Azure Site Recovery and the older recovery points are deleted. Once the resync is completed and new recovery points start generating, you can failover using the new recovery points.

The RPO and RTO SLAs of Azure Site Recovery remain the same for both disk types. However, Premium SSD v2 disks takes more time to complete the enable protection process. Also, as Azure Site Recovery uses Premium SSD v1 disks as replica disks, during failover, the new Premium SSD v2 disks created in target using the replica disk, would need some time for data hydration. However, this would not impact the environment availability.

The Premium SSD v2 disks use Standard Page Blob snapshots in source, and Premium Snapshots in target. If the visible snapshots are deleted, Azure Site Recovery will have to resync.

Azure Site Recovery for Premium SSD v2 has Premium Cache Storage account as default, which reflects as High Churn. While you enable Azure Site Recovery from PowerShell ensure that the cache storage account used is premium.

No, Azure Site Recovery does not support Linux VMs with shared disks. Only VMs with WSFC-based shared disks are supported.

Yes, it is supported.

No, enable replication can only be enabled successfully when all the VMs attached to a shared disk are selected.

Yes, the first time you don’t select all the VMs in Enable Replication, a warning appears mentioning the unselected VMs attached to the shared disk. If you still proceed, unselect the shared disk replication by selecting ‘No’ for the storage option in Replication Settings tab.

Yes, you can restart the job without reselecting clusters, just like other A2A scenarios. However, since the enable replication process runs for each node, you need to restart the failed job for all nodes through the Site Recovery Jobs interface.

No, if new shared disks need to be added, disable the replication for the already protected cluster. Enable a new cluster protection with a new cluster name for the modified infrastructure.

No, Azure Site Recovery for Shared Disks supports only Crash consistent recovery points.

No, recovery plans are not supported for shared disks in Azure Site Recovery.

A replication policy defines the retention history of recovery points, and the frequency of app-consistent snapshots. Site Recovery creates a default replication policy as follows:

• Retain recovery points for one day.
• App-consistent snapshots are disabled and aren't created by default.

Learn more about replication settings.

A crash-consistent recovery point contains on-disk data, as if you pulled the power cord from the server during the snapshot. It doesn't include anything that was in memory when the snapshot was taken.

Today, most apps can recover well from crash-consistent snapshots. A crash-consistent recovery point is enough for nondatabase operating systems, and apps such as file servers, DHCP servers, and print servers.

Site Recovery automatically creates a crash-consistent recovery point every five minutes.

App-consistent recovery points are created from app-consistent snapshots. They capture the same data as crash-consistent snapshots, and in addition capture data in memory, and all transactions in process.

Because of extra content, app-consistent snapshots are the most involved, and take the longest. We recommend app-consistent recovery points for database operating systems, and apps such as SQL Server. For Windows, app-consistent snapshots use the Volume Shadow Copy Service (VSS).

Because app-consistent recovery points capture all data in memory and process, if they capture frequently, it can affect performance when the workload is already busy. We don't recommend that you capture too often for nondatabase workloads. Even for database workloads, one hour should be enough.

Site Recovery can create app-consistent recovery points with a minimum frequency of one hour.

Yes. The Mobility agent for Linux support custom scripts for app-consistency. A custom script with pre and post-options is used by the agent. Learn more

To understand how Site Recovery generates recovery points, let's use an example.

• A replication policy retains recovery points for one day, and takes an app-consistent snapshot every hour.
• Site Recovery creates a crash-consistent recovery point every five minutes. You can't change this frequency.
• Site Recovery prunes recovery points after two hours, saving one point per hour.

So, for the recent two hours, you can choose from 24 crash-consistent points, and two app-consistent points, as shown in the graphic.

The oldest recovery point that you can use is 15 days with Managed disk and three days with Unmanaged disk.

Crash-consistent recovery points are generated in every five minutes. App-consistent snapshots are generated based on the input frequency entered by you. Beyond two hours, pruning of recovery points may happen based on the retention period that you input. Following are the scenarios:

If you have a replication policy of one day, and Site Recovery can't generate recovery points for more than one day, your old recovery points remain. Site Recovery only replaces the oldest point if it generates new points. Until there are new recovery points, all the old points remain after you reach the retention window.

Yes. In the vault > Site Recovery Infrastructure > Replication policies, select and edit the policy. Changes apply to existing policies too.

The first recovery point that's generated has the complete copy. Successive recovery points have delta changes.

Yes. For example, if you increase retention from one day to three days, Site Recovery saves recovery points for an additional two days. The added time incurs storage changes. Earlier, it was saving recovery points per hour for one day. Now, it is saving recovery points per two hours for 3 days. Refer pruning of recovery points. So additional 12 recovery points are saved. As an example only, if a single recovery point had delta changes of 10 GB, with a per-GB cost of $0.16 per month, then additional charges would be $1.60 × 12 per month.

Multi-VM consistency ensures that recovery points are consistent across replicated virtual machines.

• When you enable multi-VM consistency, Site Recovery creates a replication group of all the machines with the option enabled.
• When you fail over the machines in the replication group, they have shared crash-consistent and app-consistent recovery points.

Learn how to enable multi-VM consistency.

No. When you enable multi-VM consistency, it infers that an app has a dependency on all virtual machines in the replication group, and single virtual machine failover isn't allowed.

You can replicate 16 virtual machines together in a replication group.

Multi-VM consistency is CPU intensive, and enabling it can affect workload performance. Enable only if virtual machines are running the same workload, and you need consistency across multiple machines. For example, if you have two SQL Server instances and two web servers in an application, enable multi-VM consistency for the SQL Server instances only.

You cannot add a protected VM to an existing replication group.

The Site Recovery team, and Azure capacity management team, plan for sufficient infrastructure capacity on a best-effort basis. When you start a failover, the teams also help ensure virtual machine instances that are protected by Site Recovery can deploy to the target region.

Failover isn't automatic. You can start a failover with a single click in the portal, or use PowerShell to trigger a failover.

You can't keep the public IP address for a production app after a failover.

When you bring up a workload as part of the failover process, you need to assign an Azure public IP address resource to it. The resource must be available in the target region. You can assign the Azure public IP address resource manually, or you can automate it with a recovery plan. Learn how to set up public IP addresses after failover.

Yes. By default, when you enable disaster recovery for Azure virtual machines, Site Recovery creates target resources, based on source resource settings. For Azure virtual machines configured with static IP addresses, Site Recovery tries to provision the same IP address for the target virtual machine, if it's not in use. Learn more about keeping IP addresses after failover.

Site Recovery tries to provide the IP address at the time of failover. If another virtual machine uses that address, Site Recovery sets the next available IP address as the target.

Learn more about setting up network mapping and IP addressing for virtual networks.

The Latest (lowest RPO) recovery point option provides the lowest recovery point objective (RPO). It first processes all the data that has been sent to Site Recovery service, to create a recovery point for each virtual machine, before failing over to it. It initially attempts to process and apply all data sent to Site Recovery service in the target location and create a recovery point using the processed data. However, if at the time failover was triggered, there is no data uploaded to Site Recovery service waiting to be processed, Azure Site Recovery won't perform any processing and hence, won't create a new recovery point. In this scenario, it will instead failover using the previously processed recovery point only.

Yes. Site Recovery processes all pending data before failing over, so this option has a higher recovery time objective (RTO) than other options.

The Latest processed option does the following:

1. It fails over all virtual machines to the latest recovery point processed by Site Recovery. This option provides a low RTO, because no time is spent processing unprocessed data.

You can start failover. Site Recovery doesn't need connectivity from the primary region to do the failover.

Site Recovery has an RTO SLA of one hours. Most of the time, Site Recovery fails over virtual machines within minutes. To calculate the RTO, review the failover job, which shows the time it took to bring up a virtual machine.

A recovery plan in Site Recovery orchestrates the failover and recovery of virtual machines. It helps make recovery consistently accurate, repeatable, and automated. It does the following:

• Defines a group of virtual machines that fail over together
• Defines the dependencies between virtual machines, so that the application comes up accurately.
• Automates recovery, with the option of custom manual actions for tasks other than virtual machine failover.

In a recovery plan, you can create up to 7 groups of virtual machine for sequencing. Groups failover one at a time, so that virtual machines that are part of the same group failover together. Learn more.

To check the RTO of a recovery plan, do a test failover for the recovery plan. In Site Recovery jobs, check the test failover duration. In the example screenshot, the SAPTestRecoveryPlan test failover job took 8 minutes and 59 seconds.

Yes. Learn more.

No. When you fail over virtual machines from one region to another, the virtual machines start up in the target disaster recovery region in an unprotected state. To reprotect virtual machines in the secondary region, you enable replication back to the primary region.

It depends. If the source region virtual machine exists, then only changes between the source disk and the target disk are synchronized. Site Recovery compares the disks to what's different, and then it transfers the data. This process usually takes a few hours. Learn more.

After reprotection, failback takes about the same amount of time it took to fail over from the primary region to a secondary region.

The Site Recovery team and Azure capacity management team plan for sufficient infrastructure capacity on a best-effort basis. When you start a failover, the teams also help ensure virtual machine instances that are protected by Site Recovery can deploy to the target region.

No, Site Recovery doesn't intercept replicated data, and it doesn't have any information about what's running on your virtual machines. Only the metadata needed to orchestrate replication and failover is sent to the Site Recovery service.

Site Recovery is ISO 27001:2013, 27018, HIPAA, and DPA certified. The service is undergoing SOC2 and FedRAMP JAB assessments.

Yes, both encryption in transit and encryption at rest in Azure are supported.

Azure Site Recovery creates replica and target disks. Replica disks are disks where the data is replicated and target disks are disks that are attached to failover (or test failover) virtual machines. Azure Site Recovery creates these disks with public access enabled. However, you can manually disable the public access for these disks by following these steps:

1. Go to the Replicated items section of your recovery services vault.

2. Select the virtual machine for which you want to change the disk network access policy.

3. Find the target subscription name and target resource group name in the Compute tab. The replica disks are in the target subscription and target resource group. The failover and test failover virtual machines are also created in the target resource group within target subscription.

   

4. Go to the Disks tab of the replicated items to identify the replica disk names and target disk names corresponding to each source disk. You can find the replica disks in the target resource group obtained from the previous step. Similarly, when you complete the failover, you get target disks attached to recovery virtual machine in the target resource group.

   

5. For each replica disk, do the following:

   1. Go to the Disk Export tab under the Settings of the disk. The disk should have SAS Access taken by Azure Site Recovery by default.

   2. Cancel the export using the Cancel export option before making any network access changes.

      

      Azure Site Recovery needs SAS on replica disks for replication. Canceling the export may briefly impact Azure Site Recovery replication, but Site Recovery automatically gets the SAS back in a few minutes.

   3. Go to the Networking tab under the Settings options of the disk. By default, the disk is created with Enable public access from all networks setting enabled.

   4. Change the network access to either Disable public access and enable private access or Disable public and private access per your requirement, after cancel export is successful.

      If you want to change disk network access to Disable public access and enable private access, the disk access resource to be used should already be present in the target region within the target subscription.

      

   Note

   You can change the network access of the disk only if you have canceled the export. If you do not cancel the export, network access change for the disk is disabled.

After completing the failover or test failover, the recovery virtual machine created in the target location also have the disks with public access enabled. These disks won't have SAS taken by Azure Site Recovery. To change the network access for these disks, go to the Networking tab of the disk and change the disk network access as needed according to step 5.

During reprotection and failback as well, Azure Site Recovery creates disks with public access enabled. You can change the network access of those disks as well as discussed in the steps above based on your requirements.

• Review Azure-to-Azure support requirements.
• Set up Azure-to-Azure replication.
• If you have questions after reading this article, post them on the Microsoft Q&A question page for Azure Recovery Services.