RTO vs RPO

How long until I'm up vs how much data can I lose. The two numbers that drive every DR decision.

Overview

The two DR numbers

RTO and RPO are the two numbers every DR conversation orbits. They measure different things, are easy to confuse, and must be precise.

Definitions (Google Cloud DR documentation, verbatim)

RTO (Recovery Time Objective) — "How long after a disaster before I'm up and running."
RPO (Recovery Point Objective) — "How much data can I afford to lose in the event of a disaster."

Worked example

Hourly backup — 09:00 — Last good copy
Database destroyed — 09:30 — RPO: 30 minutes of writes lost
Replacement up, restored from 09:00, traffic redirected — 60 minutes later — RTO: 60 minutes

> [!IMPORTANT] From the user's perspective, the service is down for 60 minutes and any writes between 09:00 and 09:30 are gone. Two separate losses.

The numbers drive the architecture

RPO — More frequent replication, synchronous replication, streaming changelogs to a standby — Synchronous multi-region replication: every write durable in two regions before the client sees ACK. RTT cost on every write, plus consensus complexity
RTO — Warmer standby, faster failover, pre-staged infra, automated traffic shifting — Multi-site active/active with traffic already split

> [!WARNING] Neither can be 0 without spending real money. Both at 0 needs fully synchronous active/active multi-region, the most expensive DR posture.

Key concepts

RTO (Recovery Time Objective): "How long after a disaster before I'm up and running." (GCP) The max acceptable time from disaster to service restored.
RPO (Recovery Point Objective): "How much data can I afford to lose in the event of a disaster." (GCP) The max acceptable gap between the last good data and the disaster moment.
Synchronous replication: Every write durable in two regions before client ACK. RPO=0 but adds inter-region RTT to every write. Used for extremely tight RPO.
Asynchronous replication: Writes ACK from primary; replicate to secondary in background. Cheap but RPO = replication lag (seconds to minutes typical).
Streaming changelogs: CDC / WAL streaming to a remote store. Continuous replication with bounded lag — middle-ground RPO, cheaper than synchronous.

When to use it

Every DR conversation — set RTO and RPO before you debate strategy
Cost reviews — "we have RPO=0" is a budget claim; verify it matches what's actually paid for
Incident retrospectives — did the actual recovery match the stated RTO/RPO?
Database technology choice — sync vs async replication is an RPO decision

Interview questions

Define RTO and RPO and give an example.
How do you reduce RPO toward zero?
Can RTO=0 and RPO=0 both be achieved simultaneously?