Recommend a Recovery Solution for Azure and Hybrid Workloads That Meets Recovery Objectives

A recovery architecture begins with business impact, not a product name. “Use Azure Backup” is incomplete until the architect knows how much data loss is acceptable, how quickly the workload must return, which failure scopes matter, and which dependencies must recover together. “Use Azure Site Recovery” is equally incomplete if the application is mostly managed PaaS services that require service-native replication rather than virtual-machine failover.

This lesson turns recovery time objective (RTO), recovery point objective (RPO), workload criticality, and hybrid topology into a defensible combination of high availability, backup, replication, recovery orchestration, and service-native protection. Azure Site Recovery (ASR) is central for supported Azure and hybrid machines; Azure Backup protects recoverable history; platform-native capabilities protect databases, storage, Kubernetes, and other managed services.

Learning objectives

After this lesson, you should be able to:

1. Translate a business impact analysis into workload tiers, RTO, RPO, retention, and failure-scope requirements.
2. Distinguish high availability, disaster recovery, and backup.
3. Recommend ASR for supported Azure VMs, VMware, Hyper-V, and physical-server recovery scenarios.
4. Select Azure Backup and service-native protection when point-in-time recovery or long-term retention is required.
5. Design recovery plans, dependency order, networking, capacity, identity, DNS, and validation.
6. Choose active-active, warm standby, pilot light, replication, or backup/restore according to objectives and cost.
7. Define evidence that the design actually meets recovery objectives.

Start with the business impact analysis

For each workload, record:

• business process and accountable owner;
• financial, safety, contractual, regulatory, and reputational impact over time;
• RTO, RPO, and maximum tolerable disruption;
• recovery granularity: record, database, VM, application, zone, region, or site;
• dependency graph: identity, DNS, network, certificates, keys, databases, queues, external partners, and operator access;
• normal and peak change rate, dataset size, and restore throughput;
• required recovery points and retention;
• allowed manual steps and minimum staffing during an incident;
• regional, sovereignty, and paired-region constraints;
• test frequency and evidence required by auditors.

RTO is the target duration from disruption/recovery initiation to an acceptable service state. RPO is the maximum tolerable interval of lost changes, expressed as a point in time. Neither is automatically guaranteed by selecting a service. Replication lag, boot order, database recovery, DNS, capacity, validation, and human decisions all consume the recovery budget.

High availability, disaster recovery, and backup are different controls

High availability may keep a zone-redundant service running without invoking a recovery plan. Disaster recovery moves or recreates service in another failure domain. Backup preserves recovery history, which remains essential when replication faithfully copies corruption or malicious changes to the secondary.

Design all three where business impact requires them. A replicated VM with no protected historical data can fail over quickly but cannot necessarily recover a file deleted last week. A perfect backup with no standby may preserve every required restore point but miss a 30-minute RTO.

Select a recovery pattern

Text equivalent: use zone-aware HA for local failures, backup for historical recovery, and select active-active, replication/warm standby, pilot light, or backup/restore for regional/site failures according to RTO and RPO. Every pattern still needs an exercised recovery plan.

Active-active

Both locations serve production traffic and maintain current data. Choose this for extremely low recovery targets when the application's data consistency and conflict model support it. It has the highest infrastructure and operational cost and requires global routing, distributed data design, and failure-isolation testing. “Deploy twice” is not enough: shared identity, DNS, keys, pipelines, quotas, or a single database can remain a hidden single point of failure.

Warm standby

A secondary environment is deployed and synchronized but runs at reduced capacity or does not normally receive full traffic. Failover scales or promotes it. This supports tighter objectives than rebuilding while reducing cost relative to full active-active. Validate target-region capacity and scale-up duration.

Pilot light

Core stateful components or minimal services remain available in the recovery location; most compute is deployed or scaled during recovery. Choose it when infrastructure as code is mature and RTO allows provisioning. Test quotas, images, dependencies, and configuration promotion.

Backup and restore

Infrastructure and data are rebuilt from protected definitions and recovery points. This is economical for lower-tier workloads but its RTO includes provisioning, data transfer, restore, application recovery, and validation. Estimate restore time using realistic data volumes rather than a small proof of concept.

Azure Site Recovery for Azure and hybrid machines

ASR is a managed replication and failover service for supported Azure VMs and hybrid machines. Sources can include Azure VMs, VMware VMs, Hyper-V VMs, and supported physical servers; recovery targets are Azure VMs. It continuously replicates changes, maintains recovery points, orchestrates failover/failback, and supports test failover.

For Azure-to-Azure recovery, current Microsoft reliability guidance recommends placing the Recovery Services vault in the target region, using zone-redundant storage for the cache account, considering high-churn support for workloads with high change rates, and using on-demand capacity reservations when target compute availability is critical. Monitor replication health and keep mobility components updated.

The vault stores configuration and orchestration metadata; the replicated workload data follows the selected replication architecture. Vault redundancy matters differently when the same vault is used for Azure Backup, so do not infer backup behavior from the ASR control plane.

Crash-consistent and application-consistent recovery points

A crash-consistent point reflects disk state as if power were lost. Many operating systems and applications can recover from it, but in-memory transactions are not coordinated. An application-consistent point uses workload-aware quiescing so applications flush state before the snapshot. It can simplify recovery but may be less frequent and adds workload coordination. The business RPO must specify whether crash-consistent recovery is acceptable.

Recovery plans

A recovery plan groups machines and defines ordered recovery groups. Machines within an appropriate group can start in parallel; groups run in sequence. Scripts and manual actions can integrate DNS, traffic controls, validation, and external systems. The plan represents the application dependency model, not simply a list of VMs.

Keep automation idempotent. An incident commander may retry a step. Scripts should detect current state rather than create duplicate routes, records, or resources. Store automation and infrastructure definitions in version control and test the same versions used in production.

Azure Backup and service-native recovery

Azure Backup protects supported Azure and hybrid workloads through Recovery Services vaults or Backup vaults, depending on the data source. Protection models differ for Azure VMs, files, disks, databases in VMs, blobs, and other workloads. Choose the correct vault and policy from current documentation rather than assuming one vault covers every service.

Backup design includes:

• backup frequency and achievable RPO;
• operational versus vault tiers and restore performance;
• retention and archive requirements;
• locally, zone, or geo-redundant vault storage as supported;
• cross-region restore requirements and regional behavior;
• soft delete, immutability, authorization, and multi-user approval protections;
• encryption and key availability during disaster;
• private endpoints and network access;
• restore testing and clean-room/ransomware recovery.

Managed PaaS services often have their own recovery controls. Azure SQL Database supports automated backups, point-in-time restore, long-term retention, zone redundancy, and geo-replication/failover patterns. Storage offers local/zone/geo redundancy, object replication, versioning, soft delete, and backup options. Cosmos DB has service-native continuous backup and multi-region capabilities. AKS recovery includes both cluster configuration and persistent data; rebuilding the control plane from infrastructure definitions is different from restoring application state.

Do not force ASR onto a PaaS service that it does not replicate. Compose the application recovery plan from service-native data recovery and machine/workload recovery.

Hybrid dependencies

Hybrid recovery introduces dependencies outside Azure:

• VMware/Hyper-V discovery and replication appliances;
• bandwidth, change rate, and initial synchronization;
• VPN/ExpressRoute and fallback connectivity;
• overlapping IP ranges and target subnet design;
• on-premises DNS, domain controllers, certificate services, and identity;
• firewalls and allow lists held by partners;
• licensing and vendor-supported configurations;
• operators who can access Azure if the corporate site is unavailable.

Document which dependencies recover in Azure and which remain on-premises. If authentication depends on domain controllers at the failed site, the recovered application may be unusable. If the target network reuses the source IP space while a partial site remains connected, routing can fail. Design the recovery network and identity path before replication is enabled.

Worked scenario: three-tier hybrid order system

Contoso runs two VMware database VMs and four application VMs on-premises. Azure Front Door serves a public web tier already hosted in Azure. The order system requires RPO of 15 minutes and RTO of two hours for site loss. Database records must be retained for seven years, and a regional Azure outage must not remove all recovery evidence.

Recommended architecture:

1. Protect supported on-premises machines with ASR to the chosen Azure target region. Size bandwidth and replication infrastructure against measured change rate.
2. Create a recovery plan with database VMs first, application VMs second, then health validation and Front Door origin/routing changes.
3. Prebuild the target virtual network, private DNS, security rules, identity dependencies, Key Vault access, and capacity. Reserve target compute if the business cannot accept regional capacity risk.
4. Use application-aware database backup with the required retention in addition to replication. Configure vault redundancy and immutability/security according to the regional and ransomware threat model.
5. Run isolated test failovers at least on the organization's approved quarterly or semiannual cadence, measure end-to-end RTO, and verify a recovery point within the 15-minute RPO.
6. Define failback, including resynchronization and the point after which the recovered Azure environment becomes authoritative.

Networking, identity, and traffic restoration

Recovery networking must be ready before disaster:

• nonoverlapping target address spaces and required peering/hub connectivity;
• network security groups, firewalls, routes, DNS resolvers, and private DNS zones;
• private endpoints and service endpoints for target-region services;
• public IP or load-balancer behavior and approved ingress;
• Traffic Manager, Front Door, DNS, or application routing changes;
• identity providers, managed identities, role assignments, emergency access, and PIM activation;
• secrets, certificates, keys, and key-vault regional/access dependencies.

DNS time-to-live affects traffic-switch timing but reducing TTL alone does not ensure clients respect it. Global proxies such as Front Door can provide health-based origin routing, but application state and data consistency must support the switch. Record who authorizes traffic failover and the validation required before directing users to the target.

Observability and recovery evidence

Monitor replication health, lag, protected-item state, backup job success, policy compliance, vault security, and target capacity. Alerts must reach operators through a path that survives the primary-site outage. A dashboard that depends on the failed identity or network is not a recovery control.

For each drill, capture:

• selected recovery point and observed data loss;
• initiation, provisioning, boot, dependency, validation, and traffic timestamps;
• manual steps, approvals, and errors;
• application smoke-test results and data reconciliation;
• target capacity and performance under representative load;
• failback/resynchronization results;
• actions, owner, and due date for every gap.

RTO and RPO should be service-level objectives with evidence, not static values copied into a document.

Common exam traps

• Backup equals disaster recovery. False. Restore time and recovery-point frequency may miss RTO/RPO.
• Replication replaces backup. False. Replication can copy corruption or deletion.
• ASR protects every Azure PaaS service. False. Use service-native recovery where appropriate.
• A running VM means RTO is met. False. The usable application and dependencies must be restored and validated.
• The source network can be cloned blindly. False. Overlapping ranges and partial-site connectivity can break routing.
• Target compute will be available during a regional event. Not guaranteed. Check quotas and consider capacity reservations.
• Test failover can use the production network casually. False. Use an isolated network and a controlled validation plan.
• One recovery tier fits every workload. False. Tier by business impact and choose cost proportionally.
• RPO is the snapshot schedule written in policy. Not necessarily. Validate observed lag and the type of recovery point the application can use.

Retrieval checkpoint

Summary

Translate business impact into explicit RTO, RPO, retention, failure scope, and dependency requirements. Use high availability for local continuity, ASR or service-native replication/standby patterns for supported disaster-recovery scenarios, and Azure Backup or platform-native backups for historical recovery. Prepare target capacity, network, identity, keys, DNS, and traffic control. Model the whole application in a recovery plan, exercise isolated failover and failback, and use measured evidence to prove the design meets its objectives.

Sources and freshness

Reviewed 2026-08-02. Scope follows the April 17, 2026 AZ-305 study guide. Current behavior is grounded in Microsoft's Reliability in Azure Site Recovery, Azure Site Recovery recovery plans, Azure Backup documentation, and current service-specific reliability guidance. The attached Exam Ref supplies historical teaching context; live Microsoft documentation controls supported workloads, regional behavior, limits, and recommendations.