Full Replication
NOTE: Formerly known as Disaster recovery
Full replication keeps a complete, ready-to-boot copy of your VMs on another storage repository: in the same pool, in a different pool, even on another site. At each run, the whole VM is exported and streamed directly into the destination SR, so a fresh standby copy is always waiting there, powered off and protected against accidental start.
If the production side is lost (hosts, storage or the entire site), you start the replicas on the destination and you are back in business.
Best practices
Disaster recovery is a vast topic and we strongly encourage you to read some literature about it. In short: define the maximum data loss you can accept (RPO) and the maximum downtime you can accept (RTO), then pick the replication frequency and infrastructure that match those numbers.
Full replication helps on the RTO side. There is no restore phase: the export and the import happen at the same time, in one streaming pass, with no intermediate file. Streaming allows exporting and importing simultaneously, so as soon as a run completes, the replica sits on the destination SR, ready to boot.
The goal is to have your DR VMs ready to boot on a dedicated host or site. A replica that boots is also living proof that the export worked.
You don't have to test replicas by hand: the backup health check feature can automatically clone a replica, boot it and verify that the guest OS comes up, then discard the clone.
Schedule a DR task
Planning a full replication job is very similar to planning a backup or a snapshot: create a new backup job, select the Disaster recovery mode, pick the VMs, set a schedule, and choose the destination storage repository (any SR that XO can reach, on any connected pool).
Your replicated VMs will be visible "on the other side" as soon as the first run is done, named after the original VM, the job and the run date, for example: web01 - DR job - (20260801T040000Z).
Retention
The retention setting (historically called depth) is the number of copies kept per replicated VM. At each run, a new copy is imported and the oldest ones beyond the retention count are removed.
Replicas are identified by the backup metadata XO stores on them and by their blocked start operation. Each one also carries a Disaster Recovery tag, and HA is disabled on it (with an extra HA disabled tag when the source VM used HA). A replica you clone, or whose start block you remove, leaves the rotation: you can play with it without the fear of losing it at the next run.
Each retained copy is a full VM on the destination SR: a high retention number will lead to huge space usage. Size your DR storage accordingly.
Network conflicts
If you boot a copy of your production VM while the original is still running, be careful: if they share the same static IP, you'll have trouble.
A good way to test a replica without this kind of problem is to clone it, remove the network interfaces from the clone, and boot it to check that the export went well.
Protection against accidental start
For each replicated VM, XO adds start and start on as blocked operations. Even a replica with "Auto power on" enabled will not be started if your DR host reboots, and neither HA nor a distracted admin can boot it behind your back.
When you actually need to run a replica, you have two options, and both take it out of the retention rotation:
- Clone it (recommended): the clone is instant, boots normally, and the original replica stays in place for the next runs. This is what the block message itself suggests: "Start operation for this vm is blocked, clone it if you want to use it."
- Remove the blocked operation on the replica (in the VM advanced tab) and start it directly. XO will no longer treat it as a replica, so the job won't delete it, and the next run will create a fresh copy alongside it.
Failover
The day the production side is gone, the procedure is short: go to the DR pool, take the most recent replica of each VM, clone it or unblock it, fix the network settings if needed, and start it. Your services are back without waiting for any restore.
Because full replication re-sends the entire VM at each run, its practical RPO is limited by how long a full export takes. If you need more frequent runs and a lower RPO, look at incremental replication, which only transfers the changed blocks. To decide how replication fits with your other backup jobs, see the backup strategy guide.