Primary and Secondary Storage Locations for Redundancy

Aligning storage locations with redundancy requirements means placing live data and backup copies so they survive the failures you plan for. The primary location is where reads and writes are served, such as a Cloud Storage (opens in a new tab) bucket or Cloud SQL (opens in a new tab) 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.

1.1Primary and Secondary Locations for Failover and Restore

Primary and secondary locations work together to keep data available during outages. The primary location serves application traffic every day, while the secondary location holds a synchronized standby or a backup copy in a separate failure domain. 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.

1.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. When data is distributed redundantly across zones or regions, the combined deployment stays available even if one failure domain goes offline.

1.3High Availability Protection for Cloud SQL Within a Region

High availability protection for Cloud SQL (opens in a new tab) 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.

1.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.

The table shows that wider scope survives larger failures but still needs careful planning. Zonal data depends on extra copies elsewhere, regional data depends on copies in another region, and multi-region data depends on safe configuration because one change can affect all geographies.

GCP 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 (opens in a new tab) instances both use these location types 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.

2.1Zones as Single-Zone Failure Boundaries

Zones are sub-locations inside a region where zonal resources run, such as Cloud SQL instances, Compute Engine (opens in a new tab) virtual machines, and Hyperdisk volumes. A zone name combines its region with a letter, for example us-central1-a is zone a in region us-central1. Zones have high-bandwidth, low-latency connections to other zones in the same region and are designed so a failure in one zone usually does not affect the others. 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.

Zonal resources have low resilience on their own and must be protected by distribution. To protect applications that use zonal resources, data and compute must be distributed or replicated across multiple zones or regions. In Cloud SQL, this means configuring high availability so the primary instance replicates synchronously to a standby instance in a separate zone, with automatic failover if the primary zone fails.

2.2Regions as Multi-Zone Deployments

Regions are independent geographic areas made up of zones, such as europe-west2 in London or asia-northeast1 in Tokyo. Regional resources are deployed redundantly across multiple zones within one region, so regional resources include regional Cloud Storage buckets, regional Spanner instances, regional managed instance groups, regional Google Kubernetes Engine clusters, and Filestore Enterprise instances. Because copies exist in more than one zone, regional resources survive a single-zone incident. A region-wide outage caused by a natural disaster or large infrastructure failure can still affect some or all regional resources in that region.

A region is the primary location choice for Cloud SQL and for latency-sensitive storage. 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. Choose a regional location when the priority is low latency for users in one geography plus protection against zonal failure.

2.3Dual-Region and Multi-Region Distribution Across Regions

Dual-region and multi-region distribution spreads data across specific regions rather than zones in one region. Cloud Storage offers dual-region and multi-region buckets as multi-region resources, alongside multi-region Spanner instances, multi-region Bigtable instances, and multi-region key rings. These resources remain available when a specific zone or a specific region has an incident, and they are affected only when multiple regions in their footprint fail at the same time. This wider distribution gives high resilience compared to zonal resources with low resilience and regional resources with medium resilience.

Multi-region locations are especially important as secondary and backup locations for disaster recovery. In Cloud SQL, the live instance always uses a regional location, while multi-regional locations are used only for backups. 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. Choose a dual-region or multi-region bucket or backup location when data must stay readable after a regional outage or when backups must be restorable in a different region.

2.4How Primary and Backup Copies Flow Across Scopes

How primary and backup copies flow across scopes explains the path from live data to recoverable data. Data flows from a primary copy in a zone or region to secondary copies in other zones or regions through synchronous replication for high availability and through backups for disaster recovery. An example architecture combines all three scopes: a global load balancer sends traffic to compute in multiple zones, Cloud SQL replicates synchronously from a primary zone to a standby zone, and automated Cloud SQL backups are stored in a multi-region Cloud Storage bucket for restore in another region.

The table shows a ladder of increasing resilience with increasing geographic spread. Moving from zonal to regional to multi-region adds more independent copies, so larger outages are needed to cause data loss.

Storage location tradeoffs in Google Cloud describe what each scope gains in protection and what it gives up in latency, cost, and complexity. A zone is a deployment area inside a region, a region is an independent geographic area made of zones, and dual-region and multi-region locations spread data across regions. Primary data and secondary copies use different location types to balance latency, availability, durability, and cost.

3.1Benefits and Limits of Zonal Storage

Zonal storage lives in a single zone and can only be used in that zone. Examples include Cloud SQL (opens in a new tab) instances, Google Cloud Hyperdisk volumes, Filestore Basic and Zonal instances, and disks attached to Compute Engine (opens in a new tab) virtual machines (VMs). A disk can only be attached to a computer in the same zone, which creates a strict boundary between the storage and computers outside that zone.

The advantage of zonal storage is proximity with fast access. Zones have high-bandwidth, low-latency connections to other zones in the same region, and keeping a database close to Compute Engine VMs or applications in the same zone reduces latency. The limitation is low resilience, because a failure in a zone might affect the zonal resources provisioned within that zone, although zones are designed so failure in one zone usually does not affect other zones. Because a zone defines the expected boundary for a failure, zonal data must be protected by distributing or replicating resources across multiple zones or regions, such as choosing a specific zone like us-central1-a or choosing Any to let Google Cloud assign a zone and then enabling high availability (HA).

3.2Benefits and Limits of Regional Storage

Regional storage is deployed redundantly across multiple zones within one region. Examples include Cloud Storage regional buckets, Hyperdisk Balanced High Availability volumes, Filestore Enterprise instances, virtual private cloud (VPC) subnets, and Regional Spanner instances. Data flows redundantly across the zones in the region, so the resource does not depend on any single zone.

The advantage of regional storage is medium resilience with low latency inside the region. Regional resources are resilient to incidents in a specific zone, and placing Cloud SQL data in the same region as Compute Engine instances and other services reduces latency and increases availability. The limitation is that a region outage can affect some or all regional resources in that region, whether from natural disasters or large-scale infrastructure failures. For Cloud SQL, the primary instance and its data are stored in a regional location chosen at creation, the location cannot be changed after creation, and survival of a region-level event requires a secondary copy in another region.

3.3Benefits and Limits of Dual-Region and Multi-Region Storage

Dual-region and multi-region storage is distributed across specific regions for higher durability. Examples include Cloud Storage dual-region and multi-region buckets, multi-region Spanner instances, multi-cluster Bigtable instances, and multi-region key rings in Cloud Key Management Service. For Cloud SQL, multi-regional locations named asia, eu, and us are used only for backups, and automatic backups can be stored in a multi-region Cloud Storage bucket.

The advantage of dual-region and multi-region storage is high resilience for secondary copies. Multi-region resources are resilient to incidents in specific regions and zones, so they work well for disaster recovery. In a typical design, client requests flow to a backend in one region, the application writes to a Cloud SQL primary database, the primary replicates synchronously to a standby database in a different zone, and the database is backed up automatically to a multi-region bucket. The limitations are scope and remaining risk, because an outage that spans multiple regions can still affect multi-region resources in those regions, and spreading data across regions adds operational and cost tradeoffs compared with keeping active reads and writes in one region for latency and network cost.

3.4Matching Primary and Secondary Storage to Redundancy Goals

Matching primary and secondary storage to redundancy goals means using each location type for the job it does best. Primary storage holds the active data that applications read and write, while secondary storage holds the redundant copy used for failover or restore. Cloud SQL shows this split directly: the primary instance lives in a regional location and zone, high availability adds a synchronous standby in another zone, and backups provide a secondary copy in a multi-region location.

The table guides the decision: choose a zone when data must sit next to compute in the same zone, choose a region when the application and its primary database should share low-latency access with protection against zone failure, and choose dual-region or multi-region when the goal is a secondary copy that survives a regional failure.

Key Facts

• Zones are sub-locations inside a region, such as us-central1-a in us-central1, and regions are independent geographic areas, such as europe-west2 in London, made up of multiple zones.
• Regional resources are deployed redundantly across multiple zones in one region and survive a single-zone incident but can still be affected by a region-wide outage.
• Cloud SQL high availability replicates the primary database synchronously to a standby database in a different zone of the same region for automatic failover.
• The live Cloud SQL instance always uses a regional location that cannot be changed after creation, while Cloud SQL backups use multi-regional locations us, eu, and asia.
• Dual-region and multi-region storage distributes data across specific regions and survives zone and single-region incidents for disaster recovery.