DR runbook setup

:::note Placeholder page The screenshots and copy below are from a real runbook run to completion; the authoring UI around it is still being verified end to end. :::

From the console's own recovery runbooks screen:

A runbook is the order your site comes back in: directory and DNS first, then the databases that need them, then the applications on top. Ballast walks it a tier at a time and will not start one tier until the one before it is actually serving — which is the difference between a recovery and forty VMs booting at once.

It orchestrates the Hyper-V Replica relationships you already have. Each VM in a plan keeps its own replication target; the runbook only decides the order and what has to be true between tiers.

The runbooks list shows each plan alongside its most recent result:

1. Set up replication first

A runbook orchestrates order, not replication itself. The VMs it covers need to already be replicating from the primary cluster to the recovery cluster — each one keeping its own Hyper-V Replica target — before a runbook is useful.

2. Author the runbook

A runbook is a named plan made of numbered groups, each holding one or more VMs. Groups run strictly in order; the VMs within one group run together. Here is a real two-tier plan, "Company A Website":

• Group 1 — Company Website Database (DB Server)
• Group 2 — Company Website (Web Server)

Groups run strictly in order and the VMs within one run together. A group's gate has to pass for every VM in it before the next group starts — that is what stops the application tier coming up against a directory that is not serving yet.

Each VM in a group can independently declare its network at the target, whether its guest address changes on failover, and its recovery point (latest, or a specific one). A plan that has no isolated test network declared cannot be test-failed-over — the console says so directly rather than letting a test boot collide with production addresses.

3. Invoke it

Invoking a runbook is a single operator action from the console. Ballast walks the declared groups in order, waiting for each group to actually be serving before starting the next:

When something doesn't go cleanly

A runbook run's detail names the exact cause, not just a failed/succeeded flag — including what state a partially-completed run leaves things in, which VMs are already moved and which are not. The precise wording for a paused or cancelled run is TBC pending a documented example.

After a failover

Once recovered, the runbook's primary and recovery roles are reversed (or reset, depending on the chosen recovery pattern) so replication direction and future invocation stay correct. The exact reversal flow is TBC.