This page describes the backup vault, supported backup models, regions, and resources.
A backup vault is a container that stores backups, similar to self-managed storage (a Cloud Storage bucket that you create). However, a backup vault provides benefits by protecting backups in secure, isolated, and specialized storage. backup vaults are designed to support resilience against malicious or accidental deletion of backups. This capability supports various data protection use cases, such as recovery from user error and cyber recovery.
When backups are stored in a backup vault, the Backup and DR Service handles the storage and management of the backup data. You don't have direct visibility or access to the underlying storage resources where the data is stored, which safeguards those resources against direct attacks. Additionally, backup vaults allow you to specify a minimum enforced retention period, which mandates that a backup cannot expire until the specified timeframe has elapsed and helps protect against accidental or malicious deletion.
You create, access, and manage backup vaults using the Google Cloud Backup and DR Service. Backup vaults store backups in a single region. If you need to store backups to multiple regions, use self-managed storage.
Resource model
The following section describes the backup vault resource model.
Backup vaults have a three-level hierarchical resource model to organize backup data:
- Backup vault. A top-level, user-defined resource for storing Google Cloud Backup and DR backup data.
- Data source. Represents the specific resource that is backed up, such as a virtual machine or database instance. A single data source can contain multiple backups. A data source is a child resource of a backup vault.
- Backup. Represents a single backup for the resource specified by the data source. A backup is a child resource of a data source.
The following diagram shows the backup vault resource model.
Supported resources
The following table helps you to understand the resources that backup vaults support and what you use to manage them.
| Workload | Managed by |
|---|---|
| Compute Engine instance | Google Cloud console |
| Google Cloud VMware Engine, Oracle database, and SQL Server database | Management console |
Backup models for resources protected using the Google Cloud console
This section describes the two backup models for resources protected using the Google Cloud console.
Centralized model: In the centralized model, organizations streamline backup management by creating backup vaults and plans within a designated central administrator project. This central repository consolidates backups of various resources, like Compute Engine VMs running across multiple service projects. Organizations then use these centrally managed backup plans to protect their Compute Engine VMs residing in different service projects.
Backup administrators can also grant access to backup plans to application or platform owners within service projects through IAM permissions. Granting access allows platform owners to take ownership of backing up their applications.
Decentralized model: In the decentralized model, backup vaults are created in various projects based on the organization's specific needs and required isolation levels. This means a backup vault and backup plan is created for each project with various resources, such as Compute Engine VMs. This approach is crucial for decentralized organizations where the responsibility for backing up VMs lies with the respective application team.
Backup models for resources protected using the management console
This section describes the two backup models for resources protected using the management console.
Centralized model: In the centralized model, organizations streamline backup management by creating backup vaults and deploying the management console within a designated central administrator project. This central repository consolidates backups of various resources, such as VMware Engine VMs running across multiple service projects. Organizations then configure policies within the management console to protect their resources residing in different service projects.
Decentralized model: In the decentralized model, management consoles and backup vaults are created in various projects based on the organization's specific needs and required isolation levels. For example, an organization might choose to have a separate management console for each line of business. This approach is useful for decentralized organizations where the responsibility for managing and backing up resources is split between multiple teams.
Backup vault supported regions
Backup vault is supported in the following regions.
| Geographic Area | Region Name | Region Description | |
|---|---|---|---|
| Americas | |||
us-central1 |
Iowa |
 Low CO2
|
|
us-east4 |
Northern Virginia | ||
| Europe | |||
europe-west1 |
Belgium |
Low CO2
|
|
europe-west4 |
Netherlands |
Low CO2
|
|
| Asia Pacific | |||
asia-east1 |
Taiwan |
Backup vault names
Your backup vault names must meet the following requirements:
- Backup vault names can only contain lowercase letters, numeric
characters, dashes (
-), underscores (_), and periods (.). Spaces are not 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.
Backup vault minimum enforced retention period
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 and 30 days.
You can prevent the shortening or removal 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 or remove 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.
What's next
- Create and manage a backup vault in the Google Cloud console
- Manage data sources in the Google Cloud console
- Manage backups in the Google Cloud console