> Expert > Backup and Restore Agents > Virtualization > Virtual Server Agent > Microsoft Azure > Replication for Microsoft Azure

Failover and Failback Orchestration for Microsoft Azure

Updated

You can execute a planned or unplanned failover to a disaster recovery (DR) site, or a failback to revert to a primary site.

Failover and failback operations are only supported for regular streaming backups or auxiliary copies.

Planned Failover

Performs a planned failover so that you can test the failover process or perform maintenance on your primary site.

A planned failover triggers the following actions:

  1. Power off the source and destination VMs.

  2. Perform an incremental backup of the source VMs to capture the latest data.

  3. Run replication to apply the most recent updates for destination instances in the disaster recovery site.

  4. Disable replication.

  5. Power on the destination VMs.

Unplanned Failover

In the event that the primary site is unavailable, this option switches over to the DR site immediately.

An unplanned failover triggers the following actions:

  1. Power off the source VMs if they are accessible.

  2. Disable replication.

  3. Start destination instances at the disaster recovery site.

  4. Snapshots of DR blobs are retained so that they can be used for backups of destination VMs.

Note

For an unplanned failover, some changes on the source VM might not be synced to the destination instance. For this reason, it is best to use the Failback option only after a planned failover.

Failback

After a failover, you can perform a failback operation to move instances back to the original primary site or a new primary site.

If the original VM still exists on the primary site, you can use replication to update the original VM with any data that changed on the DR site.

If the original VM needs to be recreated, you can restore the full instance from the DR site.

A failback triggers the following actions:

  1. Power off the destination VMs.

  2. Perform an incremental backup of the destination VMs.

    Integrity snapshots from the last replication operations or snapshots created by last backup jobs are used to identify changed blocks.

  3. Restore VMs from destination VM backups to the primary site.

  4. Power on the source VMs at the primary site.

  5. Enable replication from the primary site to the DR site.

Note

If you fail back to a different site than the original VM, or if the source VM no longer exists at the primary site, make sure the new primary VM is included in a subclient for backups. Also, either edit the existing replication schedule to remove and add the new primary VM, or create a new replication schedule to include the VM. The next replication operation will fully replicate the source virtual machine.

Was this page helpful?