Backups & Redundancy
Exam guide§3.2
Two separate ideas the exam tests: backups (recover from a bad write/delete) and location redundancy (survive a zone or region failure).
Backups per database
| Product | Automated backups | Point-in-time recovery (PITR) |
|---|---|---|
| Cloud SQL | Yes, scheduled + on-demand | Yes (via binary/WAL logs) |
| Spanner | Backups + import/export | No PITR, but versioned retention |
| Firestore | Scheduled backups + export | PITR (last 7 days) |
| Bigtable | Table backups | No PITR |
| BigQuery | Automatic (time travel) | Time travel (7 days default) |
- Cloud SQL PITR requires automated backups AND binary logging enabled - restoring to a specific timestamp replays logs on top of the last backup, into a NEW instance.
- BigQuery time travel lets you query or restore a table as it was up to 7 days ago; no separate backup job needed.
A Cloud SQL restore (especially PITR) restores into a new instance, not over the running one. Plan to repoint your app. Deleting the instance also deletes its automated backups unless you exported them.
Redundancy: regional vs multi-region
- Zonal - one zone. A zone outage takes it down. (e.g. a single Compute Engine disk.)
- Regional - replicated across zones IN one region. Survives a zone failure. Cloud SQL HA and most databases default here.
- Multi-region - replicated across regions. Survives a whole-region failure. Higher cost/latency. Spanner multi-region, Firestore, and multi-region Cloud Storage buckets.
Cloud Storage location types
Low latency near compute, single-region apps→Region (e.g.
us-central1)Multi-zone in one regionDefined geo-redundancy + low latency→Dual-region (e.g.
nam4)Two specific regionsHighest availability, content served broadly→Multi-region (e.g.
US, EU)Across a large geographyA bucket's location is set at creation and can NEVER be changed. To "move" a bucket you create a new one in the target location and copy the objects over. Co-locate buckets with the compute that reads them to avoid egress costs and latency.