General questions about Azure Site Recovery

Site Recovery contributes to your business continuity and disaster recovery (BCDR) strategy, by orchestrating and automating replication of Azure VMs between regions, on-premises virtual machines and physical servers to Azure, and on-premises machines to a secondary datacenter. Learn more.

No, Azure Site Recovery doesn't support Docker workloads running on virtual machines. To protect these virtual machines with Site Recovery, exclude the disks that have Docker installed on them.

There are various measures taken by Site Recovery to ensure data integrity. A secure connection is established between all services by using the HTTPS protocol. This makes sure that any malware or outside entities can't tamper the data. Another measure taken is using checksums. The data transfer between source and target is executed by computing checksums of data between them. This ensures that the transferred data is consistent.

Azure doesn't support persistent MAC addresses and so software with MAC based license models cannot be used for both on-premises to Azure migration or disaster recovery.

No, Azure Site Recovery currently doesn't support Ephemeral Disks.

Azure Recovery Services agent is used for configuring/registering with Site Recovery services, and for monitoring the health of all the components. This component is one of the basic building blocks of the entire Azure Site Recovery on-premises infrastructure. It helps to replicate your workloads to another Azure region from an on-premises site, and fail over to Azure in a disaster.

Yes, Site Recovery supports both dedicated and shared infrastructure models.

No. Tenant identity remains anonymous. Your tenants don't need access to the Site Recovery portal. Only the service provider administrator interacts with the portal.

When you're replicating to Azure, application data is sent to Azure storage but not to the Site Recovery service. Data is encrypted in-transit (HTTPS), and remains encrypted in Azure.

No. Azure's billing relationship is directly with the service provider. Service providers are responsible for generating specific bills for their tenants.

No, Data is replicated to Azure storage in your subscription. When you perform a test failover (disaster recovery drill) or an actual failover, Site Recovery automatically creates virtual machines in your subscription.

Yes.

We support Azure Pack, Cloud Platform System, and System Center based (2012 and higher) deployments. Learn more about Azure Pack and Site Recovery integration.

No, you can replicate Hyper-V virtual machines only to Azure.

Review Site Recovery pricing details.

You can use the pricing calculator to estimate costs while using Site Recovery.

Yes, there are extra charges for cache storage account usage when replicating virtual machines using Site Recovery. The cache storage account costs remain the same when the replica storage is of type managed disks or unmanaged disks.

Yes. Every protected instance incurs no Azure Site Recovery charges for the first 31 days. For example, if you have been protecting 10 instances for the last six months and you connect an 11th instance to Azure Site Recovery, there are no charges for the 11th instance for the first 31 days. The first 10 instances continue to incur Azure Site Recovery charges since they've been protected for more than 31 days.

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

There isn't any separate cost for disaster recovery drill. There is compute charges after the virtual machine is created after the test failover.

No, Site Recovery doesn't intercept replicated data, and doesn't have any information about what's running on your virtual machines or physical servers. Replication data is exchanged between on-premises Hyper-V hosts, VMware hypervisors, or physical servers and Azure storage or your secondary site. Site Recovery has no ability to intercept that data. Only the metadata needed to orchestrate replication and failover is sent to the Site Recovery service.

Site Recovery is ISO 27001:2013, 27018, HIPAA, DPA certified, and is in the process of SOC2 and FedRAMP JAB assessments.

Yes. When you create a Site Recovery vault in a region, we ensure that all metadata that we need to enable and orchestrate replication and failover remains within that region's geographic boundary.

For virtual machines and physical servers replicating to Azure, both encryption-in-transit and encryption-at-rest (in Azure) are supported.

Yes, TLS 1.2 protocol is enforced by default for Azure-to-Azure Site Recovery scenario.

Mobility agents installed on the replicated items communicate to Process Server only on TLS 1.2. However, communication from Configuration Server to Azure and from Process Server to Azure could be on TLS 1.1 or 1.0. Follow the guidance to enforce TLS 1.2 on all Configuration Servers and Process Servers set up by you.

All communication between the microservices of Azure Site Recovery happens on TLS 1.2 protocol. Site Recovery uses security providers configured in the system (OS) and uses the latest available TLS protocol. One needs to explicitly enable the TLS 1.2 in the Registry and then Site Recovery will start using TLS 1.2 for communication with services.

You can switch on the managed identity of the recovery services vault by going to the Identity setting. Once the vault gets registered with Microsoft Entra ID, you can go to your storage accounts and give the following role-assignments to the vault:

• Resource Manager based storage accounts (Standard Type):
  • Contributor
  • Storage Blob Data Contributor
• Resource Manager based storage accounts (Premium Type):
  • Contributor
  • Storage Blob Data Owner
• Classic storage accounts:
  • Classic Storage Account Contributor
  • Classic Storage Account Key Operator Service Role

Azure Site Recovery doesn't track source virtual machine changes outside the Source OS. For example, If you are using Azure to Azure replication and change the size of the source virtual machine, the change in size of source virtual machine isn't replicated to the target virtual machine.

• Azure virtual machines: Site Recovery can replicate any workload running on a supported Azure virtual machine.
• Hyper-V virtual machines: Site Recovery can protect any workload running on a Hyper-V virtual machine.
• Physical servers: Site Recovery can protect physical servers running Windows or Linux.
• VMware virtual machines: Site Recovery can protect any workload running in a VMware virtual machine.

You can use Site Recovery to protect most workloads running on a supported virtual machine or physical server. Site Recovery provides support for application-aware replication, so that apps can be recovered to an intelligent state. It integrates with Microsoft applications such as SharePoint, Exchange, Dynamics, SQL Server and Active Directory, and works closely with leading vendors, including Oracle, SAP, IBM, and Red Hat. Learn more about workload protection.

Yes. When you use Site Recovery to orchestrate replication and failover in your branch offices, you'll get a unified orchestration and view of all your branch office workloads in a central location. You can easily run failovers and administer disaster recovery of all branches from your head office, without visiting the branches.

Yes, Site Recovery supports disaster for Azure virtual machines between Azure regions. Review common questions about Azure virtual machine disaster recovery. If you want to replicate between two Azure regions on the same continent, use our Azure to Azure disaster recovery offering. No need to set up configuration server/process server and ExpressRoute connections.

Yes, Site Recovery supports disaster recovery of on-premises VMware virtual machines. Review common questions for disaster recovery of VMware virtual machines.

Yes, Site Recovery supports disaster recovery of on-premises Hyper-V virtual machines. Review common questions for disaster recovery of Hyper-V virtual machines.

Yes, Site Recovery supports disaster recovery of on-premises physical servers running Windows and Linux to Azure. Learn about requirements for disaster recovery to Azure. The physical servers run as virtual machines in Azure after failover. Failback from Azure to an on-premises physical server isn't currently supported. You can only fail back to a VMware virtual machine.

No, Azure Site Recovery doesn't support move of Recovery Services vault that has protected virtual machines hosted in it.

Azure Site Recovery replicates data to an Azure storage account or managed disks, over a public endpoint. However, replication can be performed over Site-to-Site VPN as well. Site-to-Site VPN connectivity allows organizations to connect existing networks to Azure, or Azure networks to each other. Site-to-Site VPN occurs over IPSec tunneling over the internet, using existing on-premises edge network equipment and network appliances in Azure, either native features like Azure Virtual Private Network (VPN) Gateway or third party options such as Check Point CloudGaurd, Palo Alto NextGen Firewall.

• Private connectivity over the public Internet to Microsoft Edge
• Recovery Service Vaults configured for security with Private Endpoints
• Replication over customer private Virtual Network connection
• Easy transition to "Future State"
• No SLA and potentially higher latency
• Requires an on-premises VPN device availability

Our partner, Riverbed, provides detailed guidance on working with Azure Site Recovery. Review their solution guide.

Yes, ExpressRoute can be used to replicate on-premises virtual machines to Azure.

• Azure Site Recovery replicates data to an Azure Storage over a public endpoint. You need to set up Azure peering or use an existing public peering (deprecated for new circuits) to use ExpressRoute for Site Recovery replication.
• Azure peering is the recommended routing domain for replication.
• Replication is supported over private peering only when private endpoints are enabled for the vault.
• If you're protecting VMware machines or physical machines, ensure that the Networking Requirements for Configuration Server are also met. Connectivity to specific URLs is required by Configuration Server for orchestration of Site Recovery replication. ExpressRoute cannot be used for this connectivity.
• After the virtual machines have been failed over to an Azure virtual network, you can access them using the private peering setup with the Azure virtual network.

Using storage accounts as target storage isn't supported by Azure Site Recovery. It is recommended to rather use managed disks as the target storage for your machines. Managed disks only support LRS type for data resiliency.

• Hyper-V: Hyper-V virtual machines can be replicated every 30 seconds (except for premium storage) or five minutes.
• Azure virtual machines, VMware virtual machines, physical servers: A replication frequency isn't relevant here. Replication is continuous.

Extended or chained replication isn't supported. Request this feature in feedback forum.

This isn't supported. Request this feature in the feedback forum.

This is supported when you're replicating VMware virtual machines and Hyper-V virtual machines to Azure, using the Azure portal.

Dynamic disks are supported when replicating Hyper-V virtual machines, and when replicating VMware virtual machines and physical machines to Azure. The operating system disk must be a basic disk.

Yes. You can read more about throttling bandwidth in these articles:

• Capacity planning for replicating VMware virtual machines and physical servers
• Capacity planning for replicating Hyper-V virtual machines to Azure

Yes. Azure Site Recovery for Linux Operation System supports application custom scripts for app-consistency. The custom script with pre and post-options is used by the Azure Site Recovery Mobility Agent during app-consistency. Following are the steps to enable it.

1. Sign in as root into the machine.

2. Change directory to Azure Site Recovery Mobility Agent install location. Default is "/usr/local/ASR"
   # cd /usr/local/ASR

3. Change directory to "VX/scripts" under install location
   # cd VX/scripts

4. Create a bash shell script named "customscript.sh" with execute permissions for root user.
   a. The script should support "--pre" and "--post" (Note the double dashes) command-line options
   b. When the script is called with pre-option, it should freeze the application input/output and when called with post-option, it should thaw the application input/output.
   c. A sample template -
   

   # cat customscript.sh
   

    #!/bin/bash

    if [ $# -ne 1 ]; then
        echo "Usage: $0 [--pre | --post]"
        exit 1
    elif [ "$1" == "--pre" ]; then
        echo "Freezing app IO"
        exit 0
    elif [ "$1" == "--post" ]; then
        echo "Thawed app IO"
        exit 0
    fi

5. Add the freeze and unfreeze input/output commands in pre and post-steps for the applications requiring app-consistency. You can choose to add another script specifying those and invoke it from "customscript.sh" with pre and post-options.

A replication policy defines the settings for the retention history of recovery points. The policy also defines the frequency of app-consistent snapshots. By default, Azure Site Recovery creates a new replication policy with default settings of:

• One day for the retention history of recovery points.
• No app-consistent snapshots.

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

Today, most applications can recover well from crash-consistent snapshots. A crash-consistent recovery point is enough for no-database operating systems and applications like file servers, DHCP servers, and print servers.

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

Application-consistent recovery points are created from application-consistent snapshots. Application-consistent recovery points capture the same data as crash-consistent snapshots while also capturing data in memory and all transactions in process.

Because of their extra content, application-consistent snapshots are the most involved and take the longest. We recommend application-consistent recovery points for database operating systems and applications such as SQL Server.

Application-consistent recovery points capture all the data in memory and in process. Because recovery points capture that data, they require framework like Volume Shadow Copy Service on Windows to quiesce the application. If the capturing process is frequent, it can affect performance when the workload is already busy. We don't recommend that you use low frequency for app-consistent recovery points for non-database workloads. Even for database workload, 1 hour is enough.

Site Recovery can create an application-consistent recovery point with a minimum frequency of 1 hour.

To understand how Site Recovery generates recovery points, let's see an example of a replication policy. This replication policy has a recovery point with a 1-day retention window and an app-consistent frequency snapshot of 1 hour.

Site Recovery creates a crash-consistent recovery point every 5 minutes. You can't change this frequency. For the most recent 2 hours, you can choose from 24 crash-consistent points and 2 app-consistent points. As time progresses, Site Recovery prunes all the recovery points beyond the last 2 hours and saves only one recovery point per hour for up to 24 hours of the day.

The following screenshot illustrates the example. In the screenshot:

• Within the past 2 hours, there are recovery points with a frequency of 5 minutes.

• Beyond the past 2 hours, Site Recovery keeps only one recovery point per hour.

  

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

No, Site Recovery keeps all your previous recovery points. Depending on the recovery points' retention window, Site Recovery replaces the oldest point only if it generates new points. Because of the problem, Site Recovery can't generate any new recovery points. Until there are new recovery points, all the old points remain after you reach the window of retention.

Go to Site Recovery Vault > Site Recovery Infrastructure > Replication policies. Select the policy that you want to edit, and save the changes. Any change applies to all the existing replications too.

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

Yes, if you increase the retention period from one day to three days, Site Recovery saves the recovery points for an extra two days. The added time will incur storage charges since there will be 12 additional recovery points that need to be saved with increase in retention period from one day to three days. For example, a single recovery point might have delta changes of 10 GB with a per-GB cost of $0.16 per month. Additional charges would be $1.60 × 12 per month.

You can access the Azure virtual machines over a secure Internet connection, over a site-to-site VPN, or over Azure ExpressRoute. You need to prepare a number of things in order to connect. Learn more.

Azure is designed for resilience. Site Recovery is already engineered for failover to a secondary Azure datacenter, in accordance with the Azure SLA. If this happens, we make sure your metadata and vaults remain within the same geographic region that you chose for your vault.

You can trigger an unplanned failover from the secondary site. Site Recovery doesn't need connectivity from the primary site to perform the failover.

Failover isn't automatic. You initiate failovers with single click in the portal, or you can use Site Recovery PowerShell to trigger a failover. Failing back is a simple action in the Site Recovery portal.

To automate you could use on-premises Orchestrator or Operations Manager to detect a virtual machine failure, and then trigger the failover using the SDK.

• Read more about recovery plans.
• Read more about failover.
• Read more about failing back VMware virtual machines and physical servers

Yes, you can use the alternate location recovery to failback to a different host from Azure.

• For VMware virtual machines
• For Hyper-V virtual machines

Once a machine from source location has been failed over to the target location then there are three options available for you to choose from. All three serve different purposes -

1. Complete Migration means that you won't go back to the source location anymore. You migrated over to the target region and now you're done. Clicking on Complete Migration triggers Commit and then Disable Replication, internally.
2. Commit means that this isn't the end of your replication process. The replication item along with all the configuration will remain, and you can hit Re-protect at a later point in time to enable the replication of your machines back to the source region.
3. Disable Replication will disable the replication and remove all the related configuration. It won’t affect the already existing machine in the target region.

Yes. You can automate Site Recovery workflows using the REST API, PowerShell, or the Azure SDK. Currently supported scenarios for deploying Site Recovery using PowerShell:

• Replicate Hyper-V virtual machines in VMMs clouds to Azure PowerShell Resource Manager
• Replicate Hyper-V virtual machines without VMM to Azure PowerShell Resource Manager
• Replicate VMware to Azure with PowerShell Resource Manager

No, the retirement of the AzureRM module doesn't affect how Site Recovery automatic updates work. No changes are needed for the internal runbook, and the REST API used in place, continues to function as intended with the automation account.

Learn about new updates, and get rollup information.

Next steps

• Read the Site Recovery overview