Failover & Recovery
Failover brings a protected workload up at the recovery site. There are three kinds, and choosing the right one matters.
| Type | Disruptive? | Source affected? | When to use |
|---|---|---|---|
| Test failover | No | No | Rehearsing recovery, at any time |
| Planned migration | Yes (graceful) | Gracefully stopped | A scheduled move with the primary still healthy |
| Emergency failover | Yes | Not touched | The primary site is down or unreachable |
These actions are licensed and gated
Failover, planned migration, test failover, and reprotect require the Disaster Recovery entitlement on Cockpit. If it is not licensed, the controls are disabled with an explanatory tooltip.
Test failover (rehearsal)
Test failover boots a copy of the workload at the recovery site in an isolated bubble network. The production VM keeps running and is never touched, so you can rehearse recovery safely and as often as you like.
To run: from Cockpit's Replication tab choose Test Failover, or from a DRM plan/failover view choose Test.
What to verify: the test copy boots, and (if the guest has an agent and IP mapping) comes up on its mapped address. Every disk of a multi-disk workload should be attached from the replica.
Always clean up: when finished, choose Stop Test Failover (or Cleanup test on a plan). This removes the isolated copy and its temporary network. A test that is left running continues to consume resources.
Test failover is your safety net
Run a test failover after protecting a workload, after changing its configuration, and on a regular schedule. It is the only non-disruptive way to prove a workload is genuinely recoverable.
Planned migration
Planned migration is a graceful, coordinated move while the primary site is still healthy — for example, a maintenance window or a controlled relocation.
It:
- Gracefully powers down the workload at the primary site.
- Runs a final replication delta so no data is lost.
- Boots the workload at the recovery site.
Because the source is confirmed stopped before the recovery boots, there is no risk of the workload running in two places at once.
To run: from Cockpit's Replication tab choose Planned Migration, or run a recovery plan whose steps use the failover action while the primary is up.
Emergency failover
Emergency failover is for a real disaster — the primary site is offline or unreachable. It immediately registers and powers on the workload at the recovery site from the latest available recovery point.
To run: from Cockpit's Replication tab choose Emergency Failover (you will be asked to confirm), or run the replicated recovery plan from the surviving DRM.
Use emergency failover only when the primary is truly down
Emergency failover recovers from the last recovery point, so any data written after that point is lost. If the primary is actually still running, forcing a recovery can create a split-brain (the same workload live at both sites). DRM guards against this by confirming the source is stopped or unreachable first; if the source is still reachable and running, the failover is refused unless you explicitly override it.
Recovery-point selection
Failover boots from the latest completed recovery point at the recovery site. Recovery points whose underlying data is not actually present are never offered — only physically restorable points are used. You can review the available recovery points for a workload in Cockpit's Replication tab or DRM's recovery-points view.
After a failover
Once the workload is running at the recovery site, the next step is usually to reprotect it (replicate it back toward the original site) and later fail it back. See Reprotect & Failback.