Design business continuity solutions
Backup and Disaster-Recovery Architecture
CoreTranslate business recovery objectives into workload-specific backup, replication, failover, retention, and testing designs.
Aligned to the current AZ-305 study guide, skills measured as of April 17, 2026, verified August 25, 2026.
Why this matters
Recovery architecture must survive the failure being designed for and prove that data, dependencies, identities, and runbooks recover together.
Must Know
- Define the tolerated data-loss window, restoration time, and failure scope before selecting recovery services.
- Combine backup, replication, and high availability deliberately because each protects against different risks.
- Use workload-appropriate protection: Azure Backup for supported recovery points, Site Recovery for supported machine failover, and native database features for database continuity.
- Include networking, identity, DNS, application order, data consistency, and validation in every recovery plan.
Compare and Distinguish
- RPO limits acceptable data loss; RTO limits acceptable restoration time.
- Backup provides retained recovery points; replication reduces recovery time but can replicate corruption; high availability does not replace historical recovery.
- Azure Backup protects supported workloads; Site Recovery orchestrates replication and failover for supported machines; database-native features protect database workloads.
Scenario examples
- Scenario: Ransomware protection requires retained recovery points protected from deletion. Think: isolated vault controls, immutability, and restricted destructive operations.
- Scenario: A VM application needs regional failover within minutes. Think: Site Recovery plus tested dependency and recovery-plan design.
- Scenario: A database needs point-in-time restore and regional continuity. Think: combine service-native backup with the appropriate geo-failover feature.
Exam traps
- A successful backup job does not prove a successful application restore.
- Replication alone is not protection from logical corruption.
- Choosing a service before defining recovery objectives reverses the design process.
Key takeaways
- Define business impact, failure scope, RPO, and RTO first.
- Layer high availability, replication, and backup for different risks.
- Test recovery without disrupting production and close every dependency gap.
How it works
- An Azure Backup policy schedules protection and retention, the workload-specific agent or extension transfers backup data, and the vault stores recovery points under its access and redundancy configuration.
- Site Recovery continuously replicates supported machine changes to the recovery location; a failover operation creates or starts recovery resources, and a recovery plan can sequence groups and automation around application dependencies.
- Database-native continuity features create service-managed recovery points or replicas, but restoration or failover still requires the application to reconnect and validate data consistency.
Objects and administrative surfaces
- Failure scope can be item deletion, host, zone, region, malicious action, or broad platform dependency.
- Vault region, redundancy, immutability, soft delete, authorization, and cross-region restore affect survivability.
- Recovery plans must include network, identity, DNS, data consistency, application ordering, and validation.
When to use it
- Use Azure Backup for supported protected recovery points and point-in-time restoration.
- Use Site Recovery for supported machine replication and orchestrated failover to another site or region.
- Use database-native backups and geo-continuity features together when logical recovery and rapid regional failover are both required.
Security and governance implications
- Protect vaults and recovery points from casual deletion, restrict destructive roles, and align copies with residency and key requirements.
- Test recovery without granting broad standing access, and preserve evidence that restored identities and applications remain correctly authorized.
How to validate and revise the design
- If a recovery test fails, trace boot or database state, network routes, DNS, identities, secrets, dependency order, and client reconnect behavior.
- If objectives are missed, measure change lag, restore or failover time, validation duration, capacity, and the actual failure scope.
More detail
- Vault redundancy and cross-region restore must be chosen for the failure being addressed; a vault or recovery copy that shares the failed boundary cannot satisfy the intended regional recovery design.
- Restore granularity and consistency affect achievable RTO: recovering a machine is different from recovering one file, one database point in time, or a coordinated multi-tier application state.
- Use isolated test failovers and representative restores where supported, because replication health and successful backup jobs do not validate DNS, identity, boot order, application behavior, or recovery instructions.
Ready for the quiz?
- What are the required RPO, RTO, and failure scope before any recovery product is selected?
- Which threats require historical backup, replicated continuity, zone availability, or more than one of those controls?
- Have networking, identity, DNS, application order, validation, and rollback been included in the recovery plan?
Related objectives
- D3.1.S1 — Recommend a recovery solution for Azure and hybrid workloads that meets recovery objectives
- D3.1.S2 — Recommend a backup and recovery solution for compute
- D3.1.S3 — Recommend a backup and recovery solution for databases
- D3.1.S4 — Recommend a backup and recovery solution for unstructured data