Choose your backup option Stay organized with collections Save and categorize content based on your preferences.
Preview —Enhanced backups
This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. You can process personal data for this feature as outlined in theCloud Data Processing Addendum, subject to the obligations and restrictions described in the agreement under which you access Google Cloud. Pre-GA features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.
This document explains the two backup options for your Cloud SQL instances,including their key features and configurations. This helps you choose the mostsuitable option for your instances.
Before you can use backups with your Cloud SQL instances, you mustchoose a backup option for each instance. Cloud SQL offers thefollowing backup options:
- Enhanced backups: This option manages and storesbackups in a centralized backup management project. It usesBackup and DR Service andprovides enforced retention, granular scheduling, and monitoring.
- Standard backups: Cloud SQL creates,manages, and stores these backups in the same project as yourCloud SQL instances.
The backup option you choose defines the features and configuration optionsavailable for your Cloud SQL instance. Although instances can't usemultiple backup options simultaneously, Cloud SQL lets you switchbetween these backup options as needed.
Note: If your instance was created before theenhanced backups launch,then your instance is using the standard backups option. To upgrade yourinstance to the enhanced backups option, seeEnable enhanced backups.For new instances, you'll need to select a backup option when youcreate the instance.The following table provides an overview of the key features available witheach backup option:
| Features | Standard backups | Enhanced backups |
|---|---|---|
| Centralized backup management across projects | - | ✔ |
| Backup vault | - | ✔ |
| Automated backup schedule | Daily | Hourly, daily,weekly, monthly,yearly |
| On-demand backups | ✔ | ✔ |
| Multi-region backups | ✔ | - |
| Final backup in instance deletion | ✔ | ✔ |
| Backup retention period | 1 year | Unlimited |
| Retain all backups on instance deletion | ✔ | ✔ |
| Retain backups on project deletion | - | ✔ |
| Enforced retention with retention lock | - | ✔ |
| Point-in-time recovery using logs | ✔ | ✔ |
| Cross-region backup and restore | ✔ | - |
| CMEK support | ✔ | - |
For detailed information about these backup options, seeStandard backups andEnhanced backups.For more information about how backups work in Cloud SQL,seeCloud SQL backups overview.
Enhanced backups
With enhanced backups, you can use Backup and DR to manage and storeall backups for your Cloud SQL instances across various projects in onecentral backup project. Backup and DR provides centralized management,monitoring, and reporting of day-to-day backup operations in one place. Backupsare stored in abackup vault,which is a Google-managed secured and isolated storage resource, managed byBackup and DR, andbackup plansmanage the backup and restore settings. This provides immutableand indelible backups that are independent of the source project. For moreinformation about how backups work withBackup and DR, seeBackup and DR overview.
With enhanced backups, you can use a centralized backup project that hostsyourbackup vaultandbackup plansthat you associate across all your Cloud SQL instances. These planscan also be linked across multiple projects.
Note: Cloud SQL recommends creating your backup vault andbackup plan in a different project than your Cloud SQL instances.When you attach a backup plan to a Cloud SQL instance, the existingbackup and restore settings are overwritten by the backup plan. The plancontaining your backup and restore settings is stored in the centralized backupproject, and any backups created when the plan is active on your Cloud SQLinstance are stored in the backup vault in the backups project.
If the Backup and DR is managed in a separate Google Cloud project,then backups are protected when a source or workload project is deleted. Rolesand responsibilities are managed by theBackup and DR Admin,and are separate fromCloud SQL Admin roles and responsibilities.
You can retain backups after instance deletion, or take a final backup of yourinstance prior to deletion. All backups taken as part of enhanced backups canbe used to restore an instance while its live, or after it is deleted.
Backup storage
Backups are stored in a centralized location called a backup vault. Abackup vault is a secured and isolated storage, managed byBackup and DR. A backup vault stores backups in a single region,as long as the selected location iscompatible with your instance's location.For more information about where you can create a backup vault, seeBackup vault supported locations.
Cloud SQL recommends that you use a backup vaultthat is in a different project than your Cloud SQL instance.For more information, seeBackup vaults.
Backup retention
Enhanced backups allow you to takeon-demandandautomated backups.Any backups created when using the enhanced backups option are stored in thebackup vault and can be retained for up to 99 years. Thebackup vault has aminimum enforced retention periodbetween 1 day and 99 years.
If you delete your instance, then all of your instance's backups that werecreated when your instance was live areretainedautomatically and follow the same retention settings set bythe backup plan when the instance was live. If you elect to take afinal backupof your instance prior to deletion, then you can set the backup retentionfor the final backup for up to 99 years as well.
Backup costs
In enhanced backups, the cost for backups are based on the total size ofthe backup that is stored in the backup vault. These backups are created basedon the backup configuration in the instance's associated backup plan. The totalcost is calculated by Backup and DR, and based onBackup and DR pricing.
Limitations
The following limitations apply when using enhanced backups:
- The Backup vault and your Cloud SQL instance must be inthe same region.
- Changing an instance's associated backup plan requires changing your instanceto standard backups by deleting the existing backup plan association, thenassociating the new backup plan.
- You can't create aDisaster Recovery (DR) replicafor an instance using enhanced backups.
- If your instance has aDisaster Recovery (DR) replica,then you can't enable enhanced backups for the instance.
- You can't associate a backup plan with a replica instance.
- If your instance is using enhanced backups, then you can't demote theinstance to a replica.
Standard backups
Standard backups is the backup option that is managed by Cloud SQL.Backups are created, managed, and stored in the same project as yourCloud SQL instances. Unlike enhanced backups, where backup settingsare defined by a backup plan, backup configurations for standard backups areset at the instance level and defined in the instance's settings. Therefore,if you have multiple Cloud SQL instances, then you'll needto define the backup configurations for each instance separately inthe instance's backup settings. Any backups created as partof standard backups are stored in the same project as the instance.
With standard backups, you can take automated and on-demand backups for yourCloud SQL instances. You can also select toretain all backupsand take afinal backupof your data at instance deletion. This lets you recreate anyinstances that you delete. However, if you don't retain backups or take a finalbackup prior to deleting your instance, then Cloud SQL deletes allinstance backups automatically.
Backup storage
Backups are stored in the same location for instances in bothhigh availability (HA) or non-HA configurations. In high availabilityconfigurations, you'll still be able to access your instance's backups in theevent of a failover or switchover to the secondary instance.
You can define your backup locations as follows:
- Default locations that Cloud SQLselects, based on the location of the original instance.
- Custom locations that you choose when you don'twant to use the default location.
Default backup locations
If you don't specify a storage location, then your backups are stored in themulti-region that is geographically closest to the location of yourCloud SQL instance. For example, if yourCloud SQL instance is inus-central1, then your backups are stored in theus multi-region by default.
Note: When restoring data from a backup, restore it to an instance in aregion that's available. To view a list of all backups for an instance in a region that'sundergoing an outage, use the- wildcard with thegcloud sql backups list --instancecommand or thebackupRuns.list API. For more information, seeViewing a list of backups during an outage.You can then restore the data from the backup to a new or existing instance in a region that's not undergoing an outage.
Multi-region backups
Standard backups let you have single or multi-region backup locationconfigurations. In a single-region configuration, backups are replicatedacross the different zones within the region. In a multi-region configuration,it's recommended that backups be in the same region as the instance tominimize latency and avoid potential backup failures due toorganization policies, or location-based limitations.
Custom backup locations
Cloud SQL lets you select a custom location for your backup data. Thisis useful if your organization needs to comply with data residency regulationsthat require you to keep your backups within a specific geographic boundary. Ifyour organization has this type of requirement, it probably uses aResource Location Restriction organizational policy.With this policy, when you try to use a geographic location that doesn't complywith the policy, you see an alert on theBackups page. If yousee this alert, then you need to change the backup location to a location thepolicy allows.
When selecting a custom location for a backup, consider the following:
- Cost: one cluster in your instance might be in a lower-cost region thanthe others.
- Proximity to your application server: you might want to store the backupas close to your serving application as possible, to reduce potentiallatency.
- Storage utilization: you need enough storage space to keep your backupas it grows in size. Depending on your workload, you might have clustersof different sizes or with different disk usages. This might factor intowhich cluster you choose.
You can select any available Cloud SQL location and multi-regionlocation when choosing your custom backup location. For a complete list of validregional values, seeInstance Locations.For a complete list of multi-regional values, seeMulti-regional locations.
For more information about setting and view backup locations for an instance,seeSet a custom location for backupsandView backup locations.
Backup retention
Standard backups allow you to take automatic and on-demand backups.Automated backups can be retained from1 to 365 days, and the defaultis 7 days for Cloud SQL Enterprise edition instances and 15 days for Cloud SQL Enterprise Plus edition instances.On-demand backups are retained indefinitely, until either the backup is deleted,or the instance containing the backup is deleted.
If you enable backup retention after instance deletion for your on-demandand automated backups, then those backups follow the same retention settings of1 to 365 days for automated backups, and indefinitely for on-demand backups.For more information, seeRetain backups after instance deletion.
Backup costs
In standard backups, backup costs are based on thetotal size of the backup,itsstorage location andretentionsettings.
You can configure how many automated backups to retain, from 1 to 365.
For more information about pricing related to backups, seeCloud SQL pricing.
Backup rate limitations
Cloud SQL limits the rate for backup operations on the data disk. You'reallowed a maximum of five backup operations every 50 minutes perinstance per project. If a backup operation fails, it doesn't count towardsthis quota. If you reach the limit, the operation fails with an errormessage that tells you when you can retry.
Cloud SQL uses tokens from a bucket to determine how many backup operationsare available at any one time. Each instance has a bucket. There's a maximum offive tokens in the bucket that you can use for backup operations. Every 10minutes, a new token is added to the bucket. If the bucket is full, the tokenoverflows.
Each time you issue a backup operation, a token is granted from the bucket. Ifthe operation succeeds, the token is removed from the bucket. If it fails, thetoken is returned to the bucket. The following diagram shows how this works:

Transaction log retention
Transaction logs are stored in your instance's storage location and retentionis in days. For Cloud SQL Enterprise Plus edition instances, the rangeis from 1 to 35 days, with a default of 14 days. For Cloud SQL Enterprise editioninstances, the range is from 1 to 7 days, with a default of 7 days.For both Cloud SQL Enterprise Plus edition and Cloud SQL Enterprise edition instances, the transaction logretention setting must be less than the backup retention setting.
Caution: The transaction log retention setting must always be less than or equalto the backup retention setting. Transaction logs older than the last backupare automatically deleted.Logs are purged once daily, not continuously. When the number of days of logretention is the same as the number of backups, it can result ininsufficient log retention. For example, setting log retention to seven daysand backup retention to seven backups means that between six and seven days oflogs will be retained.
We recommend setting the number of backups retained to one number more than thenumber of days for log retention to make sure there are backups for every dayof the log retention period.
What's next
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-11-24 UTC.