Let us learn more on site recovery failback with the support of our Server management support services at Bobcares.

What does it mean by Site Recovery Failback?

When the primary site recovers and becomes stable, the system performs failback and transfers operations from the secondary site to the primary site.

It entails reversing the failover procedure and ensuring that the systems and data are once again synced and operating at the primary site.

Failback is an essential component of a complete disaster recovery plan for ensuring company continuity.

Stages of site recovery failback

Site Recovery contains four steps for failover and failback:

• Stage 1: Failover from on-premises:

  After configuring replication to Azure for on-premises computers, we fail those machines over to Azure when the on-premises site fails. Duplicated data produces Azure VMs after failover.

  .
• Stage 2: Reprotect Azure VMs:

  In Azure, we must reprotect the Azure VMs in order for them to begin replicating back to the on-premises site.

  To help maintain data consistency, the on-premises VM (if available) is off during reprotection.
• Stage 3: Azure failover:

  Once our on-premises site is operational again, we do another failover, this time to fail back Azure VMs to the on-premises site.

  We can fail back to the original spot from which we failed over, or we can fail to a different location.
• Stage 4: Reprotect on-premises machines:

  After failing back, allow on-premises machine replication to Azure once more. This is the final stage in site recovery failback.

VMware/physical reprotection/failback

To reprotect and failback VMware VMs and physical servers from Azure to on-premises, we must have a healthy appliance, this is necessary for site recovery failback.

How to select an Appliance?

• To re-protect to on-premises, we may choose any of the Azure Site Recovery replication appliances registered under a vault.

  We do not need a separate Process server in Azure for re-protection operations, nor do we need a scale-out Master Target server for Linux VMs.
• Unlike forward protection, the replication appliance does not require additional network connections/ports during failback.

  If the appliance is in good condition, we can use it for both forward and backward protection. It should have no effect on replication performance.
• When choosing an appliance, make sure it can access the destination datastore where the source computer is. The appliance should always have access to the source machine’s data store.

  Reprotection will succeed even if the machine and appliance are on different ESX servers, as long as they share the data store. Ensure to have this for site recovery failback.

Note that: It won’t support Storage After a re-protect operation, replication appliance vMotion.

And also note that when choosing an appliance, make sure it can access the destination datastore where the source computer is.

Re-protect job

• If this is a fresh re-protection operation, Azure Site Recovery will immediately create a new log storage account in the destination area. There is no need for a retention disk.

• In the case of Alternate Location Recovery and Original Location Recovery, the system will recover the original configurations of the source computers.

Note that:

Failure

This is the next major step in site recovery failback. We can try any unsuccessful re-protection job again. There is an option to select any healthy replication equipment during retry.

• Original location recovery:

  If the source on-premises computer exists, this fails back to Azure. In this case, only modifications replicate back to on-premises.
• Data store selection during OLR:

  The system will automatically choose the data storage in relation to the source machine.
• Alternate location recovery:

  If the on-premises system is unavailable, we may fail back to an alternate site using Azure. When we reprotect the Azure VM to on-premises, we generate the on-premises computer.

  Full data replication from Azure to on-premises occurs. Examine the criteria and constraints for location failback.
• Data store selection during ALR:

  We can select any vCenter-managed data store on which the appliance is set up and accessible. The appliance should have read and write rights to the data store (original/new).

  We can select the cache storage account that will be utilized for re-protection.
• Data store selection during ALR:

  Any vCenter-managed data store on which the appliance is setup and accessible (read and write rights) by the appliance can be selected (original/new).

  We can select the cache storage account that will be utilized for re-protection.
• Data store selection during ALR:

  After failover, the mobility agent on the Azure VM will be immediately registered with Site Recovery Services. If registration fails, a major health concern on the failed over VM will be alerted.

  Registration will be automatically initiated after the issue has been fixed. After addressing the issues, you can manually complete the registration.

[Need assistance with similar queries? We are here to help]

Conclusion

To sum up we have now seen more on site recovery failback with the support of our tech support team.