Troubleshooting Business Continuity Issues
Business continuity on Azure rests on four measurable pillars: Recovery Point Objective (RPO, tolerable data loss), Recovery Time Objective (RTO, tolerable downtime), backup retention, and geo-redundancy. Understand which service protects which layer. Azure Backup uses Recovery Services vaults with policies (frequency, retention, instant restore); Azure Site Recovery (ASR) replicates VMs to a secondary region for orchestrated failover; storage redundancy (LRS, ZRS, GRS, GZRS, RA-GRS) protects data durability but is not a backup. SQL Database offers point-in-time restore, long-term retention, and auto-failover groups; Cosmos DB offers continuous backup or periodic modes.
Common traps: confusing RPO with RTO (RPO is about lost data, RTO about elapsed time); assuming GRS alone satisfies compliance backup requirements; forgetting that soft delete and immutable vaults affect whether a deleted backup can be recovered; overlooking that ASR requires a target region capacity and network mapping; and mixing up geo-redundant storage failover (customer-initiated, storage account) with regional service failover.
Worked rule of thumb: if the question states "we can lose at most 15 minutes of data but must be running within 1 hour," map 15 minutes to RPO and 1 hour to RTO. Choose a solution whose replication frequency is at or below the RPO and whose failover automation meets the RTO. Verify the backup policy's schedule matches the RPO before selecting retention options.
Also know Azure Backup reports, vault diagnostics, and the difference between backup job failures (agent, extension, snapshot, throttling) and restore failures (permissions, storage account firewall, cross-region restore disabled).