High Availability and Recovery for Cloud SQL and Storage

Google-managed backup and recovery for Cloud Storage (opens in a new tab) and Cloud SQL separates whole-instance restores from file-level copies. Cloud SQL provides incremental backups of an entire database instance, while Cloud Storage acts as the durable destination for exports and backup files that you manage. Data flows from the live instance or application to a backup copy stored separately from the instance, so deletion, corruption, or a regional outage does not remove the only copy.

1.1Cloud SQL Managed Backups and Backup Options

Cloud SQL managed backups are incremental copies that restore lost data to a Cloud SQL instance. Only the first backup is full-sized like the database, and each later backup contains only data that changed after the previous backup. All backups are encrypted by default with Google-managed keys or customer-managed encryption keys (CMEK). Every instance uses one backup option that controls where backups live:

Cloud SQL backups are used for three peer purposes: restore an instance to a previous state, create a new instance in a different region or zone for disaster recovery (DR), and create multiple instances for development, testing, and migration.

1.2Cloud SQL Backup Types and Restore Workflow

Cloud SQL backup types define when a copy is taken and how it is used for recovery. On-demand backups can be created at any time, even without automatic backups enabled, which is useful before a risky operation. Automated backups run on a scheduled cadence such as hourly, daily, weekly, or monthly during a backup window, and final backups are the last backups taken at the time of instance deletion.

The Cloud SQL restore workflow returns data to a new or existing instance, not to individual tables. A vaulted restore offers three destination choices: restore to a new instance with a new instance ID, overwrite an existing instance selected from a list, or overwrite the source instance. Overwriting the source instance replaces all current data, including previous point-in-time recovery logs, and the overwritten data cannot be recovered later. Point-in-time recovery (PITR) follows a stricter rule and always creates a new instance, so PITR cannot be performed to an existing instance. Backup and restore cannot upgrade a database version, so a backup can be restored only to the same database version as when it was taken.

1.3Cloud SQL Retention, Retained Backups, and Replicas

Cloud SQL retention rules control how long a backup remains available for restore. For automated backups, retention can range from 1 day to 10 years depending on the backup option and retention policy. For on-demand backups, standard backups are stored indefinitely until manually deleted, while enhanced on-demand backups use custom retention up to 10 years defined in the backup plan. When the oldest backup in an incremental chain is deleted, the next oldest backup grows to become the new full backup.

Retained backups are on-demand and automated backups that remain at the project level after an instance is deleted. Retained backups become independent of the instance and can be restored to a new or existing Cloud SQL instance at any time. Automated retained backups are deleted on a rolling basis, for example 7 days later if retention was set to 7 days, while standard on-demand retained backups remain until manually deleted or the project is deleted. Backups are maintained only with the primary instance, so replica instances have no separate backups, and a promoted replica needs its own backup configuration. Cloud SQL also performs background integrity checks by restoring a sampling of backups in an offline process.

1.4Cloud Storage Protection, Exports, and Centralized Services

Cloud Storage protection keeps objects recoverable from deletion, overwrites, and ransomware while supporting long-term retention. A common pattern is a scheduled task that transfers data to Cloud Storage, or a database export uploaded to Cloud Storage where you manage the lifecycle. For infrequently accessed backup data, older copies can move to Nearline, Coldline, and Archive storage classes, which have lower storage cost but add retrieval costs and minimum storage durations.

Protection against deletion in Cloud Storage uses layered bucket-level and object-level controls:

• Object holds: Place metadata flags on individual objects to prevent deletion or overwriting.
• Soft delete: Retains recently deleted objects and buckets for a set period, enabled by default with a seven day retention period.
• Object Versioning: Archives an overwritten or deleted live object as a noncurrent version that remains accessible until explicitly removed.
• Bucket Lock: Defines a per-bucket retention policy that retains all objects for a minimum duration and cannot be reduced or removed.
• Object Retention Lock: Defines per-object retention with an immutable retain-until date, so the object cannot be deleted or replaced until expiry.

Cloud SQL backups and Cloud Storage exports protect against different scenarios. Choose a Cloud SQL backup when the goal is to restore the whole instance disk, clone for DR in another region or zone, or recover quickly from corruption. Choose a Cloud Storage export when the goal is to keep a copy after instance deletion, move only a single database or table, or retain data in a chosen storage class. Backup and DR Service centralizes protection at scale by storing Persistent Disk snapshots from Compute Engine virtual machines (VMs) in Cloud Storage buckets with monitoring, auditing, and threat insights. Storage Transfer Service migrates online data between Cloud Storage, Amazon S3, and on-premises storage, while Transfer Appliance ships very large offline datasets on physical appliances to Cloud Storage.

Replication strategies in Google Cloud copy data to extra locations so one zone or region failure does not cause loss or downtime, which supports high availability and disaster recovery (opens in a new tab). Cloud Storage uses bucket location types and asynchronous copying to balance durability, availability, and recovery speed, while Cloud SQL uses read replicas, standby instances, and cross-region copies for performance and reliability. The choice affects how fast the system recovers and how much data could be at risk during an outage.

2.1Availability and Durability in Cloud Storage

Availability and durability in Cloud Storage protect against different problems. Availability is the ability to access data immediately when requested, and monthly availability depends on both the storage class and the location type of the bucket. Durability is long-term protection that keeps data intact and uncorrupted, and Cloud Storage is designed for at least 99.999999999% (11 9's) annual durability for all storage classes and location types.

Cloud Storage achieves durability by using erasure coding and storing pieces of data redundantly across multiple devices. A write is confirmed as successful only after the data has been stored redundantly, and checksums are stored and regularly rechecked to detect corruption in transit and at rest. If corruption is found, Cloud Storage automatically repairs it using the redundant data.

2.2Regional, Dual-Region, and Multi-Region Buckets

Bucket location type in Cloud Storage controls where redundant copies live and what kind of outage the bucket can survive. Cloud Storage uses an active-active design based on a single bucket, so there is no primary and secondary bucket and no manual failover. Cloud Storage tracks the current state of the bucket and transparently serves objects from an available region, which is why dual-region and multi-region buckets are designed for a recovery time objective (RTO) of zero.

Locally redundant data, such as data in a zonal bucket, still provides 11 9's durability against hardware failures but can become unavailable or be lost during a zone failure. Choose zonal or regional storage when data can be replaced, when low latency in one region matters most, or when lower cost matters more than surviving a regional outage.

2.3Default Versus Turbo Replication Timing

Default cross-region replication in Cloud Storage is the asynchronous process that copies newly written objects to the second geographic location. A write to a dual-region or multi-region bucket is first confirmed after redundant storage in one initial region across at least two zones, the same as a regional write. Data then flows asynchronously from that initial region to the other region to complete protection across regions.

Default replication targets redundancy for 99.9% of newly written objects within one hour and 100% within 12 hours, where new writes include uploads, rewrites, copies, and compositions. Turbo replication is a premium option for dual-region buckets that is designed to replicate 100% of newly written objects to both regions within a recovery point objective (RPO) of 15 minutes, regardless of object size. Turbo replication has strict limits: it works only for dual-region buckets, it cannot be managed through the XML API, it can take up to 10 seconds to apply after it is enabled, and writes that began before it was enabled continue at the default rate.

2.4Read Replicas, High-Availability Standby, and Cross-Region Replicas

Replication purposes in Google Cloud separate performance work from reliability work. Cloud SQL instance replication can spread read traffic to lower latency or keep a standby copy ready to limit downtime and data loss. Choosing the wrong purpose leads to the wrong design, such as using a read replica when automatic failover is needed.

A Cloud SQL for MySQL read replica serves read queries by copying changes in order: the primary records data-changing statements in its binary log, the replica receives them into its relay log, and then the replica applies them. An HA configuration keeps a synchronized standby in the same region for automatic failover, but adding HA to an existing primary might require a reboot. A cross-region replica can be combined with HA, so HA protects against zone failure while the cross-region copy protects against loss of an entire region.

2.5When Cross-Bucket Replication Makes Sense

Cross-bucket replication in Cloud Storage asynchronously copies data from a source bucket to an independent destination bucket in a different location. This option covers needs not met by built-in dual-region or multi-region locations, such as redundancy between a region pair that is not offered as a dual-region. To gain that coverage, a team can create a separate bucket for each region and keep them in sync with cross-bucket replication or with event-driven transfers from Storage Transfer Service.

This approach adds flexibility for custom geography, compliance, or migration goals, but it requires managing two independent buckets instead of one active-active bucket. Replication is most valuable when downtime or loss carries high business impact, and less valuable when data is replaceable or recovery within one region is enough.

Storage location types define the geographic scope where data is stored and how well that data survives zone or region failures. Cloud Storage (opens in a new tab) buckets and Cloud SQL instances use zones, regions, dual-regions, and multi-regions to balance latency, availability, and disaster recovery. A narrow scope keeps data close to applications but is more vulnerable to outages, while a wider scope spreads copies across more failure domains.

3.1Primary and Secondary Locations for Failover and Restore

Primary and secondary locations work together to keep data available during outages. The primary location is where reads and writes are served, such as a Cloud Storage bucket or Cloud SQL instance in a zone or region. The secondary location is a different zone or region that holds a standby copy or backup, so service can fail over or be restored after a zone or region outage.

Data flows from the primary copy to the secondary copy through synchronous replication for fast failover or through backups for later restore. After a zone failure, traffic shifts to the standby in another zone, and after a region failure, the database is restored in a different region from the secondary backup. The live Cloud SQL instance always uses a regional location, while multi-regional locations are used only for Cloud SQL backups.

3.2Zones and Regions as Failure Domains in Google Cloud

Zones and regions in Google Cloud are failure domains that can fail independently of each other. A region is an independent geographic area, such as London or Tokyo, that contains multiple zones. A zone is a sub-location inside a region, such as us-central1-a inside us-central1, and zones are designed so a failure in one zone usually does not affect the other zones in the same region.

Zones have high-bandwidth, low-latency connections to other zones in the same region. A zonal failure defines the expected boundary of impact, so a zonal resource in the affected zone may become unavailable while the same type of resource in another zone keeps running. When data is distributed redundantly across zones or regions, the combined deployment stays available even if one failure domain goes offline.

3.3High Availability Protection for Cloud SQL Within a Region

High availability protection for Cloud SQL keeps a synchronized secondary copy in a different zone of the same region for automatic failover. The deployment includes a primary instance and a standby instance in separate zones, using Hyperdisk Balanced High Availability volumes. Client writes flow first to the primary database and then synchronously to the standby database, so both zones hold the same data.

If the zone hosting the primary fails, the Cloud SQL service fails over automatically to the standby without waiting for a backup restore. To protect applications that use zonal resources, data and compute must be distributed across multiple zones or regions. In Cloud SQL, this means enabling high availability so the primary replicates synchronously to the standby with automatic failover.

3.4Choosing Location Scope for Zone and Region Survival

Choosing location scope means matching the storage footprint to the failure that must be survived. A single-zone primary is appropriate only when downtime during a zone failure is acceptable or when replication is managed separately. A regional primary with a cross-zone standby protects against zone failure with automatic failover, while a dual-region or multi-region bucket or a multi-regional backup protects against region failure with cross-region restore.

Cloud SQL supports three multi-regional backup locations: us for data centers in the United States, eu for data centers in the European Union, and asia for data centers in Asia. When a Cloud SQL instance is created, its region is where the instance and its data are stored, and that region cannot be changed later. Choosing the same region for Cloud SQL, Compute Engine, and other services reduces latency and keeps related systems together.

Key Facts

• Cloud SQL backups are incremental and encrypted by default, with standard backups stored in the same project as the instance and enhanced backups stored in a centralized backup management project using the Backup and DR Service.
• Point-in-time recovery in Cloud SQL always creates a new instance, while a standard restore can target a new instance or overwrite an existing instance.
• Cloud Storage enables soft delete by default with a seven day retention period and is designed for 11 9's annual durability using erasure coding and regularly rechecked checksums.
• Default cross-region replication targets 99.9% of new objects within one hour and 100% within 12 hours, while turbo replication for dual-region buckets targets 100% within a 15-minute RPO.
• The live Cloud SQL instance uses a regional location that cannot be changed after creation, while Cloud SQL backups can use multi-regional locations us, eu, and asia, and high availability replicates synchronously to a standby in another zone for automatic failover.