Design Solutions for Backup and Disaster Recovery — Lesson

Every organization's data is one accidental deletion, ransomware attack, or regional outage away from catastrophe. Azure provides a layered backup and disaster-recovery (BCDR) toolkit—from point-in-time snapshots to full cross-region failover—but choosing the right combination of services, vaults, policies, and replication strategies is where architects earn their keep.

This lesson integrates four learning objectives: designing BCDR for Azure and hybrid workloads (LO 22), backing up compute resources (LO 23), backing up databases (LO 24), and protecting unstructured data (LO 25). Together they form the exam's end-to-end BCDR story.

Reference: Ch. 3, §3.1, p. 99–120 of the AZ-305 exam book.

Why This Matters

A single hour of downtime for a tier-1 application can cost an enterprise $300,000 or more. Compliance frameworks such as SOC 2, HIPAA, and ISO 27001 mandate documented backup and recovery procedures. The AZ-305 exam tests your ability to recommend backup strategies that balance cost, recovery speed, and data durability across compute, databases, and storage. Getting BCDR wrong does not just cost money—it can end careers and close businesses.

Architects who master this topic can confidently design landing zones where every workload has a tested recovery path, RPO and RTO targets are met, and immutable backups protect against insider threats and ransomware.

Prerequisites

• Azure Resource Manager (ARM) fundamentals: Can you describe how subscriptions, resource groups, and resources are organized in ARM? You will need this to understand vault placement and policy scope.
• Virtual machine basics: Can you explain the difference between OS disks, data disks, and managed disks? VM backup builds on this knowledge.
• Azure SQL Database and Managed Instance awareness: Can you list the service tiers (General Purpose, Business Critical, Hyperscale) and explain what a logical server is?
• Azure Blob Storage concepts: Can you distinguish between block blobs, page blobs, and append blobs, and explain access tiers (Hot, Cool, Cold, Archive)?
• Networking fundamentals: Can you describe VNets, subnets, and private endpoints? Cross-region replication and Azure Site Recovery use network concepts extensively.

Learning Objectives

1. Evaluate RPO and RTO requirements and map them to Azure BCDR services for both cloud-native and hybrid workloads.
2. Design a compute backup strategy using Azure Backup, Recovery Services Vaults, and Azure Site Recovery that meets organizational SLAs.
3. Recommend database backup configurations—including PITR, LTR, geo-restore, and auto-failover groups—for Azure SQL, PostgreSQL, and MySQL workloads.
4. Architect an unstructured-data protection plan using blob versioning, soft delete, immutable storage, and Azure Backup for Blobs.
5. Analyse trade-offs between backup frequency, retention cost, cross-region replication, and immutability when designing enterprise BCDR solutions.
6. Design end-to-end disaster-recovery runbooks that combine compute failover, database geo-restore, and storage account failover into a tested recovery plan.

Building Blocks

Recovery Point Objective (RPO) — Analogy: Think of RPO as the length of the "rewind button" on a DVR. If your RPO is 4 hours, you accept losing up to 4 hours of recordings. Formal definition: The maximum acceptable age of data that can be restored after an outage, measured in time. Why it matters: RPO directly determines backup frequency—shorter RPO means more frequent snapshots and higher cost.

Recovery Time Objective (RTO) — Analogy: RTO is how long you wait for the TV repairman to arrive after the screen goes black. Formal definition: The maximum acceptable duration between the start of an outage and full service restoration. Why it matters: RTO drives architectural choices—hot standby gives minutes-level RTO; cold restore from archive can take hours.

Recovery Services Vault — Analogy: A central safe-deposit box that holds backup copies of your VMs, SQL databases, file shares, and on-premises servers. Formal definition: An Azure resource (Microsoft.RecoveryServices/vaults) that stores backup data and replication metadata. It supports geo-redundant storage (GRS), cross-region restore (CRR), and RBAC-scoped access. Why it matters: Almost every Azure Backup workload funnels through a Recovery Services Vault; its redundancy setting determines whether your backups survive a regional disaster.

Backup Vault — Analogy: A newer, lighter safe designed for modern workloads that don't fit in the original vault. Formal definition: A separate vault resource (Microsoft.DataProtection/backupVaults) introduced for workloads like Azure Disks, Azure Blobs, and Azure Database for PostgreSQL Flexible Server. Why it matters: Exam scenarios may require choosing between a Recovery Services Vault and a Backup Vault depending on the workload type.

Azure Site Recovery (ASR) — Analogy: An understudy who rehearses your application's role in a second theatre, ready to step on stage the moment the lead cannot perform. Formal definition: A service that orchestrates replication, failover, and failback of VMs and physical servers between Azure regions (or from on-premises to Azure). Why it matters: ASR provides near-zero RPO (continuous replication) and minutes-level RTO—the exam's go-to answer for compute disaster recovery.

Immutable Backup — Analogy: A write-once DVD—once data is burned, nobody can overwrite or erase it until the retention period expires. Formal definition: A policy that prevents deletion or modification of backup recovery points for a defined period. Why it matters: Immutability is the last line of defence against ransomware and malicious insiders who compromise admin credentials.

Deep Dive

BCDR for Azure and Hybrid Workloads (LO 22)

Designing BCDR starts with a Business Impact Analysis (BIA) that classifies workloads into tiers and assigns RPO/RTO targets per tier.

Hybrid considerations: On-premises servers can replicate to Azure via Azure Site Recovery using the ASR Mobility Service agent. The Microsoft Azure Recovery Services (MARS) agent handles file-and-folder backup from Windows machines directly to a Recovery Services Vault. For VMware and Hyper-V environments, an on-premises ASR appliance or process server orchestrates replication.

[!TIP] When the exam says "hybrid BCDR," it almost always means Azure Site Recovery for VMs and MARS agent for file-level backup. If the scenario mentions tape replacement, think Azure Backup with long-term retention to vault storage.

Storage redundancy for vaults is a critical design decision:

[!WARNING] You must set the vault storage redundancy before registering the first backup item. Changing redundancy after backups exist requires creating a new vault and migrating.

See the LO 22 lesson for a deeper exploration of hybrid replication topologies and failover orchestration.

Backing Up Compute Resources (LO 23)

Azure Backup for VMs creates application-consistent snapshots (Windows VSS / Linux pre/post scripts) stored in a Recovery Services Vault.

Backup policy anatomy:

The backup flow has two phases: (1) a snapshot is taken and stored locally in the snapshot resource group for fast restore (instant restore tier), and (2) the snapshot is transferred to the vault (vault tier) for long-term retention.

Azure Site Recovery for compute DR: ASR continuously replicates VM disks to a target region. During failover, VMs are spun up from the replicated disks. ASR supports recovery plans that sequence VM startup with scripts and manual actions—critical for multi-tier apps where the database must start before the application tier.

[!IMPORTANT] ASR test failovers should be run quarterly in an isolated VNet. The exam expects you to recommend test failovers as part of a DR runbook—never skip this in a design.

See the LO 23 lesson for extended coverage of enhanced backup policies, selective disk backup, and multi-VM consistency groups.

Backing Up Databases (LO 24)

Azure SQL Database provides automatic backups with no agent to install—full, differential, and transaction-log backups are managed by the platform.

Point-in-Time Restore (PITR) lets you restore to any second within the retention window (default 7 days, configurable up to 35 days). PITR creates a new database on the same server—it never overwrites the original.

Long-Term Retention (LTR) copies full backups to a separate RA-GRS blob store and retains them for up to 10 years. LTR is independent of PITR—configuring one does not configure the other.

[!NOTE] PITR retention defaults to 7 days for all tiers. LTR must be explicitly enabled via a retention policy (W=0, M=0, Y=1 keeps one yearly backup for 1 year).

Geo-restore leverages GRS-replicated backups to restore a database in a different region. RPO is up to 1 hour (the replication lag for GRS). For tighter RPO, use auto-failover groups which replicate data synchronously or asynchronously to a secondary region and provide a listener endpoint that redirects traffic automatically during failover.

For Azure Database for PostgreSQL Flexible Server and MySQL Flexible Server, backups are also automatic with PITR up to 35 days and optional geo-redundant backup. These workloads use a Backup Vault (not a Recovery Services Vault) for long-term or on-demand backups.

See the LO 24 lesson for deep dives into Hyperscale backup architecture, Managed Instance backup differences, and auto-failover group DNS mechanics.

Backing Up Unstructured Data (LO 25)

Azure Blob Storage has built-in data-protection features that reduce or eliminate the need for a separate backup agent:

Soft delete — Retains deleted blobs (and their versions) for a configurable retention period (1–365 days). Acts as a recycle bin.

Blob versioning — Automatically creates a new version on every overwrite. Previous versions are retained and can be promoted back to current.

Point-in-time restore — Restores block blobs in selected containers to an earlier state. Requires versioning + change feed + soft delete to be enabled.

Immutable storage — Time-based retention policies or legal holds prevent deletion or modification. Supports WORM (Write Once, Read Many) compliance for SEC 17a-4(f), CFTC, and FINRA.

For Azure Files, Azure Backup takes share snapshots stored in a Recovery Services Vault, supporting daily/weekly/monthly/yearly retention.

For large-scale or compliance-driven blob backup, Azure Backup for Blobs (operational and vaulted tiers) can be configured in a Backup Vault:

[!TIP] For the exam, if the scenario mentions compliance or WORM, the answer is immutable storage with a time-based retention policy. If it mentions accidental deletion, the answer is soft delete + versioning. If it mentions ransomware protection for backups, the answer is immutable vault backup.

See the LO 25 lesson for extended coverage of Azure Files backup, Data Lake Storage Gen2 considerations, and storage account failover mechanics.

Worked Examples

Easy — Single-VM Backup Policy

Problem: Contoso runs a single Windows Server VM (contoso-erp-vm) in East US. The business requires 24-hour RPO with 30-day retention. Budget is limited. Design a backup solution.

Step-by-step solution:

1. Create a Recovery Services Vault in East US with LRS redundancy (cheapest; regional DR is not required).
2. Create a backup policy: daily frequency, 2-day instant restore, 30-day daily retention.
3. Enable backup for contoso-erp-vm using this policy.
4. Verify the first backup job completes successfully.

[!NOTE] Key insight: LRS is acceptable here because the RPO is 24 hours and no cross-region requirement was stated. Choosing GRS would roughly double the vault storage cost with no benefit to the stated requirements.

Medium — Multi-tier App with Regional DR

Problem: Contoso's e-commerce platform runs across 3 VMs (web, app, SQL) in East US. The business requires $< 15$-minute RPO and $< 1$-hour RTO. A full regional outage must not cause data loss. Design the BCDR solution.

Step-by-step solution:

1. Compute DR: Enable Azure Site Recovery for all 3 VMs, replicating to West US. ASR provides near-zero RPO via continuous replication.
2. Recovery plan: Create a recovery plan with 3 boot groups — SQL first, then app, then web — to respect startup dependencies.
3. Database DR: For the SQL VM, also configure an Always On Availability Group with asynchronous commit to a secondary in West US for near-zero RPO at the data layer.
4. Backup: Additionally, configure daily Azure Backup with GRS and cross-region restore enabled as a defence-in-depth layer for point-in-time recovery.
5. Testing: Schedule quarterly test failovers in an isolated VNet in West US.
6. Monitoring: Create Azure Monitor alerts for ASR replication health and backup job failures.

[!NOTE] Key insight: ASR handles the RTO requirement (minutes-level failover), but backup is still needed for operational recovery (e.g., restoring from ransomware to a clean point-in-time). The two are complementary, not competing.

Hard — Enterprise BCDR with Compliance Constraints

Problem: Contoso Financial Services must protect 50 VMs, 10 Azure SQL databases, and 200 TB of blob storage across two regions. Requirements: RPO $< 5$ minutes for Tier 0 databases, 7-year LTR for audit data, immutable backups for all workloads, and SOC 2 compliance evidence. Budget exists but must be justified. Design the full BCDR architecture.

Step-by-step solution:

1. Classify workloads into tiers (Tier 0 = payment DBs, Tier 1 = CRM VMs, Tier 2 = reporting, Tier 3 = dev/test).
2. Tier 0 databases: Deploy auto-failover groups (synchronous commit within region, asynchronous to secondary region). Enable PITR with 35-day retention. Enable LTR with yearly backups retained for 7 years.
3. Tier 1 VMs: Enable ASR to the secondary region with recovery plans. Enable daily backup with GRS and CRR.
4. Tier 2/3: Daily backup with LRS, 30-day retention. No ASR needed.
5. Blob storage (200 TB): Enable soft delete (30 days), versioning, and immutable storage with a 7-year time-based retention policy for audit containers. Configure Azure Backup for Blobs vaulted tier with GRS for compliance copies.
6. Immutability: Enable immutable vault backup on all Recovery Services Vaults and Backup Vaults to prevent admin-level deletion.
7. Monitoring and compliance: Deploy Azure Policy to enforce backup enablement (deployIfNotExists). Export backup reports to Log Analytics for SOC 2 audit evidence.
8. Cost justification: The GRS + immutability combination for Tier 0/1 is more expensive than LRS, but non-compliance penalties and downtime costs exceed the storage premium by orders of magnitude.

[!NOTE] Key insight: Immutable vault backup combined with auto-failover groups and LTR forms a three-layer defence: operational recovery (PITR), disaster recovery (failover group), and compliance retention (LTR + immutability). The exam tests whether you can layer these correctly without redundant spend.

Visual Explanations

BCDR Decision Tree

When an exam scenario describes a workload, use this decision tree to select the right BCDR mechanism:

Caption: This tree routes you from workload type to the recommended Azure BCDR service. Start at the top and follow the decision branches based on scenario requirements.

Backup Data Flow

Caption: Three parallel backup pipelines — VM snapshots flow to a Recovery Services Vault, SQL auto-backups feed PITR and LTR stores, and blob operational backups land in a Backup Vault. Each supports cross-region redundancy via GRS.

Recovery Services Vault vs Backup Vault

Caption: Use this table to pick the correct vault type based on the workload in the exam scenario.

Azure Site Recovery Architecture (TikZ)

Caption: Azure Site Recovery continuously replicates VM disks from the primary region to a cache storage account in the DR region. During failover, VMs are hydrated from the replicated disks (dashed boxes indicate standby VMs that only exist during failover).

Blob Data-Protection Stack

Caption: Each layer adds incremental protection. Versioning catches overwrites, soft delete catches deletions, PITR enables bulk rollback, immutability prevents tampering, and vaulted backup provides an isolated recovery copy in another region.

Common Mistakes

❌ Myth: Enabling Azure Site Recovery means you do not need Azure Backup. ✅ Reality: ASR provides disaster recovery (failover to another region) but does not give you point-in-time recovery or long-term retention. A ransomware-encrypted VM replicated by ASR is still encrypted in the DR region. You need Azure Backup for clean recovery points. Why it's tricky: Both "protect VMs" and "recover VMs," so candidates conflate them. ASR = DR (regional failover). Backup = operational recovery (point-in-time rollback).

❌ Myth: Configuring PITR automatically configures Long-Term Retention (LTR). ✅ Reality: PITR and LTR are independent features with separate configuration. PITR retention (up to 35 days) is set on the database; LTR is set via a retention policy on the logical server. Enabling one does not touch the other. Why it's tricky: Both involve "keeping backups longer," but they use different storage, different retention scopes, and different restore workflows.

❌ Myth: Vault storage redundancy (LRS/GRS) can be changed at any time. ✅ Reality: Once a backup item is registered in the vault, the redundancy type is locked. You must set GRS before the first backup. Changing later requires a new vault and data migration. Why it's tricky: Azure Portal lets you see the redundancy dropdown even after backups exist, giving the impression it is still editable—but saving the change will fail.

❌ Myth: Soft delete on blob storage and soft delete on a Recovery Services Vault are the same feature. ✅ Reality: They are completely separate. Blob soft delete protects blob objects in a storage account. Vault soft delete protects backup recovery points inside a Recovery Services Vault (default 14-day retention, always-on for VMs). Why it's tricky: The term "soft delete" appears in both contexts, and both retain deleted data for a configurable period—but they protect different resources in different services.

Practice Exercises

🟢 Easy — Contoso has a single VM running a departmental wiki. They need daily backups retained for 14 days. No cross-region requirement. Which vault redundancy should you choose and why?

▶💡 Hint

Consider the cheapest redundancy option that still meets the stated requirements. Cross-region is not needed.

▶✅ Solution

Choose LRS (Locally Redundant Storage). The requirements state no cross-region DR, so GRS/RA-GRS would add cost without benefit. LRS provides 3 copies within a single datacenter, which is sufficient for a non-critical wiki with 14-day retention.

🟡 Medium — Contoso's finance team runs an Azure SQL Database (General Purpose tier) that holds audit data subject to 7-year regulatory retention. The default PITR retention is 7 days. Design the backup strategy.

▶💡 Hint

PITR alone maxes out at 35 days. For multi-year retention, you need a different feature.

▶✅ Solution

1. Increase PITR retention to 35 days for operational recovery.
2. Enable Long-Term Retention (LTR) with a yearly policy retained for 7 years (Y=7, WeekOfYear=1).
3. LTR copies full backups to RA-GRS storage automatically.
4. Verify GRS is enabled on the underlying backup storage for cross-region durability.

PITR handles day-to-day recovery; LTR satisfies the 7-year audit requirement (Ch. 3, §3.1, p. 112).

🟡 Medium — Contoso wants to protect 50 TB of blob data in a storage account against ransomware. The data must be immutable for 1 year. Which combination of features should you enable?

▶💡 Hint

Think about which blob-level features prevent deletion/modification and which provide an isolated recovery copy.

▶✅ Solution

1. Enable blob versioning and soft delete (90-day retention) for operational protection.
2. Apply a time-based immutable storage policy with a 1-year retention period on the container.
3. Configure Azure Backup for Blobs (vaulted tier) in a GRS Backup Vault for an isolated, immutable copy.
4. The combination ensures that even if an attacker gains Storage Account Contributor access, they cannot delete or modify data within the retention window.

🔴 Hard — Contoso runs a 3-tier application (Web VMs, App VMs, Azure SQL DB) across East US. Requirements: RPO $< 5$ minutes, RTO $< 30$ minutes, and 90-day operational recovery. The application must survive a full regional outage. Design the end-to-end BCDR solution.

▶💡 Hint

You need separate mechanisms for compute DR and database DR. Consider how ASR and auto-failover groups complement each other.

▶✅ Solution

1. Compute: Enable Azure Site Recovery for Web and App VMs replicating to West US. Create a recovery plan with boot order: App VMs → Web VMs.
2. Database: Configure an auto-failover group for Azure SQL DB with the secondary in West US. Use asynchronous geo-replication (RPO $< 5$ seconds typical, $< 5$ minutes worst case).
3. Operational recovery: Enable Azure Backup for all VMs (GRS vault, daily snapshots, 90-day retention, CRR enabled). Set SQL PITR to 35 days.
4. Testing: Quarterly ASR test failovers; monthly failover-group failover drills.
5. Monitoring: Azure Monitor alerts on ASR replication lag, backup job failures, and failover group replication lag.

The auto-failover group handles the RPO requirement at the data layer; ASR handles compute failover within the RTO window; Azure Backup provides the 90-day rollback capability.

🔴 Hard — Contoso's CISO mandates that all backup data must be protected against deletion by a compromised Global Admin. Which Azure features satisfy this requirement across VMs, databases, and blob storage?

▶💡 Hint

Think about immutability at the vault level and the storage level, plus Azure RBAC separation.

▶✅ Solution

1. Recovery Services Vault: Enable immutable vault with a locked retention policy. Even a Backup Admin cannot delete recovery points before the policy expires.
2. Backup Vault: Enable immutability for blob and disk backup items.
3. Blob storage: Apply time-based immutable storage policies at the container level.
4. Multi-user authorization (MUA): Enable MUA on the vault so that critical operations (disable soft delete, reduce retention) require approval from a second identity backed by an Microsoft Entra Privileged Identity Management (PIM) role.
5. Azure Resource Lock: Apply a CanNotDelete lock on all vault resource groups to prevent accidental resource-group deletion.
6. Separation of duties: Ensure the backup admin role and the Global Admin role are held by different people; use PIM for just-in-time elevation.

Layering immutable vaults, MUA, resource locks, and PIM creates defence-in-depth that survives a single compromised admin account.

Summary & Concept Map

• RPO and RTO are the foundation of every BCDR design—classify workloads into tiers and assign targets before selecting services.
• Azure Backup (via Recovery Services Vault or Backup Vault) provides point-in-time operational recovery for VMs, databases, blobs, and file shares.
• Azure Site Recovery provides disaster recovery through continuous replication and orchestrated failover—complementary to, not a replacement for, backup.
• Database BCDR layers PITR (short-term), LTR (long-term), geo-restore (cross-region), and auto-failover groups (near-zero RPO) for defence-in-depth.
• Unstructured data protection combines soft delete, versioning, point-in-time restore, immutable storage, and Azure Backup for Blobs.
• Immutable backups and multi-user authorization are the last line of defence against ransomware and insider threats.
• Test your recovery plan—quarterly ASR test failovers, monthly failover-group drills, and annual full-DR exercises.

Connections & Next Steps

This topic brings together four learning objectives that form the BCDR pillar of the AZ-305 exam. The recommended reading order for deep dives:

1. LO 22 — Design BCDR for Azure and hybrid workloads: Start here for the foundational RPO/RTO framework, hybrid replication patterns, and vault redundancy decisions.
2. LO 23 — Design backup solutions for compute: Dive into VM backup policies, ASR recovery plans, and multi-VM consistency groups.
3. LO 24 — Design backup solutions for databases: Master PITR vs LTR, auto-failover groups, Hyperscale backup, and geo-restore mechanics.
4. LO 25 — Design backup solutions for unstructured data: Explore blob versioning, immutable storage, Azure Files backup, and storage account failover.

Cross-topic connections: BCDR intersects with Unit 2 (Data Storage) — the storage tier and redundancy choices made during data design directly affect backup cost and restore speed. It also connects to Unit 1, Topic 3 (Governance) — Azure Policy deployIfNotExists definitions can enforce backup enablement across subscriptions, and RBAC separation of duties is essential for immutable vault security.

The next topic in Unit 3 is High Availability, which complements BCDR by focusing on preventing outages rather than recovering from them.