Business Continuity: Backup, DR & Migration

Table of Contents#

1. Business Continuity — RTO, RPO, and the Framework
2. Azure Backup — Recovery Services Vault
3. Backup Policies and Retention
4. Cross-Region Restore
5. Azure Business Continuity Center
6. Azure Site Recovery — Architecture
7. ASR Test Failover and Recovery Plans
8. ASR Reprotection and Failback
9. High Availability vs. Disaster Recovery
10. Designing for RTO/RPO — Standby Tiers
11. Azure Migrate — Discovery and Assessment
12. The Cloud Adoption Framework Migration Phases
13. Migration Strategies — the Five Rs
14. A Full Worked BC/DR Bootstrap for Meridian Freight
15. Part 14 CLI Cheat Sheet
16. Common Mistakes and Interview Traps
17. Worked Practice Problems
18. Summary and What's Next

Business Continuity — RTO, RPO, and the Framework#

Every backup and DR decision in this chapter comes down to two numbers, worth defining precisely before anything else: Recovery Time Objective (RTO) — how long can the business tolerate being down — and Recovery Point Objective (RPO) — how much data loss (measured in time) is acceptable.

Meridian Freight's rates-db (pricing data, changes slowly, tolerable to lose a few hours of updates) has a genuinely different RPO requirement than shipment-api's live order data (near-zero tolerable loss) — this chapter's design decisions follow directly from these two numbers being set deliberately per workload, not applied blanket.

Azure Backup — Recovery Services Vault#

az backup vault create --name rsv-meridian --resource-group rg-shipment-api-prod \
  --location eastus

az backup protection enable-for-vm --vault-name rsv-meridian --resource-group rg-shipment-api-prod \
  --vm vm-driver-portal-01 --policy-name DefaultPolicy

The Recovery Services vault is the container for backup data and policies — supporting VMs, SQL/SAP HANA on VMs, Azure Files, and (via a separate Backup vault) newer workload types.

Backup Policies and Retention#

az backup policy create --vault-name rsv-meridian --resource-group rg-shipment-api-prod \
  --name policy-daily-retain-90 --backup-management-type AzureIaasVM \
  --policy '{"schedulePolicy": {"scheduleRunFrequency": "Daily"}, "retentionPolicy": {"dailySchedule": {"retentionDuration": {"count": 90, "durationType": "Days"}}}}'

Worth stating precisely the current RPO reality for standard Azure Backup: the Standard policy's primary-region RPO is up to 24 hours, and replication to the secondary region can add up to another 12-36 hours in the worst case — a genuinely important number to confirm against a workload's actual RPO requirement before assuming Azure Backup alone satisfies it; a near-zero-RPO requirement (like shipment-api's live order data) needs a fundamentally different mechanism (synchronous replication, a failover group — Part 9) layered on top, not standard backup alone.

Cross-Region Restore#

az backup restore restore-disks --resource-group rg-shipment-api-prod \
  --vault-name rsv-meridian --container-name "<container>" --item-name vm-driver-portal-01 \
  --rp-name "<recovery-point>" --target-resource-group rg-driver-portal-dr \
  --use-secondary-region

A genuinely important prerequisite worth stating explicitly: cross-region restore ONLY works for a vault using GRS (or GZRS) replication — a vault configured with LRS has no secondary-region copy to restore from at all, directly connecting back to Part 8's storage redundancy discussion; the vault's own redundancy setting is a real, easy-to-overlook prerequisite decided at vault creation, not something fixable reactively during an actual regional outage. Enabling cross-region restore after the fact also takes up to 48 hours before it's actually usable — another reason this is a proactive, not reactive, configuration decision.

Azure Business Continuity Center#

az backup vault backup-status show --name rsv-meridian --resource-group rg-shipment-api-prod

Business Continuity Center provides a single, unified view across BOTH Azure Backup and Azure Site Recovery — genuinely useful for an organization with many workloads spread across both mechanisms, since it surfaces protection status, upcoming test failover schedules, and built-in alerts (unhealthy replication, failover failures, expiring agents) in one place rather than checking each vault and each ASR configuration separately. Alerts surfaced here route to the same Azure Monitor action groups (Part 13) already covering every other operational alert, keeping DR-specific alerting inside the same unified on-call path rather than a separate, easy-to-miss notification channel.

Azure Site Recovery — Architecture#

az site-recovery replication-policy create --resource-group rg-shipment-api-prod \
  --vault-name rsv-meridian --name policy-24h-rpo \
  --recovery-point-retention-in-hours 24

az site-recovery protection-container mapping create --resource-group rg-shipment-api-prod \
  --vault-name rsv-meridian --fabric-name eastus --protection-container-name pc-eastus \
  --target-protection-container pc-westus --policy-name policy-24h-rpo

Azure Site Recovery (ASR) replicates entire VMs (Azure-to-Azure, or on-premises-to-Azure) continuously, ready for a genuine regional-outage failover — a fundamentally different mechanism from Azure Backup's periodic snapshots, worth stating the distinction precisely: Backup answers "recover a point-in-time copy after data loss or corruption"; ASR answers "keep a continuously-replicated, ready-to-activate copy for a full site/region failure." A production-critical workload typically needs both, for different failure modes.

ASR Test Failover and Recovery Plans#

az site-recovery recovery-plan create --resource-group rg-shipment-api-prod --vault-name rsv-meridian \
  --name recovery-plan-shipment-api --primary-fabric-id eastus --recovery-fabric-id westus \
  --failover-deployment-model ResourceManager

A recovery plan sequences a multi-VM failover in the correct order (database tier before application tier, for instance) rather than failing over every VM simultaneously and hoping dependency order works out. Test failover runs this entire sequence into an ISOLATED, non-production network — genuinely essential to state explicitly: a test failover never impacts the actual production environment, making it safe to run as a REGULAR, scheduled DR drill rather than something attempted for the first time during an actual emergency.

From the Trenches: An organization configured Azure Site Recovery for its production fleet, confirmed replication health looked healthy in the portal, and considered DR "done." Eighteen months later, during an actual regional incident, the real failover revealed the recovery plan's VM startup order had never been updated after a database migration changed which VM was now the actual primary — the plan failed over the OLD primary first, in the wrong order, causing a longer outage than the DR investment was supposed to prevent. The corrective practice adopted afterward: a scheduled, quarterly test failover, treated as a real operational requirement rather than a one-time setup checkbox — replication health alone says nothing about whether the RECOVERY PLAN itself still reflects the current architecture.

ASR Reprotection and Failback#

az site-recovery protected-item create --resource-group rg-shipment-api-prod --vault-name rsv-meridian \
  --fabric-name westus --protection-container-name pc-westus --replicated-item-name vm-shipment-api-01 \
  --policy-name policy-24h-rpo

After a genuine failover, the failed-over VMs are now running in the secondary region — "reprotection" starts replicating them BACK toward the original primary region, so a subsequent "failback" can return to the original region once it's healthy again. This two-step reprotect-then-failback sequence, not a single "undo" operation, is worth knowing precisely rather than assuming failover is trivially reversible.

High Availability vs. Disaster Recovery#

A genuinely important conceptual distinction worth stating precisely, since the two are often conflated: High Availability (HA) protects against LOCAL failures (a VM crash, a zone outage) with automatic, fast failover WITHIN a region — Availability Zones (Part 3), SQL failover groups (Part 9). Disaster Recovery (DR) protects against a FULL REGIONAL failure, typically with a slower, often more manual failover to an entirely different region.

Designing for RTO/RPO — Standby Tiers#

Why matching the standby tier to the ACTUAL RTO/RPO requirement matters concretely, worth stating explicitly: over-provisioning a hot standby for a workload that could tolerate a cold-standby recovery wastes real, ongoing cost — under-provisioning a workload that genuinely needs hot standby risks a business-critical outage lasting far longer than acceptable. This decision should be made deliberately per workload, exactly the way this chapter's opening RTO/RPO framework recommends, not defaulted uniformly across every service.

Azure Migrate — Discovery and Assessment#

az migrate project create --name migrate-meridian --resource-group rg-shipment-api-prod

Azure Migrate performs agentless discovery of on-premises VMware/Hyper-V/physical servers, mapping application dependencies and producing right-sizing assessments — directly relevant to Meridian Freight's remaining legacy on-premises freight-routing servers, referenced since Part 1, whose eventual migration this chapter's tooling actually executes.

The Cloud Adoption Framework Migration Phases#

A genuinely important current practice worth stating explicitly: treat the assessment as a LIVING document, refreshed quarterly and cross-checked against Azure Advisor recommendations, rather than a one-time snapshot — an assessment done once at the very start of a multi-year migration goes stale as both the source environment and Azure's own service offerings change.

Migration Strategies — the Five Rs#

Why choosing the RIGHT strategy per workload — not defaulting to the same one for everything — matters concretely: Meridian Freight's legacy freight-routing servers are a rehost/replatform candidate (working, low-risk, not worth a full rewrite yet), while shipment-api itself has already been rearchitected throughout this series precisely because its growth justified that investment — the five strategies exist on a real spectrum of effort versus cloud-native benefit, and the right choice depends on each specific workload's value and risk profile, not a blanket organizational policy.

A Full Worked BC/DR Bootstrap for Meridian Freight#

# 1. Recovery Services vault with GRS (prerequisite for cross-region restore)
az backup vault create --name rsv-meridian --resource-group rg-shipment-api-prod

# 2. Backup policy matched to rates-db's actual RPO tolerance
az backup protection enable-for-vm --vault-name rsv-meridian --resource-group rg-shipment-api-prod \
  --vm vm-rates-db --policy-name policy-daily-retain-90

# 3. Site Recovery for shipment-api's hot-standby tier
az site-recovery replication-policy create --resource-group rg-shipment-api-prod \
  --vault-name rsv-meridian --name policy-24h-rpo

# 4. A recovery plan sequencing the multi-tier failover correctly
az site-recovery recovery-plan create --resource-group rg-shipment-api-prod --vault-name rsv-meridian \
  --name recovery-plan-shipment-api

# 5. Azure Migrate project for the remaining legacy on-premises servers
az migrate project create --name migrate-meridian --resource-group rg-shipment-api-prod

Part 14 CLI Cheat Sheet#

Common Mistakes and Interview Traps#

Worked Practice Problems#

Problem 1: Meridian Freight configures Azure Backup on its Recovery Services vault using the default Standard policy, believing this satisfies shipment-api's stated near-zero-data-loss requirement for live order data. During an actual VM failure, the team discovers up to 24 hours of order data since the last backup point is at risk of being lost. What was the design mistake?

Answer: The team applied Azure Backup's periodic, point-in-time backup mechanism to a workload with a near-zero RPO requirement, without recognizing that standard backup's primary-region RPO can be up to 24 hours — backup is designed to answer "recover a point-in-time copy after data loss," not to guarantee minimal ongoing data loss for a continuously changing dataset. For shipment-api's live order data, a fundamentally different mechanism is needed: synchronous or near-synchronous replication (a SQL failover group with automatic failover, Part 9) that keeps a continuously up-to-date secondary copy, with Azure Backup layered on top as a SEPARATE protection against a different failure mode (accidental deletion, corruption) rather than the sole DR mechanism for this specific near-zero-RPO requirement.

Problem 2: An organization's Azure Site Recovery setup shows healthy replication status in the portal continuously for eighteen months. During an actual regional failover, the recovery plan fails to bring services up correctly, because the VM startup sequence still reflects an architecture from before a significant database migration. What did "healthy replication status" fail to catch, and what practice would have caught it?

Answer: Replication health only confirms that DATA is being continuously copied to the secondary region — it says nothing about whether the RECOVERY PLAN'S sequencing logic still reflects the current architecture, since the plan and the replication mechanism are validated independently. A regular, scheduled test failover (run into an isolated network, safe to perform without affecting production) would have caught this specific gap by actually exercising the recovery plan's startup sequence against the CURRENT architecture, revealing the stale VM ordering well before an actual incident — exactly why test failovers need to be a recurring operational practice, not a one-time setup validation.

Summary and What's Next#

• Every backup/DR decision should trace back to an explicit RTO/RPO defined per workload — not a uniform policy applied blanket across genuinely different criticality levels.
• Azure Backup (point-in-time recovery) and Azure Site Recovery (continuous replication for regional failover) solve different failure modes — a production-critical workload typically needs both.
• Cross-region restore requires GRS/GZRS vault redundancy configured from the start — not fixable reactively during an actual regional outage, and takes up to 48 hours to become usable after enabling.
• Test failovers must be a recurring, scheduled practice — replication health alone says nothing about whether a recovery plan's sequencing still reflects the current architecture.
• High Availability and Disaster Recovery are genuinely distinct concerns — local, fast, automatic failover versus regional, slower, often more deliberate failover.
• Migration strategy (the Five Rs) should be chosen per workload based on actual value and risk profile, not defaulted uniformly — this series' own shipment-api rearchitecture versus the legacy servers' rehost/replatform path is a real, concrete example of that differentiation.

Continue to Part 15 (15-cicd-and-iac.md) for the CI/CD and Infrastructure as Code practices that actually deploy and evolve everything this series has built.