gcp
Disaster recovery on Google Cloud is not one thing you buy; it is a spectrum you choose a point on, and the point is decided by two numbers you have to write down before anything else. How long can this workload be down, and how much data can it afford to lose. Everything else, which pattern you pick, how much it costs, how you test it, follows from those two numbers. Skip them and you will either overspend protecting things nobody cares about or discover the gap during the disaster.
RTO and RPO: the two numbers that decide everything
Recovery time objective (RTO) is the maximum acceptable time a workload can be down before it must be back. Recovery point objective (RPO) is the maximum acceptable data loss, measured as the gap between your last usable recovery point and the moment of failure. A one-hour RPO means you have accepted losing up to an hour of writes.
These two numbers pull in opposite directions from cost. A near-zero RTO and RPO demands continuous replication and a live second region, which is expensive. A generous RTO and RPO lets you get away with periodic backups, which is cheap. The job is to set them honestly per workload, because a business owner signing off on "four hours down, one hour of data loss" for an internal report is very different from the same numbers on a payments system.
The four DR patterns
Google Cloud's disaster recovery guidance lines up along a familiar spectrum. Each step down the table shortens your RTO and RPO and raises your cost.
| Pattern | RTO | RPO | Relative cost | Fit |
|---|---|---|---|---|
| Backup and restore | Hours to days | Hours | Lowest | Non-critical, tolerant workloads |
| Cold standby | Tens of minutes to hours | Minutes to hours | Low | Recovery matters, downtime tolerable |
| Warm standby | Minutes | Seconds to minutes | Medium | Important workloads with tight RTO |
| Hot / active-active | Near zero | Near zero | Highest | Revenue-critical, cannot be down |
Backup and restore keeps recovery data safe and rebuilds infrastructure on demand. Cold standby has the target infrastructure defined but switched off, ready to spin up. Warm standby keeps a scaled-down copy always running, so failover is a scale-up rather than a build. Hot standby, or active-active, runs a full second region taking live traffic, which overlaps directly with the patterns in the load balancing failover guide.
Getting the data layer right
Compute you can recreate; data you cannot. The data layer is where most DR plans succeed or quietly fail, and the rule is simple: the recovery copy must live in a different region from the thing it protects. A backup sitting in the same region as the outage is not a backup you can use during that outage.
- Cloud Storage in multi-region or dual-region configurations keeps critical objects durable across a region loss, cheaply, with no application changes.
- Cross-region backups for databases give you a recovery point outside the primary region.
- Cross-region replication for databases that support it shrinks RPO toward zero by streaming changes continuously instead of snapshotting.
For globally consistent data with automatic cross-region failover, Spanner's multi-region configurations remove the hardest part of DR, at a premium. The broader trade-offs sit in the multi-region architecture guide.
What DR cannot fix
Cross-region DR protects you from region-scoped disasters. It does nothing for a global-product failure, because there is no other region to recover into. The June 2025 Service Control outage reached multi-region deployments precisely because the failed layer was global. So DR planning is necessary but not sufficient; pair it with the graceful-degradation thinking in surviving Google Cloud outages.
Test it or it does not exist
An untested DR plan is a hypothesis. Run restore drills that actually rebuild from your backups, and failover game days that move traffic to the standby region, then measure the RTO and RPO you really achieve against the ones on paper. The gap is always instructive, and finding it during a drill is far cheaper than finding it during a disaster. Instrument the drills with the SLOs from the observability guide so the numbers are real, not eyeballed.
Recover the cost too
When the disaster was Google's SLA breach rather than your own mistake, the credits you are owed are part of recovery. Your incident timeline already has the impacted window; that is the evidence a claim needs. cloudslacredit.com covers how SLA credit recovery works, clouddowntime.com/data has the historical outage data to back it up, and Next Signal turns the evidence into a filed claim and support ticket so the money is not left on the table.