disaster-recovery-planning

RTO and RPO are business decisions set by owners of revenue, customer trust, and regulatory exposure, not engineering defaults. Assign them per system tier, since a ledger and a cache have very different tolerances for downtime and data loss.

Backups are point-in-time copies that let you recover from logical disasters like corruption or accidental deletion. Replication continuously copies changes for fast failover but also propagates bad writes, so it cannot replace backups.

Pilot light keeps only the data layer running and starts the application tier on failover, giving RTO of tens of minutes to hours. Warm standby runs a scaled-down full stack, recovering in minutes at higher cost. Choose the cheapest pattern meeting your RTO/RPO.

Replication faithfully copies everything, including deletions and corruption, so a bad write instantly reaches every replica. You still need independent point-in-time backups to recover to a known-good state.

Test restores regularly into a clean, isolated environment and measure actual recovery time against the RTO. Higher tiers should also exercise full regional failover, with every gap found tracked to closure like a defect.

Active-active is wasteful for systems that tolerate an hour of downtime, since it carries the highest cost and forces hard distributed-data problems into normal operation. Reserve it for systems requiring near-zero RTO and RPO.