Disaster Recovery


Disaster recovery (cloud DR) is a backup and restore strategy that involves storing and maintaining copies of electronic records in a cloud computing environment as a security measure. The goal of cloud DR is to provide an organization with a way to recover data and/or implement failover in the event of a man-made or natural catastrophe.

How it works?

Disaster recovery is leveraged by HyperCX in a way that user can continue working on their crucial data without even worrying about any failure that could disrupt their services.HyperCX at every scheduled day and time of the week backs up images of the VMs to remote clusters. If a disaster occurs VMs at the remote clusters are automatically deployed.

Setup Backup for Disaster Recovery

Following are key components and definitions to understand how to implement Disaster recovery using HyperCX

Remote Cluster: This will serve as the backup cluster this cluster is on a remote location to prevent data loss.

Present Cluster: In this document present cluster refers to the primary cluster allocated to the client.

Tags: VMs that are enabled to backup for disaster recovery are tagged with “DR”(This tag may or may not be the same please contact support to verify it)

Template: On the remote cluster a VM template needs to be created in order for the cluster to be ready to be backed up.

Getting Started

The VM that needs to be backed up should be set up first in order to achieve automated backups to the remote server, follow the below mentioned steps to successfully configure it.

  1. Navigate to the VM that needs to be backed up and select it.

  2. Now add a label “DR” to the VM.

Creating backup template

  1. Now head over to the Remote Cluster’s portal and Login to that cluster

  2. On the remote cluster, a template must be created for each VM that will leverage DR.

  3. So create a new template by heading over to Templates-> VMs and click on (ADD button) and now click on create.

  4. Set a unique name for this template(It will be used later on).

  5. Navigate to Scheduling tab and under Placement Tab select “Select Clusters” now depending upon your Primary Cluster’s VM select either KVM or LXD cluster.

  6. The configurations of this template should be the exact same as of your Present Cluster’s VM.Following configurations are mandatory rest is upto the user.

    1. VM Capacity(CPU,Memory,VCPU etc)

    2. Network

    3. Storage should not be added as it will be automatically backed up by HyperCX from Present Cluster to Remote Cluster.

Some final configurations..

  1. Now head back to Present Cluster’s HyperCX portal and power off the VM that needs to be backed up.

  2. Navigate to the Conf tab of the VMs and click on Update configurations.

  1. Now navigate to Context tab and select Custom Vars and click on the add button(At the end of all context variable definitions)

  2. Here we’re going to add a context variable with key “DR_REMOTE_TEMPLATE” and value will be the name of template(Step 6) we defined earlier at the remote cluster. If you’re already familiar with the key value pair configuration that HyperCX uses you can skip the following.

  3. On the first input box (1*) enter “DR_REMOTE_TEMPLATE”

  4. On the second input box(2*) enter the name of the template at the Remote Cluster


HyperCX leverages delta transfers for backup(Only changes are backed up) this reduces bandwidth overhead, providing reliable backups.


Q: Remote cluster’s VM does not have the same network as of Primary Cluster

A: This outcome is expected as every network is unique to their geographical location(except for client network) so all a user needs to do is access the VM using the IP address that is allocated on the remote cluster.