Azure-to-Azure DR runbook

An Azure-to-Azure DR drill should start with a narrow, written scope. Pick one representative VM and decide what the drill is meant to prove before anyone touches the environment. Otherwise the team will confuse "a VM was created" with "the service recovered."

The scope should describe the source workload, the target Azure subscription, region, resource group, network, subnet, expected VM size, and the success criteria. For some drills, success may be booting the VM and logging in. For others, success may require application checks, user access, database connectivity, and dependency validation.

Start with non-production unless the team has already practiced the path. The point of the first drill is to find missing assumptions while the business is not depending on the outcome.

Most DR delays come from missing prerequisites, not from the restore command itself. Azure permissions, resource quotas, target networking, DNS assumptions, identity dependencies, and firewall rules can all block recovery after the backup copy is already available.

Treat the preflight as a recovery rehearsal. Confirm the selected recovery point, the health of the protected source, the target subscription and region, the expected network path, and the people who can approve the action. If a required permission or target resource is missing, that is a useful drill finding before failover begins.

The preflight should also include cleanup planning. A drill that creates temporary resources but does not define cleanup can leave cost, access, or routing changes behind.

During failover, measure each stage separately. Azure resource creation, disk attachment, VM boot, login readiness, service startup, and application validation are different parts of the timeline. Combining them into one number hides the real bottleneck.

Keep the drill controlled. Use the agreed recovery point, avoid destructive source changes unless the scenario explicitly requires them, and record every manual decision. Manual steps are not failures, but undocumented manual steps are future risk.

If Azure capacity, quotas, naming conflicts, or network rules slow the drill, capture that directly. Those findings are often more useful than a clean demo because they show what would affect a real recovery.

A recovered VM is not the same as a recovered service. The VM can boot while the application fails, while identity is unavailable, while DNS points to the wrong place, or while downstream systems reject traffic.

Validation should use the viewpoint of the user and the dependent system. Can an operator log in? Are services running? Can the application reach its database? Are certificates, secrets, DNS, and firewall rules correct? Does the application owner agree that the workload is usable?

Record validation evidence while the result is fresh. Screenshots, logs, timestamps, and short notes are enough if they let another engineer understand what passed and what still needs work.

A DR drill needs a clean ending. Before the drill starts, decide whether the recovered VM will remain as a standby artifact, be failed back, be isolated for inspection, or be destroyed after evidence is captured.

Cleanup is part of operational safety. Temporary credentials, firewall openings, DNS changes, public IPs, disks, snapshots, and test resources should not be left behind because the team moved on after the exciting part of the drill.

Also confirm that ongoing protection remains in the expected state. A drill should not accidentally reduce backup coverage or leave production assumptions changed without review.

The runbook is only useful if it improves after every drill. A successful drill should still produce changes: clearer owners, better validation steps, updated timing, or removed ambiguity. A failed drill should produce even more valuable findings.

Review evidence in terms of recovery stages. How old was the selected restore point? How long did Azure provisioning take? How long until the VM booted? How long until the application was ready? Which stage required waiting on a person, permission, or missing detail?

Use the review to update the next drill. The goal is not to make one page look complete. The goal is to make the next recovery less dependent on memory.