apointoo.
Request access
Healthcare Cloud

Does a Regional Cloud SQL Instance Keep Its Backups in the Same Region?

cmsapointoo··9 min read

For Cloud SQL standard backups, a regional database instance does not keep its backups in that same region by default. Google Cloud stores the instance data in the instance’s region, but places backups in the geographically closest multi-region when no backup location is specified. An exact-region requirement needs an explicit regional backup location.

Changing that setting is prospective. Existing backups remain in their original locations, so a correct setting today does not prove that older copies share it. A defensible residency review must inventory every backup, its location, the backup option in use, organization-policy constraints, exports, and recoverable copies after instance deletion.

Why does a regional Cloud SQL instance have multi-region backups?

Google Cloud distinguishes the location of instance data from the storage location of standard backups. Its PostgreSQL FAQ says instance data is stored in the region where the instance resides. If no backup storage location is supplied, backups go to the multi-region geographically closest to that instance.

That default supports availability goals, but it does not preserve an exact regional boundary. A multi-region is a different location class from a named region. An architecture diagram that labels only the database region therefore omits a material storage fact.

The same service-boundary issue appears in regional Google Cloud logging. A regional workload does not confer its location on logs or backups. Record each resource, location property, scope, and default separately instead of describing the whole project as regional.

Which Cloud SQL backup option does this answer cover?

This answer focuses on standard backups managed by Cloud SQL. Google documents standard backups alongside another option managed through Backup and DR. Those products have different resource models, policies, locations, recovery paths, and deletion behavior. A team must identify the selected option before applying a location rule.

Within standard backups, Cloud SQL supports automatic and on-demand backups. The custom-location instructions apply to both. High availability does not merge instance and backup locations either. Google says backups use the same location logic for high-availability and non-high-availability instances.

Do not infer the backup option from a console label or an old runbook. Capture the effective instance settings and list the actual backup resources. If Backup and DR is also configured, review its vaults and policies as a separate path rather than treating them as duplicates of standard backups.

How do you keep standard backups in the instance’s exact region?

Set a custom backup location to the approved region. Google Cloud allows a regional or multi-regional custom location for automatic and on-demand standard backups. For an exact-region requirement, choose the same named region as the instance and verify the saved effective setting.

The configuration can be managed through the supported console, command-line, API, or infrastructure-as-code surfaces described by Google. The evidence should record the project, instance, instance region, backup-location value, actor, time, and review approval. Avoid copying database contents into the change ticket.

Test with a new synthetic backup and inspect its Location field. A successful configuration update only proves that the service accepted a setting. It does not prove that a backup was created there, that older backups moved, or that exports use the same destination.

What happens to backups created before the location changes?

They stay where they were created. Google’s standard-backup instructions explicitly state that changing the backup storage location leaves existing backups in their original location. The new setting controls future backups. It is not a migration command.

Inventory old backups individually and record their location and retention state. Decide whether each copy may remain, must expire, or requires an approved deletion. Do not restore an old backup merely to inspect its contents. Location metadata and a synthetic restore rehearsal can often provide the needed technical evidence without exposing healthcare records.

Deletion is another independent boundary. The guide to restorable Google Cloud Storage objects explains why a delete request can leave other recoverable states in that service. Cloud SQL has its own backup lifecycle, so verify its documented backup list and retention behavior rather than borrowing Cloud Storage semantics.

How do organization location policies affect Cloud SQL backups?

A resource-location organization policy can restrict allowed locations. Google warns that a backup fails if its configured region is not allowed by the applicable organization policy. The documentation also says a backup in the same region as the instance succeeds with respect to that location constraint.

Policy is a guardrail, not a migration. It does not move existing backups into an allowed location. It also does not prove that every project inherited the intended rule or that other data paths use the same region. Check the effective policy at the project and test the backup job after any policy or location change.

Failure monitoring matters. A strict policy can stop a backup that still points to the default multi-region. The safer rollout order is to inventory current locations, approve the target, configure the regional backup location, create and verify a test backup, then enforce the policy. Preserve failed-job alerts so residency controls do not silently remove recoverability.

Which copies sit outside the standard backup setting?

The standard backup location governs the standard backups covered by that setting. It does not govern database exports written to Cloud Storage, downstream analytics stores, replicas, application caches, local downloads, support attachments, or independent Backup and DR resources. Each destination has its own location and lifecycle.

Message paths also need separate treatment. The article on Pub/Sub storage policies for single-region health workloads shows that a message policy constrains that service’s storage behavior, not a later database or object copy. Trace the complete approved flow instead of extending one product setting across the architecture.

Encryption keys add another location and access question. A customer-managed key can support access control, but it does not relocate a backup or authorize a destination. Record key resource, location compatibility, administrators, rotation, and recovery dependencies separately from the backup’s location.

What evidence supports an exact-region claim?

Use resource evidence, not account-level assumptions. A useful record names the instance, its region, backup option, effective backup location, every relevant backup ID, each backup’s Location value, organization-policy result, and downstream copies. It should also identify the time range covered by the conclusion.

  1. Confirm the Cloud SQL engine, edition, backup option, project, and owner.
  2. Record the instance region and effective standard-backup location.
  3. List automatic and on-demand backups with individual locations.
  4. Separate backups created before and after the configuration change.
  5. Check effective organization location constraints and failed jobs.
  6. Map exports, replicas, Backup and DR resources, and application copies.
  7. Test creation and restoration with synthetic data in approved locations.
  8. Document exceptions, owners, review dates, and deletion triggers.

The conclusion should remain narrow: named standard backups created after a specified configuration time were stored in the verified region. If older backups remain elsewhere or another backup option was not reviewed, state that limitation. Precision prevents a regional backup fact from becoming an unsupported claim about all project data.

Does regional backup placement prove HIPAA or GDPR compliance?

No. Location is one technical and contractual fact. HIPAA, GDPR, and other duties depend on the organization, roles, purposes, agreements, safeguards, transfers, retention, rights, and actual data flow. Some organizations choose an exact region because of law or contract, while others choose it as an internal architecture constraint.

Google’s BAA coverage is separate from configuration. A BAA can define covered services and shared responsibilities, but it does not select a backup location, inspect organization policy, remove old backups, or validate exports. The article on Google Cloud BAA product boundaries explains why agreement scope should not be stretched across products or customer settings.

Obtain legal and privacy approval for the required boundary, then ask cloud operators to prove the named configuration. Do not reverse that sequence by treating a console choice as the source of the legal requirement. A region toggle can implement a decision; it cannot make the decision or certify the whole system.

Frequently asked questions

Are Cloud SQL standard backups regional by default?

No. When no location is specified, Google stores standard backups in the geographically closest multi-region. A named instance region and its default backup location are therefore different facts.

Does changing the backup location move existing backups?

No. Google states that existing backups remain in their original locations. The changed setting applies to future backups, so older copies need their own inventory and disposition decision.

Can organization policy force a disallowed backup to another region?

No. Google says backups in a disallowed configured region fail. Policy should be paired with an approved backup location, job monitoring, and a tested recovery path rather than treated as automatic relocation.

Does putting Cloud SQL backups in one region make the workload compliant?

No. Regional placement can implement one approved requirement. Compliance still depends on legal scope, agreements, access, encryption, application behavior, retention, incident response, exports, and every other data copy.

References

Related articles