Cloud Disaster Recovery with Druva

Organizations are confronted with more security threats and data loss risks than ever before—and even with the best technology and processes in place, it’s only a matter of time before disaster strikes. That’s why it’s absolutely essential that you have a comprehensive cloud-native backup and disaster recovery (DR) solution in place. This should not be viewed as a “nice to have” insurance policy, but instead, it should be treated as a strategic business continuity initiative.

Why Cloud-Native Backup and Disaster Recovery?

A cloud-native back up and DR solution utilizes technologies such as the global deduplication of virtual data, ensuring that only one copy of each file is maintained. This allows you to have bandwidth savings of up to 80 percent and ensures that even remote office locations, potentially with suboptimal WAN speeds, are still effectively protected.

Leveraging the efficiencies of public cloud vendors like Amazon Web Services (AWS) allows you to take advantage of tiered storage—with data sorted into hot, warm, and cold storage depending on retention and recovery needs.

The result? Long-term storage at an affordable price.

What Is DRaaS?

Druva provides true Disaster Recovery as a Service (DRaaS) by using the power of a cloud-native architecture and the reliability of AWS to deliver best-in-class security and availability of your virtualized data. Your IT team can confidently protect virtual machine (VM) workloads in the event of a DR scenario, while maintaining uptime, without the expense and complexity of additional data center hardware and personnel. Virtual images are replicated easily across regions for true workload mobility, whether to meet regulatory requirements or for your test/dev needs. Plus, global deduplication and auto-tiering of your storage give you significant bandwidth reduction and unparalleled TCO savings.

How Druva DRaaS Works

With Phoenix DRaaS, Amazon Machine Image (AMI) copies are created based on the VM backup and maintained in the AWS cloud. When a disaster strikes, you can launch an EC2 instance from these AMIs, which will spin up to production in minutes. The AMI copies are then updated with the latest VM backup based on the defined schedule.

Phoenix DRaaS leverages VM backup data to create and maintain an AMI copy in your AWS account. The AMI can be used to boot an EC2 instance, which represents the DR copy in AWS for the VM backed up from your on-premises data center.

• At each defined schedule, a “DR restore” job is created.
• This job performs data-copy and AMI creation operations.
• In addition, the first time a DR restore job runs for a VM, the data corresponding to an entire VM backup image is copied to an S3 bucket in your AWS account.
• Subsequent DR restore jobs only copy incremental data since the previous DR restore.
• At the end of each DR restore job, a new AMI is created based on the latest VM backup image, and the previously created AMI is deleted.

What Data Flow Looks Like During Your First DR Job for a VM

1. VM data for the latest backup image from Phoenix backup storage is copied in chunks to a specified folder in an S3 bucket in your Druva account. This is accomplished with help of a Druva worker machine, which is an EC2 instance running in the Druva cloud on AWS. The data in the S3 bucket is in an encrypted format with a customer-specific eKey.
2. Phoenix AWS Proxy in your account downloads the data blocks from the Druva S3 bucket—with the transfer taking place over a TLS 1.2 tunnel—and copies that data to the S3 bucket in your AWS account in a decrypted format of 256 MB chunks.
3. Phoenix AWS Proxy creates an AMI from the data in the S3 bucket in your account.
4. Data in the S3 bucket in the Druva account is deleted.

How to Set Up DRaaS for Phoenix

Deploy Phoenix AWS Proxy—Phoenix AWS Proxy is an EC2 instance running a Phoenix service. It’s primarily responsible for orchestrating the copying of data from Phoenix backup storage to your AWS account and creating AMIs from the backed-up data based on a defined schedule. The Phoenix AWS Proxy runs in your AWS account. Note that the Proxy should be launched in the same AWS region where the backup storage for the VM is located. The AMI to be instantiated for DR will be created in this same region.

Create a DR policy—A DR policy specifies your AWS account for DR, along with the schedule for AMI creation. The schedule determines the recovery point objective (RPO) for the DR. The schedule options are: immediately after backup, daily at a specified time, or weekly at a specified day and time.

Assign the DR policy to the server group of VMs—Details for the above steps are available at Phoenix documentation.

Simplified Disaster Recovery

Managing the backup and restore of VMs in a distributed environment is a convoluted process that involves multiple members of your team supporting a complex architecture. Reducing the need for new hardware and software will improve your agility and lower your TCO.

“My favorite thing about Druva is the simplicity. I love the console—easy to get what you need.” —Adam Kailian, IT systems administrator, Build Group

With Phoenix, Druva can help. Phoenix is a single, unified data source, so your team isn’t burdened with mastering and administering multiple incompatible systems. Everything that your team needs to know is contained within an easy-to-manage dashboard, helping them get ahead—and stay ahead—of potential disaster recovery issues.

Get all the details by accessing this white paper: Druva Phoenix Disaster Recovery as a Service