# Disaster recovery, RPO and RTO > Disaster recovery is the plan for restoring a service and its data after a major failure, such as losing a region or corrupting a database. Recovery point objective (RPO) is the maximum acceptable data loss measured in time; recovery time objective (RTO) is the maximum acceptable time to restore service. Source: https://sysround.com/concepts/disaster-recovery Updated: 2026-11-05 ## How disaster recovery, rpo and rto works Start by defining the disaster and the recovery boundary. Losing one database node, losing an entire region, and discovering accidental deletion require different recovery paths. Specify which user operations must work again and whether degraded service counts as recovered. Set RPO and RTO from business requirements. An RPO of five minutes means the recovery plan must preserve data up to at least five minutes before the disruption. An RTO of 30 minutes means restoring the agreed service within 30 minutes of that disruption, not within 30 minutes of an operator starting recovery. Choose how to preserve data. Periodic snapshots plus archived transaction logs support point-in-time recovery; a remote replica can provide a more recent recovery point. Asynchronous replication does not guarantee a fixed RPO unless lag is bounded and enforced, while synchronous cross-region replication adds latency and can block writes during a partition. Choose how to restore compute and traffic. Restoring backups into new infrastructure usually takes longer than promoting a running standby. Recovery includes detection, decision-making, fencing the old writer, restoring or promoting data, starting dependencies, routing clients, and checking correctness. Keep a recovery path separate from live replication. Replicas can quickly copy accidental deletes or corruption, so retain versioned or immutable backups in a separate failure and access boundary. Recover related databases, objects, and queue positions to a compatible state rather than restoring each independently. Test the complete plan under realistic conditions. Measure the latest recoverable data and the time until usable service returns, including capacity limits and client reconnection. A healthy replica and a successful backup job are evidence, but neither proves that the recovery objectives are achievable. ## Worked example: Recovering a service after regional loss Suppose a metadata service has an RPO of one minute and an RTO of 15 minutes for regional loss. It keeps an asynchronous replica in another region, a warm application fleet, and immutable backups for corruption recovery. At 12:00, the primary region fails; the standby contains commits through 11:59:40, so the potential loss window is 20 seconds. Detection and approval take three minutes, fencing and promotion take two, and scaling, routing, and validation take six. Service returns after 11 minutes, meeting both targets for this incident. If replica lag had reached four minutes, the same fast promotion would miss the RPO. A separate restore drill must test the corruption scenario. ## Trade-offs - **Lower RPO versus write latency and availability.** Acknowledging writes only after durable replication to another region reduces regional data-loss risk but adds network latency and may stop writes when that region is unreachable. - **Lower RTO versus standby cost.** A running, adequately sized standby restores service faster than rebuilding infrastructure, but consumes capacity even when it serves no production traffic. - **Fast failover versus safe ownership.** Promoting a replacement before fencing the old writer can create split-brain and conflicting writes. - **Backup retention versus storage and recovery work.** Longer retention protects against late-discovered corruption, but costs more and may require substantial log replay and reconciliation. - **Automation versus operational risk.** Automated recovery reduces manual delay but needs reliable signals and safety checks to avoid promoting stale data or triggering unnecessary failovers. - **One recovery target versus different data needs.** A ledger, search index, and cache need different recovery guarantees, so applying the strictest target to everything can add cost without protecting more business value. ## When to use it in a system design interview - The interviewer asks what happens if an entire region or primary data store becomes unavailable. - The system acknowledges durable writes, and losing acknowledged data would violate a core requirement. - You need to choose between backup restoration, a warm standby, and an active multi-region design. - Accidental deletion, ransomware, or data corruption must be recoverable even if live replicas contain the same damage. - Recovery could overload storage, downstream services, or the surviving region. ## How to bring it up in the interview - Ask, “How much acknowledged data can we lose, and how long can this operation be unavailable?” State separate targets when critical writes and rebuildable views have different needs. - Name the failure scope before promising an RPO: synchronous replication across availability zones does not establish zero data loss after losing the whole region. - Walk through the recovery timeline, including detection, fencing, promotion or restore, dependency startup, client routing, and validation; interviewers often probe the steps hidden behind “fail over.” - Explain what happens when replication lag exceeds the RPO budget: stop acknowledging affected writes, use a stronger durability path, or explicitly accept that the target is at risk. - Defend the design with restore drills, measured recovery times, and recoverability checks; expect follow-ups about stale replicas, corrupt backups, insufficient standby capacity, and safe failback. ## Common mistakes - Reversing the terms: RPO measures acceptable data loss in time, while RTO measures acceptable service interruption. - Treating a backup interval as a guaranteed RPO without accounting for backup failures, transfer delays, and whether the backup can actually be restored. - Calling replication a substitute for backups even though deletes and corruption can propagate to every replica. - Counting only database promotion toward RTO while ignoring detection, traffic routing, dependencies, capacity, and correctness checks. - Claiming zero RPO without specifying which acknowledged writes survive which failures and when the system must refuse writes to preserve that guarantee. ## Interview questions where it comes up - [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): Durability guarantees require defining which acknowledged writes survive failures and how restore and repair affect recovery time and foreground traffic. - [Design a distributed message log like Kafka](https://sysround.com/questions/design-kafka): The acknowledgment policy and replica promotion rules determine potential data loss, while restoring partitions and consumer progress determines recovery time. - [Design a control plane for a distributed database](https://sysround.com/questions/design-database-control-plane): Safe database recovery requires durable orchestration, fenced promotion, and a plan for restoring operations when the control plane itself fails. ## FAQ ### What is the difference between RPO and RTO? RPO is how far back in time the recovered data may be compared with the disruption; RTO is how long restoring service may take. With a five-minute RPO and a one-hour RTO, you accept losing up to five minutes of recent data and taking up to one hour to restore the agreed service. ### Can RPO be zero? Yes, for a defined failure scope, if every acknowledged write is durably preserved outside that scope before success is returned. For regional loss, this generally requires synchronous durability in another region and refusing writes when that durability cannot be established. It does not automatically protect against logical corruption or deletion. ### How do backups and replication affect RPO and RTO? Replication can keep a recent copy ready for promotion, reducing data loss and recovery time, but asynchronous lag can widen the loss window. Backups provide historical recovery points that live replicas may no longer contain. Actual RPO and RTO depend on successful recovery tests, not just the configured backup schedule or replication mode. ## Related concepts - [Database replication](https://sysround.com/concepts/replication) - [Multi-region architecture](https://sysround.com/concepts/multi-region-architecture) - [Failover](https://sysround.com/concepts/failover) - [Split brain](https://sysround.com/concepts/split-brain) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.