DR drill

A DR drill proves that protected workloads actually recover — same workflow as a disaster event, run against the last consistent replicated copy, with zero impact on production or replication. Drills are built on test recovery plus an isolated drill environment.

Why drills are non-intrusive

Test drill operations recover workloads in the target site from the last consistent replicated copy. Production workloads are untouched, and replication continues uninterrupted throughout the drill. Test recoveries also do not consume license capacity.

Prepare the drill environment

Drill runbook

1. Confirm sync status

   All drill VMs should show in-sync or init-success under Jobs → Replication. See Status check.

2. Run a test recovery into the sandbox

   Follow the test recovery workflow, pointing networks at the sandbox. Skip plan-level recovery scripts if they mutate shared infrastructure (DNS and similar).

3. Validate applications

   Connect over RDP/SSH using the IPs from the recovery jobs, verify services start in boot order, and record per-application validation results and timings.

4. Clean up

   Remove drill instances via Actions → Cleanup Recoveries → Cleanup Test Recoveries to stop cloud spend.

5. Record results

   Export a report covering jobs, events, and alerts from the drill window — see Reporting. Scheduled reports can distribute drill evidence automatically.

Drill cadence

Quarterly drills per Tier 1 plan are a sound baseline; align cadence with your compliance regime (RBI/IRDAI guidelines for BFSI environments typically expect at least annual, often semi-annual drills). Re-drill after material changes: new workloads in a plan, target-platform changes, or network redesigns.

Related docs

• Recovery testing

• Preparing target site

• Reporting