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. |
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.
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).