Cloud SQL Backups, PITR, and High Availability: What to Enable for Production

What each mechanism actually does

Before getting into configuration, here is the plain-English version of each tool:

• Automated backup: a daily snapshot of your entire database. If something goes badly wrong, you can restore to the state it was in at the last backup.

• On-demand backup: a manual snapshot you trigger yourself. Useful before risky operations like schema changes or bulk updates. Persists indefinitely until you delete it.

• Point-in-time recovery (PITR): recovery to any specific second within the log retention window. Not just “yesterday’s backup” but “yesterday at 14:27:43, before that migration ran.”

• High availability (HA): a second copy of your instance in a different availability zone, kept in sync with every write to the primary. If the primary zone fails, Cloud SQL promotes the standby automatically. The standby is never directly accessible; it exists only to take over.

• Read replica: a separate Cloud SQL instance that receives changes asynchronously from the primary. You can query it for reads. It does not fail over automatically if the primary fails.

What this page helps you decide

• Whether automated backups alone are enough for your workload
• When PITR is worth enabling, and what MySQL requires that PostgreSQL does not
• When high availability justifies the extra cost
• Why read replicas are not a substitute for HA, and what happens if you treat them as one
• What a sensible production Cloud SQL setup looks like before go-live

How Cloud SQL recovery works end to end

These mechanisms form a layered recovery model, not four separate unrelated settings. Here is how they fit together.

Every day, Cloud SQL takes a full backup of your instance and stores it in Cloud Storage, replicated across regions for durability. That is your baseline recovery point. By default you keep seven of these; you can increase the count up to 365.

Between full backups, Cloud SQL can continuously archive logs: binary logs for MySQL, WAL (write-ahead log) for PostgreSQL. These logs fill the gap between backup snapshots and give you PITR. When you trigger a point-in-time restore, Cloud SQL takes the nearest full backup and replays the captured logs up to your chosen timestamp. The result is a new Cloud SQL instance at that exact state.

High availability is separate from both. It does not change how backups or PITR work. It provisions a standby instance in a different zone within the same region and keeps it synchronised in real time. When the primary zone fails, Cloud SQL detects this automatically and promotes the standby. Your application reconnects to the same IP address; Cloud SQL updates the DNS record behind the scenes.

Read replicas sit outside this recovery stack entirely. They are useful for distributing read traffic across multiple instances, but they use asynchronous replication and do not provide automatic failover. For a broader view of availability patterns across GCP services, see the guide on designing highly available systems on GCP.

Automated backups

Cloud SQL performs one automated full backup per day during a configurable backup window. Backups are stored in Cloud Storage and replicated across regions for durability. Schedule the window during a low-traffic period to minimise any performance impact.

# Enable backups and set the backup window at instance creation
gcloud sql instances create my-db-instance \
  --database-version=POSTGRES_15 \
  --region=europe-west2 \
  --tier=db-n1-standard-2 \
  --backup-start-time=02:00 \
  --retained-backups-count=14

# Update backup settings on an existing instance
gcloud sql instances patch my-db-instance \
  --backup-start-time=02:00 \
  --retained-backups-count=14

# List available backups
gcloud sql backups list --instance=my-db-instance

For PostgreSQL instances, enabling backups also automatically enables WAL archiving, which is required for PITR. For MySQL, PITR requires an additional flag covered in the next section.

On-demand backups

You can take a backup at any time. On-demand backups are not affected by the retained-backups-count limit; they persist until you delete them manually, which makes them useful as long-lived checkpoints.

# Create an on-demand backup immediately
gcloud sql backups create --instance=my-db-instance

# Describe a specific backup to confirm it succeeded
gcloud sql backups describe BACKUP_ID --instance=my-db-instance

# Delete a backup when it is no longer needed
gcloud sql backups delete BACKUP_ID --instance=my-db-instance

Point-in-time recovery (PITR)

PITR lets you recover your database to any second within the log retention window. This is the right tool when the damage was not an infrastructure failure but a logical one: someone ran DELETE FROM orders WHERE status = ‘pending’ at the wrong time, or a migration introduced corrupted data and you need to rewind to before it ran.

The behaviour differs between database engines:

• MySQL: PITR requires binary logging, which must be explicitly enabled at instance creation with —enable-bin-log. The logs only exist from the moment it is turned on; you cannot enable it retroactively and recover historical data. See the MySQL on Cloud SQL guide for more on binary logging and replica configuration.

• PostgreSQL: WAL archiving is enabled automatically whenever backups are turned on. No additional flag is needed.

# MySQL: create an instance with binary logging enabled for PITR
gcloud sql instances create my-mysql-instance \
  --database-version=MYSQL_8_0 \
  --region=europe-west2 \
  --tier=db-n1-standard-2 \
  --enable-bin-log \
  --backup-start-time=02:00

# Restore to a specific point in time (creates a new instance, not an overwrite)
gcloud sql instances clone my-db-instance my-db-restored \
  --point-in-time=2026-03-07T14:30:00.000Z

PITR always creates a new Cloud SQL instance rather than overwriting the existing one. This is intentional. During incident response, you can restore and verify the recovered data while the production instance stays accessible. Once you have confirmed the state looks correct, update your application’s connection string to point at the restored instance, or export and re-import specific tables back into the primary.

High availability in Cloud SQL

A Cloud SQL high-availability instance consists of a primary in one zone and a standby in a different zone within the same region. Every write to the primary is synchronously replicated to the standby before being acknowledged. The standby is always current, but this adds a small amount of write latency compared to a single-zone instance.

If the primary zone becomes unavailable, Cloud SQL detects this automatically and promotes the standby. Failover typically completes within 60 seconds. Your application connects to the same IP address; Cloud SQL updates the DNS record behind the scenes. The former standby becomes the new primary, and Cloud SQL provisions a replacement standby in another zone.

The standby is not accessible for reads. It does not serve queries. It exists solely to become the new primary during a zone failure. If you need to distribute read load across instances, that is what read replicas are for, and they are independent of HA.

Cost is roughly double that of a single-zone instance because you are running two instances (primary plus standby) with duplicated compute and storage. For workloads where zone downtime is unacceptable, that cost is easy to justify. For internal tools or non-critical databases, ZONAL is often fine.

# Create a high-availability (regional) instance
gcloud sql instances create my-ha-instance \
  --database-version=POSTGRES_15 \
  --region=europe-west2 \
  --tier=db-n1-standard-2 \
  --availability-type=REGIONAL \
  --backup-start-time=02:00

# Enable HA on an existing instance (requires a brief restart)
gcloud sql instances patch my-db-instance \
  --availability-type=REGIONAL

# Trigger a manual failover to test the behaviour
gcloud sql instances failover my-ha-instance

Restoring from a backup

# Restore a backup to a different instance (safer for investigation)
gcloud sql backups restore BACKUP_ID \
  --restore-instance=my-db-restored \
  --backup-instance=my-db-instance

# Restore a backup to the same instance (overwrites current data immediately)
gcloud sql backups restore BACKUP_ID \
  --restore-instance=my-db-instance

Backups, PITR, HA, and read replicas compared

These four features are frequently confused because they all relate to resilience. Here is a direct comparison by what each one actually does.

The key distinction: HA and read replicas address availability; backups and PITR address recoverability. A resilient production database uses all of them. For a wider view of recovery architecture in GCP, see the disaster recovery strategies guide.

When to use each option

The right configuration depends on what level of downtime and data loss your workload can tolerate. Here are four common scenarios:

• Small internal tool or development environment: automated backups with the default 7-day retention are usually sufficient. ZONAL availability is fine. For PostgreSQL, PITR is free to enable since it is automatic when backups are on. Skip HA unless the team depends on this database heavily during the working day.

• Production app with moderate uptime requirements: enable backups with 14 to 30 day retention, enable PITR (add —enable-bin-log at creation for MySQL), and consider HA. If a few minutes of downtime during a zone failure is covered by your SLA, ZONAL may still be acceptable, but be explicit about that decision.

• Business-critical production database: enable HA, enable PITR, set backup retention to 30 days or more, take on-demand backups before major operations, and test your failover and restore processes before go-live. Set up alerts in Cloud Monitoring for backup failures and replication lag.

• Read-heavy reporting workload: add one or more read replicas to offload analytics queries from the primary. Keep HA enabled on the primary if it is production-facing. Read replicas do not provide failover; they are for scaling, not resilience.

If you are still deciding whether Cloud SQL is the right choice for your use case, the choosing the right storage service guide covers that decision across Cloud SQL, Firestore, Bigtable, and others.

Production checklist for Cloud SQL resilience

Before taking a Cloud SQL instance to production, work through this list. Most of these settings cannot be changed retroactively without downtime or data risk:

• Automated backups are enabled with a window during off-peak hours
• Backup retention count is set to 14 or more (review what your recovery window requires)
• PITR is confirmed: for MySQL, verify —enable-bin-log was set at creation; for PostgreSQL, confirm backups are on
• High availability is set to REGIONAL if zone downtime is unacceptable for this workload
• A manual failover test has been run with gcloud sql instances failover to confirm the behaviour
• A backup restore has been tested on a non-production instance to confirm the process works end to end
• The team knows to take an on-demand backup before running migrations or bulk operations
• Alerts are configured in Cloud Monitoring for backup failures and replication lag
• Connections to the instance are secured via the Auth Proxy or private IP (see connecting to Cloud SQL securely)