Disaster recovery

Backups protect your data; disaster recovery protects your service. If a whole site goes down — power, network, flood, fire — DR is what brings the affected virtual machines back to life at a second site, in the right order, on the right networks, within a time you decided in advance. This guide explains how it works and how to set it up.

DR needs a second cluster at a second site to recover to. One cluster protects you against a failed disk or a failed host on its own; recovering from the loss of the whole cluster is what a paired second site is for.

How it works, in one picture

You choose which virtual machines matter, and the platform continuously ships their changes to the second site in the background. At the far end sits a ready-to-run copy of each protected VM, kept close to current. When you need it, you promote those copies and start the VMs — either for real, or as a rehearsal.

Recovery point: how much can you afford to lose?

The recovery point objective (RPO) is how far behind the copy at the DR site is allowed to fall — in effect, the most data an outage could cost you. You set it per group of VMs, and the platform keeps up to it:

Minutes, for VMs on the cluster's own storage. Changes stream continuously, so the DR copy is typically only a few minutes behind. This is the default and the recommended path.
A scheduled interval, for VMs on attached external storage. These replicate on a snapshot schedule you choose (for example, hourly).

A live view shows the actual recovery point for every protected group, so you can always see how current your DR copy really is — not just the target you asked for.

Recovery plans: bring a whole application up in order

Real applications aren't single VMs — they're a database, then the services that need it, then the web tier, on particular networks. A recovery plan captures exactly that:

Membership — which VMs come up together.
Boot order and delays — start the database first, wait for it, then the rest.
Network remapping — the DR site's networks aren't the primary site's; the plan maps each VM onto the right network at the destination automatically.

Adding a VM to a plan is all it takes to start protecting it — the platform detects how that VM is stored and begins replicating it. "Bring up the ERP stack at the DR site" becomes one action instead of a frantic checklist.

Pair the two sites — once

Linking your primary and DR clusters is a one-time step: a secure, authenticated handshake that lets the two sites replicate to each other and hand off. After that, protection is just a matter of which VMs you add to which plans.

Rehearse before you need it: test failover

A DR plan you've never tested is a hope, not a plan. Test failover checks a recovery plan for real — that every VM in it is replicated and ready to come up at the DR site — and reports the result without touching production and without disturbing replication. Run it on a schedule, keep the reports, and walk into your audit with evidence instead of assurances.

When it's real: failover

When the primary site is genuinely gone, an administrator declares a failover on the DR site. For each VM in the plan, in the boot order you set, the platform promotes its replicated copy to writable, recreates the VM at the DR site, connects it to the mapped network, and powers it on — pausing between VMs where you asked it to. Progress is recorded step by step, so you can watch the recovery unfold and prove afterwards what happened when.

Ransomware recovery: copies nothing can change

Ordinary replication faithfully copies whatever is on the primary — including damage. So alongside the live copy, DR can keep immutable checkpoints: recovery points locked write-once for a retention period you set. For that period nobody can alter or delete them — not an administrator, not an attacker with stolen credentials, not the ransomware itself. If the worst happens, you have clean points in time to recover to.

What to expect, honestly

DR is for whole-site loss. Everyday failures — a dead disk, a dead host — are handled automatically within a single cluster and never need a failover. See Operations.
You need somewhere to recover to. A second cluster, at a location that won't share the primary's fate. Replication and failover are validated against a real paired site.
Returning home is a planned move. Once the primary site is healthy again, you re-establish replication in the other direction and switch back during a window you choose — a controlled step, not a scramble.

DR sits inside a larger data-protection story: backups and immutable off-site copies for data, this for service continuity. Most production installations use both.