Disaster Recovery

This entire guide assumes that there are two clusters, source cluster will be used to denote MAIN CLUSTER(Cluster on which current operations reside) while remote cluster denotes DISTANT CLUSTER(Cluster on which, in case of failures on MAIN CLUSTER, operations will continue)

Overview

Disaster recovery (cloud DR) is a backup and restore strategy that involves storing and maintaining copies of electronic records in a different 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 must be manually deployed.

Setup Backup for Disaster Recovery# Disaster Recovery

This entire guide assumes that there are two clusters, source cluster will be used to denote MAIN CLUSTER(Cluster on which current operations reside) while remote cluster denotes DISTANT CLUSTER(Cluster on which, in case of failures on MAIN CLUSTER, operations will continue)

Overview

Disaster recovery (cloud DR) is a backup and restore strategy that involves storing and maintaining copies of electronic records in a different 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 must be manually 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. Only HyperCX private clusters are supported at this moment.

Main Cluster: In this document Main cluster refers to the primary cluster allocated to the client. Only HyperCX private clusters are supported at this moment.

Tags: VMs that are enabled to backup for disaster recovery are tagged with DR(This tag name may be adjusted).

Remote VM: On the remote cluster a VM 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.

  • Navigate to the VM one the Main Cluster that needs to be backed up and select it.

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

Creating backup VM

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

  • On the remote cluster, a VM must be created for each VM on Main Cluster that will leverage DR. This step is required because the remote VM does not need to be identical to the original one. For example, the remote VM will most likely be attached to different virtual networks available only in the remote cluster. This VM can be instantiated from any available template in the cluster, and then modified to match the user's needs.

  • After the Remote VM was instantiated in the Remote Cluster, a few final configurations and checks are required:

    1. Shut down the VM if it is running. For DR to work and guarantee consistency, Remote VM must be in PowerOff state.

    2. Adjust VM Capacity(CPU,Memory,VCPU etc)

    3. Configure the NIC cards these VMs will use. VNets on Remote Cluster may be different as in Main Cluster.

    4. Remove all virtual disks from the VM. These virtual disks will be automatically created by HyperCX DR on the first run.

  • On the bottom of the remote VM's info panel, add an attribute named "DR_SOURCE_VM" and set it's value to the Main Cluster's VM ID(i.e. the VM to be backed up)

Some final configuration..

  • Head back to Main Cluster and on the bottom of the local VM's info panel, add an attribute named "DR_REMOTE_VM" and set it's value to the Remote Cluster's VM ID.

In case of Disaster

  • Simply head over to the remote cluster and power on the remote VM
  • Integrity of the last DR Backup can be verified easily by DR_STATUS User Attribute on REMOTE VM

    Note: Some post startup configurations might be required for network

Restoring operations on Main cluster

  • As soon as Main cluster is up and running, Hypercx DR will start looking for DR_SOURCE_VM attribute(on Remote VM).
  • Create a new VM as previously created for Remote cluster
  • Remove all virtual disks from the VM. These virtual disks will be automatically created by HyperCX DR.
  • Power off that VM.
  • Change DR_SORUCE_VM attribute on remote cluster's VM and add remote cluster's VM ID.
  • Add DR_REMOTE_VM attribute on Main cluster's VM.

- Wait for Hypercx DR to complete Failback procedure. - Once Hypercx DR completes migration a new User attribute will appear on Remote Cluster VM(DR_FAILBACK_STATUS will be set SUCCESS/FAILED) and on Main cluster's VM(MIGRATION_STATUS will be set READY_TO_USE)

- Power off remote Cluster's VM and power on Main cluster's VM.

Hypercx DR logging

All logs of Hypercx DR will be available on VM logs which can be accessed by navigating to LOGS tab of the VM. Process successful completion or failure will also be indicated on User Atrributes and further clarity to these errors(if present) will be provided in VM logs

Conclusion

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

FAQs

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.

Q: VM logs/Attribute indicate failure what to do next? A: VM logs will provide easy to understand prompts and some failures in backups can be easily fixed by correct configuration, although a Virtalus Support Engineer will assist in case of a fatal error.

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. Only HyperCX private clusters are supported at this moment.

Present Cluster: In this document present cluster refers to the primary cluster allocated to the client. Only HyperCX private clusters are supported at this moment.

Tags: VMs that are enabled to backup for disaster recovery are tagged with DR(This tag name may be adjusted).

Remote VM: On the remote cluster a VM 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.

  • Navigate to the VM one the Present Cluster that needs to be backed up and select it.

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

Creating backup VM

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

  • On the remote cluster, a VM must be created for each VM on Present Cluster that will leverage DR. This step is required because the remote VM does not need to be identical to the original one. For example, the remote VM will most likely be attached to different virtual networks available only in the remote cluster. This VM can be instantiated from any available template in the cluster, and then modified to match the user's needs.

  • After the Remote VM was instantiated in the Remote Cluster, a few final configurations and checks are required:

    1. Shut down the VM if it is running. For DR to work and guarantee consistency, Remote VM must be in PowerOff state.

    2. Adjust VM Capacity(CPU,Memory,VCPU etc)

    3. Configure the NIC cards these VMs will use. VNets on Remote Cluster may be different as in Present Cluster.

    4. Remove all virtual disks from the VM. These virtual disks will be automatically created by HyperCX DR on the first run.

  • On the bottom of the remote VM's info panel, add an attribute named "DR_SOURCE_VM" and set it's value to the Present Cluster's VM ID(i.e. the VM to be backed up)

Some final configuration..

  • Head back to Present Cluster and on the bottom of the local VM's info panel, add an attribute named "DR_REMOTE_VM" and set it's value to the Remote Cluster's VM ID.

In case of Disaster

  • Simply head over to the remote cluster and power on the REMOTE VM.
  • Integrity of the REMOTE VM can easily be verified by DR_Status User Attribute on REMOTE VM.

*Note: Some post startup configurations might be required for network*

Restoring operations on Main cluster

  • As soon as Main cluster is up and running, Hypercx DR will start looking for DR_SOURCE_VM attribute(on Remote VM).
  • Create a new VM as previously created for Remote cluster
  • Remove all virtual disks from the VM. These virtual disks will be automatically created by HyperCX DR.
  • Power off that VM.
  • Change DR_SORUCE_VM attribute on remote cluster's VM and add remote cluster's VM ID.
  • Add DR_REMOTE_VM attribute on Main cluster's VM.
  • Wait for Hypercx DR to complete Failback procedure.
  • Once Hypercx DR completes migration a new User attribute will appear on Remote Cluster VM(DR_FAILBACK_STATUS will be set SUCCESS/FAILED) and on Main cluster's VM(MIGRATION_STATUS will be set READY_TO_USE)

  • Power off remote Cluster's VM and power on Main cluster's VM.

Hypercx DR logging

All logs of Hypercx DR will be available on VM logs which can be accessed by navigating to LOGS tab of the VM. Process successful completion or failure will also be indicated on User Atrributes and further clarity to these errors(if present) will be provided in VM logs

Conclusion

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

FAQs

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.

Q: VM logs/Attribute indicate failure what to do next? A: VM logs will provide easy to understand prompts and some failures in backups can be easily fixed by correct configuration, although a Virtalus Support Engineer will assist in case of a fatal error.