Context
Azure Site Recovery test failover creates a recovery instance for a drill while replication protection remains in place. The drill is useful only if the recovered application can be tested without colliding with production identities, addresses or external side effects. Network isolation is therefore part of recovery correctness.
Prerequisites are healthy protected items, a documented recovery plan and an approved target-region test network. Identify application dependencies and the people who validate them. Decide how payment calls, email, scheduled jobs and other external actions will be blocked or redirected during testing.
1. Validate recovery settings and isolation
Read each replicated item's target compute, disk and network settings. Confirm the test network and intended subnets. Do not assume a nonproduction name guarantees isolation: inspect peering, VPN connectivity, DNS forwarding and access to shared production services.
Provide a controlled administrator access path to recovered machines. Prepare test dependencies or approved substitutes for identity, DNS and databases. If the test requires access to a shared dependency, document that exception and its permitted operations. A VM that boots without its dependencies does not yet represent a functioning application.
2. Select the recovery point deliberately
Review the available timestamps and choose the recovery-point type according to the drill's question. Latest processed avoids additional processing, while Latest processes available replicated data before creating its point. Application-consistent points address another validation requirement. These options have different recovery timing implications.
Record the selected timestamp and expected data boundary. Do not treat the newest timestamp as automatic proof of application consistency. For a multi-VM application, review ordering and recovery plan behavior so independent machines do not start with incompatible expectations about their shared state.
3. Run the drill and validate business behavior
Track the test failover job and verify the created VM's size, disks and network. Then perform representative application checks using known test records. Inspect disabled outbound effects before exercising workflows that could notify real users or invoke production partners.
Measure the drill's observed stages separately: recovery operation, guest startup, dependency readiness and business acceptance. Keep these observations distinct from contractual recovery objectives. Record manual steps and missing configuration, since they reveal what an actual regional recovery would still require.
Diagnostic checkpoints
| Observation | Likely gap | Next evidence |
|---|---|---|
| VM running, application unavailable | Dependency or guest readiness | Startup and service checks |
| Test resolves production addresses | Isolation or DNS design | Forwarders and zone visibility |
| Data exists but workflow fails | Recovery ordering | Dependency and consistency checks |
| Drill complete, resources remain | Incomplete cleanup | Test failover cleanup state |
Illustrative scenario
A hypothetical recovery drill starts an order worker in a separate subnet that still reaches the production notification service. Before processing test orders, the team identifies and redirects that side effect. The drill then validates recovery without sending real notifications. This fictional scenario illustrates isolation review and claims no measured recovery result.
Verification and recovery SOP
Use the supported Cleanup test failover workflow and retain the recorded observations. Verify that test VMs and associated temporary resources were removed as intended, while protected items remain healthy. Confirm that no test routing or credentials remain active.
Maintain network isolation, recovery-point rationale, application checks and cleanup evidence in the SOP. Monitor replication health separately from drill completion. Repeat after major dependency or topology changes, and track unresolved manual steps as recovery engineering work rather than marking the drill successful solely because Azure created a VM.
Explore Clouvenix backup disaster recovery for implementation and operational handover.