Disaster Recovery
Disaster Recovery as a Service (DRaaS) for protecting your virtual infrastructure with replicated VMs you can recover at a secondary site.
Overview
Xelon HQ Disaster Recovery provides a fully managed DRaaS solution that protects your virtual infrastructure against site-level failures. By defining resource pools at a secondary site and importing replicated VMs for DR protection, you can recover workloads at the recovery site with minimal data loss.
Disaster Recovery builds on the replication engine and adds resource pool management and the ability to import replicated VMs at a secondary site. Recovery is performed by importing a replica or switching a device to its replicated cloud; there is no orchestrated or automated failover and no isolated test-failover mode.
Setting Up Disaster Recovery
Access the DR dashboard
Navigate to Virtual Datacenter > Disaster Recovery in the sidebar to open the DR management interface.
Add a resource pool
Click Add Resource Pool to register a named resource pool for a tenant on a selected cloud at the recovery site. You provide a Resource Pool ID and an optional folder name; the form does not let you specify compute, memory, or storage amounts. Xelon HQ references this pool to discover and import replicated VMs but does not itself reserve or guarantee CPU, memory, or storage capacity — any actual capacity reservation must be configured on the underlying resource pool directly.
Import replicas
The dashboard displays available replicas from your primary site. Click a replica's Import action to bring it into HQ as a managed device. During import you choose the device owner and creator, and map each of the replica's network interfaces to one of your networks. Replication parameters such as RTO/frequency are not set here; they are managed per device from the device's replication settings.
Defining Resource Pools
A DR resource pool is a named reference that associates an existing resource pool with a tenant and a cloud at the recovery site. The form does not collect CPU, memory, or storage sizing values — those fields do not exist. When you click Add Resource Pool you supply only the following:
| Field | Description |
|---|---|
| Resource Pool ID | The identifier of the resource pool to associate (3–50 characters). |
| Resource Pool folder name | An optional folder name for the pool. |
| Select Tenant | The tenant the pool belongs to. |
| Select Cloud | The destination cloud (hypervisor system) at the recovery site. |
CPU, memory, and storage available to protected VMs are governed by the underlying cloud and the resource pool itself, not by values entered in this form. If you need guaranteed capacity for a failover, configure it on the resource pool directly at the recovery site.
Managing DR Replicas
To manage VMs in your disaster recovery plan:
View available replicas
The DR dashboard lists replicas from your primary site. Each replica shows its name, status, and resource pool ownership.
Configure network mapping
For each VM, configure the network mapping to define how the VM will be connected at the recovery site. The replication frequency (RTO) is not set here; it is determined by the pre-defined replication job that was selected when replication was first enabled on the source device.
Start protection
Confirm the import to begin initial replication. The first sync may take longer depending on VM size and available bandwidth.
Recovering a Protected VM
Xelon DRaaS does not provide an isolated test-failover mode. There is no Test Failover button that creates temporary VM copies and no Clean Up Test button. Recovery is performed in one of two ways:
Import a replica
Open the Disaster Recovery page, select a replica, and use its Import action to recreate it as a new device under a chosen tenant, owner, and network mapping. Click Create Device to complete the import.
Or switch a device to its replicated cloud
On the device's replication block, use Switch to [destination cloud] to perform a live failover. This starts the replicated VM at the destination site and is a real cutover, not a non-disruptive test.
Switching to the replicated cloud is a real failover: it starts the VM at the target site and deletes the original on the source site. HQ does not provide a non-disruptive test mode, isolated test copies, or test scheduling. Testing your DR plan on a recurring basis is a best practice you must arrange operationally outside the product.
Recovery Procedures
In the event of a real disaster, follow these steps to activate your DR plan:
Assess the situation
Determine the scope of the failure and confirm that the primary site is unavailable. Verify that replication was current before the failure.
Bring replicated VMs online
The Disaster Recovery dashboard does not provide an orchestrated Failover button. To bring a replicated VM online, select it from the Disaster Recovery list and use Import / Create Device to recreate it under a chosen tenant, owner, and network mapping. Per-VM switchover to a replicated copy is handled separately from the device's replication block.
Activate recovery VMs
There is no automated DRaaS failover. To activate a replicated VM, open that device's replication panel and click Switch to [destination cloud]; HQ powers on the replicated VM at the destination site and re-attaches its NICs to the target networks selected in the switch dialog. VMs are switched individually, and network mappings are applied from that dialog — not automatically from an earlier DR import step.
Verify and communicate
Validate that all services are running and notify stakeholders. Update DNS records or external configurations as needed.
Plan for failback
Once the primary site is restored, plan the failback process to return workloads and re-establish replication.
After a failover, replication from the original primary site stops. You must reconfigure replication once the primary site is available again to restore full DR protection.