Azure / Advanced: secure and recoverable architecture / Lesson 15

Reliability objectives and disaster recovery

Translate business recovery needs into time, data-loss, dependency, and authority requirements. Evaluate a complete restoration path instead of treating replication or backup status as sufficient proof.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Distinguish availability objectives, RTO, and RPO.
Calculate a synthetic recovery path and data-loss interval.
Plan and verify dependency-complete recovery and failback.

Define acceptable harm before selecting a recovery pattern

Availability, recovery time objective, and recovery point objective answer different questions. An SLO defines a target for an observed service indicator over a stated population and window. RTO expresses the acceptable recovery duration for a defined disruption; RPO expresses the acceptable loss of recoverable data, commonly as a time interval. These are workload decisions, not automatically inherited from a service SLA or region pair. Include customer impact, manual alternatives, data consistency, and authority to declare a disaster. A technically available endpoint can still fail the business if it returns stale or incomplete records.

Recover the whole dependency graph

A document service may need compute, data, DNS, routing, identities, keys, configuration, telemetry, and operator access in the recovery location. A database replica alone does not recreate those dependencies. Choose cold, warm, or active recovery patterns from objectives and measured capability, while accounting for cost and complexity without promising a universal price. The JSON model lists a restoration order and validation gate; it is not a deployable runbook or evidence of a successful drill. Verify regional service support and data residency for every critical dependency, and consider what happens when the primary environment is unavailable during recovery.

json A dependency-complete recovery intention

{
  "model": "recovery-dependency-plan",
  "sequence": [
    "declare-and-authorize",
    "restore-or-promote-data",
    "start-compatible-compute",
    "verify-identity-network-and-keys",
    "validate-user-task",
    "steer-traffic"
  ],
  "gate": "no-traffic-before-integrity-and-access-validation"
}

Expected output

restored data alone is insufficient for complete service recovery

No restore, promotion, DNS change, failover, or cloud operation is performed. The sequence requires service-specific review.

Model the critical path and the recoverable point

The offline case assumes sequential detection, decision, restore, validation, and traffic-steering stages totaling fifty minutes against a sixty-minute RTO. It also assumes the last durable recoverable checkpoint is six minutes before the incident against a five-minute RPO, so the data-loss objective fails even though the time model passes. Parallel recovery stages would need a dependency-aware critical path rather than a simple sum. The values are hypothetical, not measured Azure recovery times. A real test must establish the recoverable consistency point and user-task completion, including whether queued or external effects were lost or duplicated.

python Offline RTO and RPO checks with different outcomes

stages_minutes = [10, 5, 20, 10, 5]
rto_target = 60
recoverable_lag_minutes = 6
rpo_target = 5
print(sum(stages_minutes), sum(stages_minutes) <= rto_target)
print(recoverable_lag_minutes, recoverable_lag_minutes <= rpo_target)

Expected output

50 True
6 False

The synthetic RTO passes and RPO fails. No Azure failover duration, replication lag, or restored record is observed.

Recovery evidence includes restoration, not just backup creation

Backups need appropriate retention, integrity, access, keys, and a tested restore procedure. Replication can copy corruption or deletion and may provide a different recoverable point from a retained backup. Review which service supports point-in-time recovery, cross-region restore, immutability, or other protections under the selected configuration; do not assume every option exists everywhere. Keep enough operational information to rebuild configuration without exposing secrets. Restore into an isolated environment for a future authorized test, verify data and permissions, then complete a representative application task. A successful backup job alone is not evidence that the business can recover.

Failover and failback are controlled business changes

Define activation criteria, approval, communication, traffic decisions, read/write ownership, and the procedure for returning to the preferred location. Two writable copies without a conflict strategy can create new damage. A failback may require resynchronization and compatibility checks rather than merely reversing DNS. Record actual recovery evidence, gaps, and lessons without claiming complete coverage of every disaster. This course performs no restore, failover, failback, backup query, or cloud command. Its planning and arithmetic remain separate from service-specific drills, which need authorized scope, protected synthetic data, and a clear stop/recovery procedure.

Common errors and fixes

Passing RTO arithmetic is claimed as passing every recovery goal

Why it happens: Time and recoverable data objectives are conflated.
How to fix it: Evaluate RTO, RPO, consistency, and task completion separately.
Prevent it next time: Keep each objective and its observed evidence in the report.

A backup success notification is treated as a restore drill

Why it happens: Creation evidence replaces recovery validation.
How to fix it: Verify a controlled restore and complete the dependent task.
Prevent it next time: Include keys, identities, metadata, and permissions.

Failback is reduced to reversing a route

Why it happens: Data divergence and write ownership are omitted.
How to fix it: Plan resynchronization, validation, and controlled traffic ownership.
Prevent it next time: Review split-brain and stale-data risks before either transition.

Check your understanding

1. The model recovers in fifty minutes but loses six minutes against a five-minute RPO. Is recovery accepted?

Show worked solution

The modeled RTO condition passes, but the RPO condition fails. Acceptance must consider both objectives and consistency, access, and complete user outcomes. Do not hide the failed data objective behind a fast endpoint recovery or a successful traffic change.

2. Why must identities and encryption keys be in a recovery plan?