Replication
Replicate virtual machines to secondary sites for business continuity and rapid failover.
Replication is configured per device and accessed from the Multicloud replication card on the device detail page sidebar. Navigate to Virtual Datacenter > All Devices and open a device to view its replication status. See Virtual Machines for device management.
Overview
VM Replication in Xelon HQ copies your virtual machine to a second cloud on a recurring schedule (RTO) that you choose — from every 30 minutes up to every 24 hours — maintaining a periodically-updated replica you can switch to if the primary site fails. Replication provides faster recovery times than traditional backups, making it essential for business-critical workloads that require minimal downtime.
Replication provides continuous or near-continuous data protection with fast failover, while backups provide periodic point-in-time snapshots. For comprehensive protection, use both in combination.
Viewing Replication Status
To view replication status, open a device from Virtual Datacenter > All Devices and look for the Multicloud replication card in the device detail page sidebar. The card shows:
- Replication state: Whether replication is ON or OFF for the device.
- RTO: The recovery time objective based on the replication frequency (in hours).
- Location: The source cloud location and the destination cloud. When replication is ready, a link to switch to the replicated cloud is shown.
Click Edit on the Multicloud replication card to change the replication configuration or enable/disable replication for the device.
Replication Prerequisites
To enable VM replication, your organization must have access to at least two public cloud locations. If you only have access to one cloud, contact support at the address shown in the replication card to set up the functionality.
Failover to Replicated VM
When the primary site is unavailable or you need to switch to the replica, you can perform a failover.
Select the replication job
Navigate to the replication job for the VM you want to fail over.
Initiate failover
In the Multicloud replication card, click the Switch to {destination cloud name} link. A dialog will open where you must select the target network for each NIC, optionally choose a backup plan for the destination, and enter your password to confirm. Click Switch to {destination} to proceed.
Verify the replica
Confirm that the replica VM is running and serving traffic correctly. Check application health and data integrity.
Update DNS or load balancers
If not handled automatically, update DNS records or load balancer configurations to point to the new VM location.
After failover, the replica is powered on and becomes the live VM, the original source VM is deleted, and the replication job is marked switched (there is no paused state). To return to the original site once it is available, open the Multicloud replication card and click Switch back to {source datacenter}. To re-establish ongoing protection afterward, assign a replication tag to the device again.
RPO and RTO Considerations
| Metric | Definition | Typical Value |
|---|---|---|
| RPO (Recovery Point Objective) | Maximum acceptable data loss measured in time. Determined by the replication frequency. Recovery Point Objective is a general DR concept; the product does not surface it as a separate field. | Bounded by the replication frequency you select (every 30 minutes up to every 24 hours) |
| RTO (Recovery Time Objective) | Maximum acceptable downtime from failure detection to service restoration. | Hours (RTO is the replication frequency, reported on the device card and usage reports in whole hours, e.g. 1, 2, or 4 hours) |
Replication RPO depends on the sync frequency and network bandwidth between sites. To check replication health, open the device and review the replication frequency (shown as RTO, in hours) and current status in the Multicloud replication card; there is no separate "RPO Status" column or replication dashboard.
Best Practices
- Replicate all tier-1 workloads that require minimal downtime and data loss.
- Test failover quarterly to ensure the process works and your team is familiar with the procedures.
- Monitor RPO compliance and investigate any replication lag promptly.
- Document the failover procedure including DNS changes, application verification steps, and stakeholder notification.
- Combine with backups for defense in depth: replication handles site failures, while backups protect against data corruption and accidental deletion.
- Plan for failback after a failover event to return workloads to the primary site.