Recovery Plans and Automated Failover

A Recovery Plan in Azure Site Recovery is a structured, ordered sequence of steps that orchestrates the failover of multiple VMs together. Rather than failing over each VM individually, a recovery plan groups them into groups that fail over in sequence — ensuring that infrastructure (database, middleware, web) comes up in the correct order, just as it would during initial deployment.

To create a recovery plan, you select the source site (primary region) and target site (secondary region), then add the VMs you want to include. The plan wizard automatically creates a default group, but you can add more groups to control the failover sequence. VMs in the same group fail over simultaneously; groups execute in numbered order.

For a typical three-tier application, the recovery plan should have three groups:

• Group 1 — Database tier VMs (must start first)
• Group 2 — Application/middleware tier VMs
• Group 3 — Web frontend VMs (start last)

Each group waits for the previous group to complete failover successfully before starting. This mirrors the correct startup order and prevents web tier VMs from starting before the database is ready to accept connections.

Recovery plans support pre-actions and post-actions at each group boundary. These can be:

• Manual actions — pause the failover and wait for a human to confirm (e.g., 'Verify database is ready')
• Azure Automation runbooks — automatically execute a script (e.g., update DNS records, disable maintenance mode)

Using Automation runbooks enables fully automated failover without human intervention for Tier 1 workloads.

Azure Site Recovery supports two types of failover:

• Planned failover — initiated before a known event (e.g., data centre maintenance). The primary VM is shut down cleanly, data is synchronised, and then the secondary VM starts. No data loss.
• Unplanned failover — triggered during an actual disaster. The primary VM may be unavailable, so ASR uses the most recent replication checkpoint. Some data loss is possible depending on the RPO.

After a failover, the recovered VMs in the secondary region are in a pending commit state. You must commit the failover to confirm that the secondary site is now the active site and that you do not want to roll back. Once committed, you can set up reverse replication to protect the secondary site and eventually fail back to the primary region when it is restored.

After committing a failover, the replicated items in the original primary region are no longer actively replicated. To restore protection, you must reprotect the items — this reverses the replication direction so the new primary (formerly secondary) replicates to the original primary region. Reprotection takes time and should be initiated as soon as the original primary region is available again.

Every step in a recovery plan adds to the total RTO. Common time consumers include:

• VM startup time (2-5 minutes per VM)
• Application warm-up time (database connection pool initialisation, cache warming)
• DNS propagation after IP changes
• Manual approval gate wait times

Measure each step during test failovers and sum them to calculate your actual RTO versus your target.

After a failover, VMs in the secondary region have different IP addresses. For applications that expose a public DNS name, you must update DNS to point to the new IPs. Use an Azure Automation runbook as a post-failover action to update Azure DNS or Traffic Manager endpoint health to redirect traffic automatically — avoiding a manual step that could delay your RTO.

During a failover, the Azure portal Jobs view in the Recovery Services vault shows real-time progress for each step in the recovery plan. You can see which group is executing, which VMs have successfully started, and whether any scripts or manual actions are pending. Monitoring this view allows the recovery team to intervene quickly if a step fails.

Key best practices for recovery plans:

• Keep groups small (5-10 VMs) to limit blast radius if a group fails
• Use Automation runbooks instead of manual actions wherever possible to reduce RTO
• Document the expected startup time for each group so RTO can be calculated
• Run a test failover at least quarterly to validate the plan
• Review and update the plan whenever new VMs are added or application architecture changes

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: a recovery plan orchestrates the ordered failover of multiple VMs with pre/post actions at each group; unplanned failover uses the last replication checkpoint while planned failover has zero data loss; and after failover you must commit and reprotect to restore DR protection. Next up we explore how to test DR plans without impacting production.