Skip to main content
Druva Documentation

Phoenix disaster recovery workflow

Phoenix Editions: File:/cross.pngBusiness         File:/tick.png Enterprise     File:/tick.pngElite
(Purchase Separately)

Disaster recovery stages

The following table lists the different stages of the disaster recovery process.

For definitions of different terms and concepts used in DRaaS see, Disaster recovery concepts

Stage Description

With Phoenix DRaaS, the Phoenix AWS proxy:

  • Reads the virtual machine backup data from the Phoenix Cloud
  • Replicates the virtual machine to an EBS volume
  • Creates an EBS snapshot of the EBS volume called a DR copy in your AWS account
  • Deletes the EBS volume

The Phoenix AWS proxy replicates the entire virtual machine the first time it creates a DR copy. Subsequently, it incrementally updates the DR copy based on the replication frequency specified in the DR plan. This DR copy replaces the copy that is present in your AWS account.  Phoenix AWS proxy maintains only the latest DR copy of a virtual machine. At the time of failover, the Phoenix AWS proxy:

  • Converts the available DR copy to an EBS volume
  • Injects drivers into this EBS volume that is required to boot up the EC2 instance
  • Starts the EC2 instance, in turn spinning up to production in minutes
Failback You can failback the EC2 instances (failed over) and recover the virtual machine with a single click in your virtualization infrastructure in a few hours after it has been recovered to your AWS account during failover.

The following diagram depicts the Phoenix DRaaS workflow:

DR Failback Workflow.png

Restore workflow

Let's discuss the DR restore workflow flow briefly and know what is happening during the process of copying data from Druva account to the customer account.


  1. The Phoenix Cloud tells the Phoenix AWS proxy to copy the virtual machine backup data from S3 bucket in Phoenix.
  2. The Phoenix AWS proxy then makes an API call to execute this command. 
  3. The data from S3 goes through the Phoenix AWS proxy to the EBS volume and the data path for this Phoenix AWS proxy is the Internet gateway.
    We introduce one more entity here, which is S3 endpoint. It ensures that the data coming from one account to another does not leave the AWS network.
  4. Once the data has been copied to the EBS volume, then through another API call, the Phoenix AWS proxy creates an EBS snapshot of the volume and deletes the volume itself.

Failover workflow

To ask what a failover is, is to ask what happens when disaster strikes and the primary data center becomes unavailable. Here’s what happens.


  1. First, an administrator triggers the failover from the Phoenix Management Console and Phoenix Cloud instructs the Phoenix AWS proxy to initiate the failover.
  2. The EBS snapshot is used to create an EBS volume. The Phoenix AWS proxy creates an EC2 instance in your AWS account. You can choose the EC2 instance type from the Phoenix Management Console when you configure the VM for DR. The EBS volume gets attached to the EC2 instance.
  3. Once the process has completed, EC2 instance is restarted and is ready to support its workload. The same process is repeated for all protected VMs. 
  4. The last step is to update the DNS servers to redirect the traffic to the IP addresses of the new EC2 servers.

Phoenix provides advanced orchestration capabilities allowing to decide on the failover sequence, creating dependencies between EC2s and adding scripts for execution during EC2 boot. An example of dependency would be an e-commerce Web server storing data in the database. It wouldn’t make sense to start Web EC2 before the database is available.

Druva DRaaS also allows for DR testing in a different VPC or subnet. 

Failback workflow

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


  1. The first step is to redeploy the Phoenix backup proxy VM to establish communication with the Phoenix 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.

Related articles