Skip to main content


 

 

How can we help you?

 

Druva Documentation

About disaster recovery failback

Heads up!

We've transitioned to a new documentation portal to serve you better. Access the latest content by clicking here.

Enterprise Workloads Editions
❌ Business| ✅ Enterprise (Purchase Separately) | ✅ Elite

 

Overview

To address a disaster, Disaster Recovery spins up the AWS EC2 instances from the EBS snapshots during failover. The virtual machines in the AWS account are recovered based on the configuration and failover settings specified in the DR plan. Once Disaster Recovery addresses the disaster, you can failback the EC2 instances with a single click to an alternate location in your virtualization infrastructure without any data loss. 

When you trigger failback, the backup proxy creates a target virtual machine in the virtualization infrastructure. The virtual machine then connects to the failed over EC2 instance and the data is copied to the virtual machine. Druva then boots up the virtual machine and launches the target instance. You must configure the virtual machine with the previous backup policy to resume the operations. 

Note: You can failback the entire DR plan or multiple VM instances in the DR plan by selecting all the required instances in the DR plan at one time for failback. 

The starting point for failback is a freshly rebuilt primary data center and backup DR site containing data that needs to be transferred back to the primary site.

Failback_updated.png

  1. The first step is to redeploy the Druva backup proxy VM to establish communication with the Druva Cloud and get the backup configuration from the cloud. 
  2. In the next step, the backup proxy launches a template VM, which reaches out to the EC2 instance and get its configuration information – number of CPUs, memory size, number of disks, and so on. 
  3. Based on this information received, it attaches one or more VMDK disks and starts copying data from the EBS volumes to the VMDK disks. 
  4. Once the download is completed, the template VM is rebooted with the configuration parameters read from the EC2 instance. After that, the server is operational. The same process is repeated for all protected VMs. 
  5. The last step is to update the DNS to redirect the traffic back to the primary site.

Failback considerations

Before triggering the failback operation, ensure the following:

  • You must deploy the Druva AWS proxy with version 4.8.6 or later, and the backup proxy with version 4.8.6 or later.
  • You have successfully failed over the EC2 instance and the instance is in the running state.
  • You must stop all application services running on the EC2 instance that you want to failback so that no updates to the application are lost during the failback process.
  • Was this article helpful?