Azure Site Recovery

Replication policy

Similar to Azure–to–Azure replication, you must create a replication policy and associate it with your replication configuration during the DR setup process. This involves setting the following options:

• Copy Frequency This defines how often delta sync occurs after the initial replication is completed. Options range from 30 seconds to 5 minutes.

• Recovery Point Retention This defines how far back in time ASR allows for recovery, as the service retains recovery points based on retention timelines that you define. The maximum supported recovery-point retention at this time is 24 hours.

• App-Consistent Recovery Points These are snapshots of the on-disk data along with all processes, data, and transactions running in memory. They are captured using the Volume Shadow Copy Service on Windows Servers. App-consistent snapshots take longer than crash-consistent snapshots and can add load to the server depending on the available resources and frequency defined. You should test to make sure these snapshots are not causing significant overhead or resize your VM workload to accommodate the additional load. The minimum frequency supported for this snapshot is 1 hour.

FIGURE 2-24 Hyper-V with VMM/Hyper-V cluster with VMM topology.

FIGURE 2-25 Hyper-V without VMM/Hyper-V cluster without VMM topology.

You can also define whether the replication should initialize immediately once the configuration is completed or schedule it to be initiated at a later time in the day.

Data security

Similar to the Azure–to–Azure DR scenario, ASR does not intercept, scan, or analyze data transferred between your on-premises and Azure target regions. This makes the entire process transparent to the service and eliminates the risk of the replicated data being used for malicious purposes. ASR only obtains metadata information to monitor replication health and coordinate failover activities. Data is encrypted in transit as well as encrypted while at rest when stored in the target region.

Failover and failback

In case of a disaster in the on-premises Hyper-V environment, you can failover the Azure VM to the target region using the ASR service. You will be asked to select the recovery point to use for the restoration. The target VM will then be created based on settings you’ve defined and the replicated data.

The target VM is created in an unprotected state. Once the on-premises datacenter is back online, you can set up failback replication for the VM from Azure to the on-premises Hyper-V host. At this time, you can choose to either perform a delta sync, during which ASR will check the source disk for consistency and determine the missing changes to replicate over, or, if that is not possible, to choose the full download option so the entire disk is replicated from Azure back on-premises. (In most cases when the Azure VM has been running for quite a few days, you will have to perform the full download option to set up failback.) Once replicated, you can perform a failback in the same manner as the failover whenever you have the appropriate amount of downtime available.

Test, planned, and unplanned failovers

Similar to Azure–to–Azure disaster recovery, ASR supports test and planned failover options even for Hyper-V VMs replicating to Azure. In addition, it supports unplanned failover in case the primary site has gone offline without giving you the ability to perform a graceful failover to Azure.

In a test failover, ASR creates a VM in a test network defined by you, with the replicated data for that Hyper-V VM. It is 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. The test VM does not commit write operations to the replication data. This enables you to make changes to the test VM—for example, application or database upgrades—without affecting the primary server or the replication in any way. You can perform test failovers to validate your VM and its workload failover as needed in Azure to perform application or database upgrade testing or for compliance auditory reasons. This can also help in scenarios in which you are running low on resources on-premises and need a temporary test environment to quickly validate application changes. When you are finished testing, you can simply clean up the test environment; the test VM and associated disks will be deleted from Azure, while the original replication on-premises continues unimpeded.

During a planned failover, ASR performs a final delta sync from on-premises Hyper-V to ensure all changes are replicated to Azure. Thereafter, a VM is built based on the target configuration and brought online in the defined Azure region. The VM allows changes to be committed to disk. Although the changes are not replicated to the primary region, replication from the primary site is stopped, and the primary VM is shut down before the failover is initiated. Use this option in scenarios when you are migrating from on-premises to Azure.

If your on-premises environment is already offline, you will have to perform an unplanned failover. In such a scenario, ASR is unable to replicate any final changes from the on-premises VM. It will allow you to choose from one of the already replicated recovery points, however.