This document explains the two backup options for your Cloud SQL instances,
including their key features and configurations. This helps you choose the most
suitable option for your instances.
Before you can use backups with your Cloud SQL instances, you must
choose a backup option for each instance. Cloud SQL offers the
following backup options:
- [**Enhanced backups**](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backup-options.md.txt#enhanced-backups): This option manages and stores backups in a centralized backup management project. It uses [Backup and DR Service](https://docs.cloud.google.com/backup-disaster-recovery/docs/concepts/backup-dr.md.txt) and provides enforced retention, granular scheduling, and monitoring. Pricing for enhanced backups is managed by [Backup and DR Service pricing](https://cloud.google.com/backup-disaster-recovery/pricing).
- [**Standard backups**](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backup-options.md.txt#standard-backups): Cloud SQL creates, manages, and stores these backups in the same project as your Cloud SQL instances.
The backup option you choose defines the features and configuration options
available for your Cloud SQL instance. Although instances can't use
multiple backup options simultaneously, Cloud SQL lets you switch
between these backup options as needed.
> [!NOTE]
> **Note:** If your instance was created before the [enhanced backups launch](https://docs.cloud.google.com/sql/docs/sqlserver/release-notes.md.txt#July_31_2025), then your instance is using the standard backups option. To upgrade your instance to the enhanced backups option, see [Enable enhanced backups](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/manage-enhanced-backups.md.txt#enable). For new instances, you'll need to select a backup option when you [create the instance](https://docs.cloud.google.com/sql/docs/sqlserver/create-instance.md.txt).
The following table provides an overview of the key features available with
each 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 | 10 years |
| Retain all backups on instance deletion | ✔ | ✔ |
| Retain backups on project deletion | - | ✔ |
| Enforced retention with retention lock | - | ✔ |
| Point-in-time recovery using logs | ✔ | ✔ |
| Point-in-time recovery after instance deletion | ✔ | ✔ |
| Cross-region backup and restore | ✔ | ✔ |
| CMEK support | ✔ | ✔ |
For detailed information about these backup options, see
[Standard backups](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backup-options.md.txt#standard-backups) and [Enhanced backups](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backup-options.md.txt#enhanced-backups).
For more information about how backups work in Cloud SQL,
see [Cloud SQL backups overview](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backups.md.txt).
## Enhanced backups
With enhanced backups, you can use Backup and DR to manage and store
all backups for your Cloud SQL instances across various projects in one
central backup project. Backup and DR provides centralized management,
monitoring, and reporting of day-to-day backup operations in one place. Backups
are stored in a
[backup vault](https://docs.cloud.google.com/backup-disaster-recovery/docs/concepts/backup-dr.md.txt#backup-vaults),
which is a Google-managed secured and isolated storage resource, managed by
Backup and DR, and
[backup plans](https://docs.cloud.google.com/backup-disaster-recovery/docs/concepts/backup-dr.md.txt#backup_plans)
manage the backup and restore settings. This provides immutable
and indelible backups that are independent of the source project. For more
information about how backups work with
Backup and DR, see
[Backup and DR overview](https://docs.cloud.google.com/backup-disaster-recovery/docs/concepts/backup-dr.md.txt).
With enhanced backups, you can use a centralized backup project that hosts
your
[backup vault](https://docs.cloud.google.com/backup-disaster-recovery/docs/concepts/backup-dr.md.txt#backup-vaults)
and [backup plans](https://docs.cloud.google.com/backup-disaster-recovery/docs/concepts/backup-dr.md.txt#backup_plans)
that you associate across all your Cloud SQL instances. These plans
can also be linked across multiple projects.
> [!NOTE]
> **Note:** Cloud SQL recommends creating your backup vault and backup plan in a different project than your Cloud SQL instances.
When you attach a backup plan to a Cloud SQL instance, the existing
backup and restore settings are overwritten by the backup plan. The plan
containing your backup and restore settings is stored in the centralized backup
project, and any backups created when the plan is active on your Cloud SQL
instance 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. Roles
and responsibilities are managed by the
[`Backup and DR Admin`](https://docs.cloud.google.com/backup-disaster-recovery/docs/access-control.md.txt#roles),
and are separate from `Cloud SQL Admin` roles and responsibilities.
You can retain backups after instance deletion, or take a final backup of your
instance prior to deletion. All backups taken as part of enhanced backups can
be used to restore an instance while its live, or after it is deleted.
When you use enhanced backups for an instance protected with a customer-managed
encryption key (CMEK), the backup is protected using the same key as the
instance, not the vault CMEK.
### Backup storage
Backups are stored in a centralized location called a
backup vault. A backup vault is a secured and
isolated storage, managed by Backup and DR. You can create the
backup vault in one of the following locations:
- The same region as your Cloud SQL instance
- A [different region](https://docs.cloud.google.com/backup-disaster-recovery/docs/concepts/backup-vault.md.txt#regions) from your Cloud SQL instance. For more information, see [Cross-region backups](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backup-options.md.txt#eb-cross-region)
- A [multi-region](https://docs.cloud.google.com/backup-disaster-recovery/docs/concepts/backup-vault.md.txt#multi-regions)
For more information, see
[Workload location compatibility](https://docs.cloud.google.com/backup-disaster-recovery/docs/concepts/backup-vault.md.txt#workload-location-compatibility)
and
[Backup vault supported locations](https://docs.cloud.google.com/backup-disaster-recovery/docs/concepts/backup-vault.md.txt#locations).
Cloud SQL recommends that you use a backup vault
that is in a different project than your Cloud SQL instance.
For more information, see
[Backup vaults](https://docs.cloud.google.com/backup-disaster-recovery/docs/concepts/backup-dr.md.txt#backup-vaults).
### Cross-region backups
With enhanced backups, you can store the backups of your Cloud SQL
instance in a backup vault that's located in a different region
than the instance. Storing backups in a separate region helps you meet
disaster recovery and compliance requirements that require backups to be
geographically separate from the source instance.
To use cross-region backups, do the following:
1. [Create a backup vault](https://docs.cloud.google.com/backup-disaster-recovery/docs/cloud-console/backup-vault-create.md.txt) in the region where you want to store your backups.
2. [Create a backup plan](https://docs.cloud.google.com/backup-disaster-recovery/docs/cloud-console/backup-plan-create.md.txt) in the same region as your Cloud SQL instance, and select the backup vault that you created. The backup plan and the backup vault must be in the same project.
3. [Enable enhanced backups](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/manage-enhanced-backups.md.txt#enable) by associating the backup plan with your instance.
You view, restore, and manage cross-region backups the same way as backups
that are stored in the same region as your instance.
Consider the following when you use cross-region backups:
- **Backup duration**: scheduled and on-demand backups, and Cloud SQL operations that create a backup (such as a major version upgrade), can take longer because backup data is transferred to another region.
- **Costs** : in addition to Backup and DR backup storage and management charges, inter-region data transfer charges apply. For more information, see [Backup and DR pricing](https://cloud.google.com/backup-disaster-recovery/pricing).
- **CMEK** : if your instance uses a customer-managed encryption key (CMEK), then backups are protected with the instance's key, which resides in the instance's region. If the instance's region is unavailable, then you can't restore these backups. For more information, see [Restore a CMEK-enabled instance using enhanced backups](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/restore.md.txt#restore-cmek).
- **Point-in-time recovery (PITR)** : you can perform PITR by using a cross-region backup only to a new instance in the same region as the source instance. For more information, see [Perform a PITR using the backup vault](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/pitr.md.txt#backup-vault-pitr).
### Operational backups
When you perform a major or minor version upgrade on an instance that uses
enhanced backups, Cloud SQL automatically creates backups and stores
them in the backup vault.
If Cloud SQL can't create a backup in the backup vault
during an upgrade, then Cloud SQL creates a standard backup in the
instance's region so that the upgrade can complete. This backup has the
following characteristics:
- Is stored in the same project as your instance, not in the backup vault.
- Is billed at standard [Cloud SQL backup rates](https://cloud.google.com/sql/pricing#storage-and-networking-pricing).
- Isn't protected by the backup vault's enforced retention, and you can delete it.
### Backup retention
Enhanced backups allow you to take [on-demand](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backups.md.txt#on-demand-backups) and [automated backups](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backups.md.txt#automated-backups). Unlike standard on-demand backups (which may be stored indefinitely), enhanced on-demand backups support user-defined custom retention periods up to 10 years. Any backups created when using the enhanced backups option are stored in the backup vault and are governed by the allowed retention range determined by the intersection of the backup vault's minimum enforced retention and the backup plan's maximum custom retention setting. If `max_custom_on_demand_retention_days` is not explicitly configured in the backup plan, a default upper limit of the backup vault's minimum enforced retention plus 30 days is applied, and regardless of configuration, the maximum allowed retention for any custom on-demand backup is 10 years (3,653 days).
If you delete your instance, then all of your instance's backups that were
created when your instance was live are
[retained](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backups.md.txt#recovery-backups)
automatically and follow the same retention settings set by
the backup plan when the instance was live. If you elect to take a
[final backup](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backups.md.txt#final-backup)
of your instance prior to deletion, then you can set the backup retention
for the final backup for up to 10 years as well.
### Backup costs
In enhanced backups, the cost for backups are based on the total size of
the backup that is stored in the backup vault. These backups are created based
on the backup configuration in the instance's associated backup plan. The total
cost is calculated by Backup and DR, and based on
[Backup and DR pricing](https://cloud.google.com/backup-disaster-recovery/pricing).
If your backup vault is in a different region than your
instance, then inter-region data transfer charges also apply. For more
information, see [Cross-region backups](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backup-options.md.txt#eb-cross-region).
### Limitations
The following limitations apply when using enhanced backups:
- The backup plan must be in the same region as your Cloud SQL instance. The backup vault can be in the same region, a different region, or a [compatible multi-region](https://docs.cloud.google.com/backup-disaster-recovery/docs/concepts/backup-vault.md.txt#multi-region-compatibility).
- If your instance uses CMEK, then you can't restore cross-region backups while the instance's region is unavailable.
- You can't create a [Disaster Recovery (DR) replica](https://docs.cloud.google.com/sql/docs/sqlserver/intro-to-cloud-sql-disaster-recovery.md.txt) for an instance using enhanced backups.
- If your instance has a [Disaster Recovery (DR) replica](https://docs.cloud.google.com/sql/docs/sqlserver/intro-to-cloud-sql-disaster-recovery.md.txt), 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 the instance to a replica.
- For Cloud SQL instances, you can only select and associate with a backup vault that has a minimum enforced retention period of 10 years (3,653 days) or less.
## 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 your
Cloud SQL instances. Unlike enhanced backups, where backup settings
are defined by a backup plan, backup configurations for standard backups are
set at the instance level and defined in the instance's settings. Therefore,
if you have multiple Cloud SQL instances, then you'll need
to define the backup configurations for each instance separately in
the instance's backup settings. Any backups created as part
of standard backups are stored in the same project as the instance.
With standard backups, you can take automated and on-demand backups for your
Cloud SQL instances. You can also select to
[retain all backups](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backups.md.txt#recovery-backups)
and take a [final backup](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backups.md.txt#final-backup)
of your data at instance deletion. This lets you recreate any
instances that you delete. However, if you don't retain backups or take a final
backup prior to deleting your instance, then Cloud SQL deletes all
instance backups automatically.
### Backup storage
Backups are stored in the same location for instances in both
high availability (HA) or non-HA configurations. In high availability
configurations, you'll still be able to access your instance's backups in the
event of a failover or switchover to the secondary instance.
You can define your backup locations as follows:
- [Default locations](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backup-options.md.txt#sb-default-backup-location) that Cloud SQL selects, based on the location of the original instance.
- [Custom locations](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backup-options.md.txt#sb-custom-backup-location) that you choose when you don't want to use the default location.
#### Default backup locations
If you don't specify a storage location, then your backups are stored in the
multi-region that is geographically closest to the location of your
Cloud SQL instance. For example, if your
Cloud SQL instance is in `us-central1`, then your backups are stored in the
`us` multi-region by default.
> [!NOTE]
> **Note:** When restoring data from a backup, restore it to an instance in a region that's available. To view a list of all backups for an instance in a region that's undergoing an outage, use the **-** wildcard with the `gcloud sql backups list --instance` command or the `backupRuns.list` API. For more information, see [Viewing a list of backups during an outage](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backing-up#backuplist). 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 location
configurations. In a single-region configuration, backups are replicated
across the different zones within the region. In a multi-region configuration,
it's recommended that backups be in the same region as the instance to
minimize latency and avoid potential backup failures due to
organization policies, or location-based limitations.
#### Custom backup locations
Cloud SQL lets you select a custom location for your backup data. This
is useful if your organization needs to comply with data residency regulations
that require you to keep your backups within a specific geographic boundary. If
your organization has this type of requirement, it probably uses a
[Resource Location Restriction organizational policy](https://docs.cloud.google.com/resource-manager/docs/organization-policy/defining-locations).
With this policy, when you try to use a geographic location that doesn't comply
with the policy, you see an alert on the **Backups** page. If you
see this alert, then you need to change the backup location to a location the
policy 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 than the others.
- **Proximity to your application server**: you might want to store the backup as close to your serving application as possible, to reduce potential latency.
- **Storage utilization:** you need enough storage space to keep your backup as it grows in size. Depending on your workload, you might have clusters of different sizes or with different disk usages. This might factor into which cluster you choose.
You can select any available Cloud SQL location and multi-region
location when choosing your custom backup location. For a complete list of valid
regional values, see
[Instance Locations](https://docs.cloud.google.com/sql/docs/sqlserver/locations.md.txt#location-r).
For a complete list of multi-regional values, see
[Multi-regional locations](https://docs.cloud.google.com/sql/docs/sqlserver/locations.md.txt#location-mr).
For more information about setting and view backup locations for an instance,
see
[Set a custom location for backups](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backing-up#locationbackups)
and [View backup locations](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backing-up#view_backup_locations).
> [!NOTE]
> **Note:**If you change the location where backups are stored, existing backups remain in their original location.
### Backup retention
Standard backups allow you to take automatic and on-demand backups.
Automated backups can be retained from
7 days to 365 days, and the default
is 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-demand
and automated backups, then those backups follow the same retention settings of
1 to 365 days for automated backups, and indefinitely for on-demand backups.
For more information, see
[Retain backups after instance deletion](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backups.md.txt#recovery-backups).
### Backup costs
In standard backups, backup costs are based on the
[total size of the backup](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backups.md.txt#backup-size),
its [storage location](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backup-options.md.txt#sb-backup-storage) and [retention](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backup-options.md.txt#sb-backup-retention)
settings.
You can configure how many automated backups to retain, from 1 to 365.
For more information about pricing related to backups, see
[Cloud SQL pricing](https://cloud.google.com/sql/pricing#storage-and-networking-pricing).
### Backup rate limitations
Cloud SQL limits the rate for backup operations on the data disk. You're
allowed a maximum of five backup operations every 50 minutes per
instance per project. If a backup operation fails, it doesn't count towards
this quota. If you reach the limit, the operation fails with an error
message that tells you when you can retry.
Cloud SQL uses tokens from a bucket to determine how many backup operations
are available at any one time. Each instance has a bucket. There's a maximum of
five tokens in the bucket that you can use for backup operations. Every 10
minutes, a new token is added to the bucket. If the bucket is full, the token
overflows.
Each time you issue a backup operation, a token is granted from the bucket. If
the operation succeeds, the token is removed from the bucket. If it fails, the
token is returned to the bucket. The following diagram shows how this works:
## What's next
- [Cloud SQL backups overview](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/backups.md.txt)
- [Restore from a backup](https://docs.cloud.google.com/sql/docs/sqlserver/backup-recovery/restoring.md.txt#restorebackups)