Disaster Recovery in System Design

A failure removes the primary data store or an entire operating location. Starting an empty server does not restore the customer’s records, application configuration or external connections.

Disaster recovery plans how the workload returns to a useful state after a defined major disruption. Set recovery goals from business needs, identify the required data and dependencies, and verify the recovery procedure with evidence.

RTO, recovery time objective, is a target for returning the service after a defined disruption. RPO, recovery point objective, describes the acceptable data-loss window.

A backup taken an hour ago may restore quickly while losing later updates. A very recent copy may still take too long to restore. Set both goals and describe the failure scenario, data scope and service boundary.

Replication alone is not an independent historical backup. Accidental changes can propagate. Retained, appropriately protected copies and recovery procedures address different risks.

The demo starts with three records and a snapshot containing those three. Add a record, take another snapshot if desired, then simulate primary loss. Restore returns only the records in the latest snapshot.

The lab stores all state in local memory and models record counts, not elapsed recovery time or a real backup. Unsnapshotted records are lost under this snapshot-only model. Continuous logs, replicas and external effects are deliberately excluded.

Backup-and-restore can use less standing infrastructure but require more recovery work. A prepared standby can shorten some steps while adding ongoing cost and data synchronization work. Active deployments have their own coordination and failure complexity.

Choose the strategy from the failure scope and required outcomes. Another region is useful only if data, permissions, configuration and dependencies are available there under the intended incident.

Track recovery copies and their age, protect them from accidental deletion or compromised ordinary credentials, and test access during a real primary outage.

A runbook should specify who declares the incident, the authoritative recovery source, safe restoration steps, routing changes and validation. Include how new writes are controlled while recovering so incompatible owners do not diverge.

Verify important records, application behaviour, permissions and external dependencies before declaring service recovery. A database process starting successfully is only one checkpoint.

AWS recovery guidance connects strategies with objectives and testing. PostgreSQL backup documentation describes actual backup approaches. Sources checked 6 October 2026.

Routing traffic to another region is only one step. The destination needs appropriate data, compute capacity, keys, configuration, identity services and other dependencies. Compare replica lag with the recovery-point objective before claiming the target has current data.

Prevent two regions from accepting conflicting authoritative writes when the original region returns. Use the database’s supported promotion and fencing mechanism, and define a controlled failback procedure. An outage report does not prove the old writer has stopped.

Test whether backups, logs and credentials are usable if their usual region or account is unavailable. Respect data-location requirements for replicas and backups. Keep independent protected copies and validate restoration; an accidental deletion can replicate quickly. See replication and regional placement.

Set RTO and RPO for a stated disruption. Choose copies and infrastructure that can support both.

Practice the complete restore, including access, routing and data validation. Use measured results to improve the plan instead of assuming a backup file guarantees recovery.