LEARN. PRACTICE. GROW.Concept and mechanism
Redundancy is a design characteristic; recovery is a capability requiring evidence. Two instances can share DNS, authentication, storage, or an unavailable team. Counting machines does not demonstrate independent failure modes. Describing concrete scenarios reveals what continues working when a dependency disappears. RTO is the recovery-time objective; RPO bounds data loss expressed in time. Both start from business needs and do not offset each other. If a rehearsal takes 72 minutes against a 60-minute RTO, that objective failed even when recovered data lags by only five minutes against a fifteen-minute RPO.
Guided application
A completed backup does not prove complete restoration. Recoverable assets may include data, configuration, application versions, and authorized access to necessary keys. Exercise in an appropriate context, measure time to usable service, and verify integrity and reconciliation. Do not stop timing merely because a database starts. After DNS, certificate, credential, or topology changes, compare the recovery environment for drift. Record observed outcomes, exercise limits, and assigned actions. A useful report distinguishes demonstrated capability from assumptions, allowing management to fund gaps and operations to understand remaining intervention dependencies.
Example: the database restores but the application cannot obtain its key. The rehearsal identifies a missing dependency; publishing the key in the report is not an acceptable repair.
Common pitfalls
Replicas treated as total isolation; green backup treated as restoration; good RPO treated as compensation for failed RTO.
Related topics: Services, dependencies, and evidence · Identity, connectivity, and protection · Operations, batch, and observability
Measure recovered service, usable data, and exercised dependencies.
Reference: REL13 Plan for disaster recovery · DR banking infrastructure professional assessment2026.10