Backup vaults for immutable and indelible backups

Set up a backup vault

The backup vault is a Google-managed regional resource that provides isolated, immutable, and indelible storage for backups. It organizes data into a hierarchy of vaults, data sources, and backups, protecting data against accidental or malicious deletion through enforced retention periods and project-level identity isolation.

This document explains how backup vaults work, including the hierarchical resource model, supported workloads, backup models, location compatibility, availability, and naming requirements.

Resource hierarchy

Data within the Backup and DR Service is organized into a three-tiered hierarchy within the backup vault:

Backup vault: a top-level container that enforces global minimum retention policies.
Data source: a child resource representing a specific protected entity (for example a Compute Engine instance). The system creates this automatically upon the first backup.
Backup: a child resource of a data source representing a discrete backup with a specific point-in-time recovery point.

The following diagram shows the backup vault resource model:

Limitations

This page describes backup vaults for resources managed through the Google Cloud console (such as Compute Engine or Cloud SQL). If you are using the appliance management console for workloads like Oracle or Google Cloud VMware Engine, see Overview of backup vaults managed from the appliance management console.
AlloyDB clusters and Filestore instances in backup vaults aren't supported for multi-regions.
Backup and DR Service doesn't impose any restriction on the compatible destination locations when restoring a workload from a backup vault backup.
You can incur network transfer fees depending on the locations of your backup vault and source workload. For more information, see Backup and DR Service pricing.

Supported resources

Workload type	Management
Compute Engine instance	Google Cloud console
Compute Engine disk	Google Cloud console
Filestore instance	Google Cloud console
Cloud SQL instance	Google Cloud console
AlloyDB cluster	Google Cloud console
Google Cloud VMware Engine, Oracle database, and SQL Server database	Appliance management console

Backup models for resources

	Centralized model	Decentralized model
Google Cloud console	Consolidates backup management by creating backup vaults and backup plans in a central administrator project. Administrators can use these centrally managed plans to protect resources across multiple service projects, or use IAM permissions to delegate backup plan access to application owners.	Isolates backup management by creating a separate backup vault and backup plan within each project. This approach is ideal for decentralized organizations where individual application teams are responsible for backing up their own resources.
Appliance management console	Consolidates backup management by deploying the appliance management console and creating backup vaults in a central administrator project. Administrators configure backup policies within the central management console to protect resources, such as Google Cloud VMware Engine VMs, across multiple service projects.	Isolates backup management by deploying a separate appliance management console and backup vault for each project or line of business. This approach is ideal for decentralized organizations where backup management responsibilities are split across multiple teams.

Backup vault supported locations

You can create a backup vault in the same region as the source workload (regional), in a different region from the source workload (cross-regional), or across multiple regions (multi-regional).

Supported regions and cross-regions

You can create backup vaults in the following regions and cross-regions:

Geographic Area	Region Name	Region Description
North America
	`northamerica-northeast1` ^*	Montréal	Low CO₂
	`northamerica-northeast2`	Toronto	Low CO₂
	`us-central1`	Iowa	Low CO₂
	`us-east1`	South Carolina
	`us-east4`	Northern Virginia
	`us-east5`	Columbus
	`us-south1`	Dallas	Low CO₂
	`us-west1`	Oregon	Low CO₂
	`us-west2`	Los Angeles
	`us-west3`	Salt Lake City
	`us-west4`	Las Vegas
	`northamerica-south1` ^*	Querétaro
South America
	`southamerica-east1`	São Paulo	Low CO₂
	`southamerica-west1`	Santiago	Low CO₂
Europe
	`europe-central2`	Warsaw
	`europe-north1`	Finland	Low CO₂
	`europe-north2`	Stockholm	Low CO₂
	`europe-southwest1`	Madrid	Low CO₂
	`europe-west1`	Belgium	Low CO₂
	`europe-west2`	London	Low CO₂
	`europe-west3`	Frankfurt
	`europe-west4`	Netherlands	Low CO₂
	`europe-west6`	Zürich	Low CO₂
	`europe-west8`	Milan
	`europe-west9`	Paris	Low CO₂
	`europe-west10`	Berlin
	`europe-west12`	Turin
Middle East
	`me-central1`	Doha
	`me-central2`	Dammam
	`me-west1`	Israel
Africa
	`africa-south1`	Johannesburg
Asia Pacific
	`asia-east1`	Taiwan
	`asia-east2`	Hong Kong
	`asia-northeast1`	Tokyo
	`asia-northeast2` ^*	Osaka
	`asia-northeast3`	Seoul
	`asia-southeast1`	Singapore
	`asia-southeast2`	Jakarta
	`australia-southeast1`	Sydney
	`australia-southeast2`	Melbourne
India
	`asia-south1`	Mumbai
	`asia-south2`	Delhi

^* Querétaro (northamerica-south1), Montréal (northamerica-northeast1), and Osaka (asia-northeast2) don't support zone separation. This means the multiple zones within each of these regions may not be located in physically separate data center campuses. Consequently, a single, localized physical disaster event could potentially impact multiple zones within the same region, increasing the risk of data loss compared to regions that support zone separation.

Supported multi-regions

You can create backup vaults in the following multi-regions:

Multi-region name	Description
`ASIA`	Data centers in Asia
`EU`	Data centers in the European Union
`US`	Data centers in the United States

Workload location compatibility

The following table describes the compatible backup vault locations for each supported workload, when using regional and cross-regional backup vaults. Note that backup plans in the Google Cloud console must be created in the same region as the source workload.

Workload	The backup vault must be in the same region as the source workload	Regional support	Multi-regional support	Cross-regional support
Compute Engine instance	No
Compute Engine disk	No
Cloud SQL instance	Yes
AlloyDB cluster	Yes
Filestore instance	No
Google Cloud VMware Engine, Oracle database, and SQL Server database	No

Multi-region compatibility

The following requirements must be met to use multi-regions:

If a workload supports multi-region backup vaults, the source workload location must be compatible with the multi-region backup vault location.
You can only backup up resources in regions that share the same prefix. For example, resources in regions with the asia prefix are only allowed to be backed up to the asia multi-region.

The following table describes the compatible backup vault locations for each supported workload when using multi-region backup vaults:

Workload type	Supports use of multi-region backup vaults?	Supported backup vault multi-regions
Compute Engine instance		`asia`, `eu`, `us`
Compute Engine disk		`asia`, `eu`, `us`
Filestore instance		N/A
Cloud SQL instance		`asia`, `eu`, `us`
AlloyDB cluster		N/A
Google Cloud VMware Engine, Oracle database, and SQL Server database		N/A

Availability

Backup vaults created in regional and cross-regional locations provide resilience against a single-zone outage. Backup data is stored redundantly in at least two separate zones.

Backup vaults created in multi-region locations provide resilience against a single-region outage. Backup data is stored redundantly in at least two separate regions.

Compare multi-region and cross-region backup vaults

Criteria	Multi-region backups	Cross-region backups
Backup creation	Automated by Google across two regions within a continent.	Autonomy to explicitly define a region to create backup.
Use case	High availability & operational simplicity	Strict compliance, data residency laws, or targeted disaster recovery sites, within and outside source regional boundaries.
Management	Low overhead. Single vault, automated balancing	Medium overhead. Requires setting up specific target pairing.
Customer-managed encryption keys (CMEK)	Multi-region backup vault must use CMEK from the same region as the backup vault.	Cross-region backup vault must use CMEK from the same region as backup vault.
Cost implications	Multi-regional upload and download charge, where applicable. Backup storage charge for multi-region vault. Management charge.	Inter-region data transfer charges. Backup storage charge. Management charge.
Supported workloads	Compute Engine instances Compute Engine disks Cloud SQL instances	Compute Engine instances Compute Engine disks Filestore instances

Backup vault names

Your backup vault names must meet the following requirements:

Backup vault names can only contain lowercase letters, numeric characters, and hyphens (-). Spaces aren't allowed.
Backup vault names must start and end with a number or letter.
Backup vault names must contain 3-63 characters. Names containing periods can contain up to 222 characters, but each period-separated component can be no longer than 63 characters.
Backup vault names cannot be represented as an IP address in dotted-decimal notation. For example, 192.0.2.255.

Prevent backup deletion

An enforced retention period prevents backups from being deleted before a specified duration has passed. Backups stored in the vault incur storage charges for the duration of this period. Before configuring enforced retention, review the cost and compliance implications described in Resource hierarchy.

Minimum enforced retention

The backup vault minimum enforced retention period lets you control when a backup can be deleted in order to protect data from accidental or malicious deletion. Backups inside backup vaults are only eligible for deletion after reaching the end of the minimum enforced retention duration. When you create a new backup vault, you must specify a minimum enforced retention period between 1 day and 99 years.

When you create a backup vault with a Minimum enforced retention of three days, then any backup rule that stores backups in this vault must have a Delete backups after value equal to or greater than three days.

Prevent deletion for duration specified in backup rule

This setting allows a backup vault to adopt the retention period defined in an associated backup plan.

When you enable this option on a backup vault, the following behavior occurs:

The retention period specified in the backup rule takes precedence and acts as enforced retention. However, the vault's minimum enforced retention must still be satisfied, so rule-specified retention durations cannot be less than the vault-level minimum.
Manual deletion is prevented. Backups cannot be manually deleted during this enforced retention period. They are automatically deleted only after the duration specified in the backup plan's rule has expired.
When this setting is active, the Enforced retention column for the backup vault will indicate Inherited from rule.

Example: Retention precedence

If you have the following configuration:
- Backup vault Minimum enforced retention: 3 days
- Backup vault Prevent deletion for duration specified in backup rule: Enabled
- Backup plan Delete backups after: 7 days
Result:

The backup cannot be deleted for the 7-day period specified in the backup plan's rule and will be automatically deleted only after 7 days have passed.

Note: This value can only be set when a backup vault is created.

For more information on how enforced retention compares with the expiration period set in the backup plan, see Overview of data retention in Backup and DR Service.

Lock the enforced retention period

You can prevent the shortening of a backup vault's minimum enforced retention period by locking the backup vault. You can still increase the minimum enforced retention period after it has been locked, see Update the minimum enforced retention period.

When setting a lock, you must define the date when the lock takes effect. Until the effective date is reached, you can increase or shorten the backup vault's enforced retention period. However, after the lock's effective date is reached, even the project owner cannot decrease the enforced retention period for that backup vault.

For example, say that you've set the minimum enforced period to five days, specified that the vault should be locked, and have set the lock effective date to July 31, 2024, at 12 AM UTC. Until July 31, 2024, at 12 AM UTC, you can increase or decrease the minimum enforced retention period. After that, you can only increase the minimum enforced retention period.

Backup vault access restriction

A backup vault's access restrictions setting lets you control the sources from which data can be backed up into or restored from a backup vault. This setting determines the types of resources that you can store in a backup vault.

You can select one of the following access restriction settings for a backup vault. Note that this setting is permanent and can't be changed.

Restrict access to current organization: backup and restore operations are only supported within your current organization. This selection makes the backup vault compatible with resources managed through Google Cloud console, such as Compute Engine instances, but not with resources managed through the appliance management console.
Restrict access to current project: backup and restore operations are only supported within your current project. This selection makes the backup vault compatible with resources managed through Google Cloud console (for example, Compute Engine instances), but not with resources managed through the appliance management console.
Restrict access to current organization & unrestricted access for backup appliances: for resources managed through Google Cloud console, backup and restore operations are only supported within your current organization. Resources managed through the appliance management console (for example, Google Cloud VMware Engine VMs) are also supported, but backup and restore operations for those resources are not restricted to your current organization. This selection makes the backup vault compatible with resources managed through Google Cloud console and with resources managed through the appliance management console.
Allow unrestricted access: allows backup and restore operations to or from any project or organization. This selection makes the backup vault compatible with resources managed through Google Cloud console and with resources managed through the appliance management console.

Encryption

By default, Google Cloud automatically encrypts data when it's at rest using Google-owned and Google-managed encryption keys. If you have specific compliance or regulatory requirements related to the keys that protect your data, you can use customer-managed encryption keys (CMEK) for your backups. See Customer-managed encryption keys (CMEK).