Druva needs the following for the disaster recovery service:

Druva offers cloud-based, enterprise-scale backup and disaster recovery solutions for business continuity.

In the event of disaster recovery, you can recover data to a failover site in a few minutes, offering tighter RTOs by using ready-to-go images of the production servers as compared to backup solutions where the RTOs are comparatively higher when restoring data back to the production environment.

For the list of regions supported by Druva for disaster recovery, see the Downloads page.

It depends on the factors such as the virtual machine, guest operating system, and the Kernel version of the guest operating system, the presence of applications installed on the virtual machine. On average, it takes 10-30 minutes to recover a virtual machine as an EC2 instance. It can take up to 60 minutes to recover a virtual machine in some cases, such as if you are using:

The expected RPO largely depends on the time it takes to complete a backup job and then a DR restore/update DR copy job. In case you have scheduled to run a DR copy update immediately after the backup job, the RPO for DR would be the sum of the backup time and the time to complete the DR job. In general, Disaster Recovery is best suited for VMs with a few hours plus RPO.

Elite edition customers get Disaster Recovery pre-packaged. Whereas, Enterprise edition customers need to purchase this feature for an additional cost. This feature is not available for Business edition customers.

You would incur a cost for running the Druva AWS proxy, the cost of creating a DR copy that is used to launch an EC2 instance for failover. For more information, see AWS component costs. If you perform failover, you will incur an additional cost for the launched EC2 instance.

No. Druva does not overwrite a DR copy. Druva creates a new DR copy with every update DR copy job, and deletes the previous DR copy after the creation of the new DR copy.

Yes. If an instance is launched from a DR copy for disaster recovery, we do not delete it. However, you cannot start an EC2 instance from your AWS account using the DR copy. To start an EC2 instance, you have to run a failover job from the Management Console.

The Disaster Recovery solution is built on top of Druva's "already established" secure backup solution (the backup data stored in Cloud is encrypted using digital envelope encryption). This data is securely transferred in its encrypted form to the customer’s AWS account. In the customer’s account, the data is decrypted to create a DR copy.

When the DR job runs for the first time, the entire raw data corresponding to the latest backup stored in Druva storage is transferred to the customer’s AWS account. For subsequent DR jobs, only incremental data since the last DR job, is transferred to the AWS account.

We strongly discourage the use of CloudCache with Cloud Disaster Recovery as CloudCache can impact the RPO.

Druva provides the following capabilities:

After you buy a license, you must deploy a Druva AWS proxy. For more information, see Set up Druva AWS proxy.

For more information about the supported VMware vCenter Server and ESXi, see the Support matrix.

Druva currently supports only the VMware environment for disaster recovery. For more information about the supported operating systems, see Support matrix.

No. Disaster Recovery currently does not support physical machines.

To protect your virtual machines in the event of a disaster, you can create a DR plan and add the virtual machines to the DR plan. For more information, see Configure virtual machines for disaster recovery.

Yes. You can register the same AWS account to multiple Druva organizations. However, you have to set up the Druva AWS proxy for each organization. For more information, see Deploy Druva AWS proxy.

No. By default, Druva replicates data and creates a DR copy in the same region where you back up the virtual machines. Disaster Recovery requires you to deploy at least one Druva AWS proxy in the AWS account in the same region (the region where you are backing data) before you can configure the virtual machine for disaster recovery for that account.

No. As a part of the failover settings, you can select only those VPCs in the AWS account that belong to the same region as the backup storage.

No. You can configure virtual machines to replicate data and perform failover to only one AWS account.

When you launch the Druva AWS proxy, on the AWS Console you can either create a new virtual private cloud or use an existing one. You can choose an existing virtual private cloud and an existing subnet to ensure all virtual machines from your organizations are replicated in the same subnet.

No. Druva does not allow you to add the same virtual machine to multiple DR plans.

Disaster Recovery creates DR copies for virtual machines and maintains them in the AWS account. At the time of the disaster, you can launch EC2 instance from the latest DR copy, in-turn spinning up to production in minutes.

Yes, you can update the existing DruvaIAMPolicy in your AWS account. To update the policy, perform the following steps:

Druva uses the GP3 type.

The Recent Failovers section on the Overview page of the selected DR Plan provides the status of the failover requests for virtual machines. Click the Job ID to view the EC2 instance ID corresponding to the virtual machine. For more information about viewing failover history, see View disaster recovery jobs.

You can also see the instances that failed over successfully on the Failover Instances page of the selected DR plan.

Yes, the failover operation is resumable, however, you cannot resume the restore operation. With orchestration, Druva provides an option to continue the failover of the other virtual machines, if one or some fails. The information to resume a failover is maintained in the s3 bucket and based on the data the virtual machine failover is either skipped if is done already or is performed for the virtual machine.

Yes, the DR restore resumes on a network disconnect, but the job fails if the agent restarts.

The customer AWS account stores logs specific to the DR restores and the metadata information for failover in the S3 bucket.

The failover of all virtual machines in a boot step starts in parallel. Druva provides an ability to configure failover settings to abort or continue the failover at the step level upon failure of a virtual machine.

No. By default, the latest DR copy available (based on the last successful update DR copy job) will be used to launch an EC2 instance for failover. You cannot choose any particular recovery point for failover.

Druva creates a temporary security group for each failover so that the failover instance and the AWS proxy can communicate.

After the successful conversion, Druva deletes the temporary security group and attaches the security group that is selected in the failover settings.

📝 Note
​ The temporary security group is not deleted when DEBUG_TW = True is added in the AWS proxy configuration.