Disaster Recovery
Cockpit protects your virtual machines with hypervisor-level, active-passive replication: a VM running at your primary site (Site A) continuously replicates its disks to a secondary recovery site (Site B). If the primary site fails — or during planned maintenance — you recover the workload on the secondary site with a bounded amount of data loss.
Replication is coordinated by Cockpit but the data moves peer-to-peer directly between the Vapor hosts, so recovery traffic does not flow through the management plane.
How it works, briefly
- Baseline sync copies the full disk once.
- Incremental syncs then transfer only the blocks that changed since the last recovery point, on your RPO schedule (changed-block tracking, not a full re-copy).
- Each successful sync becomes a recovery point you can fail over to.
What you can do
| Guide | Task |
|---|---|
| Configure replication | Pair sites, enroll a VM, and set its replication policy (RPO, retention, network remap, guest re-addressing). |
| Operate & monitor | Trigger a manual sync, read replication health, and understand recovery points. |
| Failover & failback | Run a test failover (drill), planned or unplanned failover, then reprotect and fail back. |
Orchestrating recovery across many VMs (DRM)
Cockpit replicates and fails over VMs individually. When a real recovery involves many workloads that must come back in a specific order — databases before the applications that depend on them — you can drive it as one repeatable runbook with the Disaster Recovery Manager (DRM), an optional appliance that orchestrates Cockpit.
- One DRM appliance runs at each site, each connected to that site's Cockpit.
- You group workloads into a recovery plan — an ordered list of VMs with priority groups and per-step boot delays — and run, test, or fail it over as a single unit.
- The two DRM appliances are paired, so a plan you author at the primary site is automatically kept as a read-only copy at the recovery site. If the primary site is lost, you open the recovery site's DRM and execute that plan against its local Cockpit — with no dependency on the failed site.
DRM builds on the same Cockpit replication described in these guides; it adds ordering and one-click, multi-VM execution on top. DRM is optional — Cockpit's built-in replication and per-VM failover work on their own. See the DRM appliance's own operations guide for setup and runbooks.
Key terms
- Site pair — a trusted link between your primary and recovery Cockpit instances, required before any VM can replicate.
- RPO (Recovery Point Objective) — how often replication runs, i.e. the most data you can lose (e.g. 15 minutes).
- Recovery point (PIT) — a point-in-time state on the recovery site you can fail over to. Retention decides how many are kept.
- Failover — bringing the VM up on the recovery site. Planned does a clean shutdown + final sync (no data loss); unplanned recovers from the last synced point when the source is gone.
- Reprotect — after a failover, reverse the replication direction so the recovery site protects back toward the original site.
- Failback — return the workload to the original site once it is healthy again.
- Recovery plan (DRM) — an ordered, multi-VM runbook (priority groups + boot delays) that the DRM orchestration appliance runs, tests, or fails over as one unit.
- DRM site pairing — a trusted link between the two DRM appliances (distinct from the Cockpit site pair above): it replicates recovery plans to the recovery site so they are ready to execute there during a disaster.
Before you start
- You need two Cockpit sites (primary and recovery), each managing at least one Vapor host with enough free storage at the target datastore.
- For application-consistent recovery points and guest IP re-addressing, install the QEMU Guest Agent in the guest OS.
- You need a role that permits replication actions (see Access Control).