Restore an AlloyDB cluster from a backup vault

This document shows you how to restore an AlloyDB cluster from a backup vault using the Google Cloud console or the gcloud CLI. It describes how to restore from a vaulted backup or perform point-in-time recovery (PITR).

For more information about Backup and DR conceptual capabilities, see Backup and DR overview. If you want to backup your databases first, see Back up AlloyDB clusters to a backup vault.

Disaster recovery options for your AlloyDB clusters.

Backups stored in a backup vault are independent of the source cluster's lifecycle and project.

You can restore backups even if the original workload project containing the source AlloyDB cluster is deleted. This is because the necessary decryption permissions for CMEK-encrypted backups are anchored to the Backup and DR service agent in the backup vault's project, not the workload project. This ensures that your backups remain accessible and restorable as long as the backup vault and the Cloud Key Management Service vault key are intact and the service agent has permissions.

Before you begin

Before you restore an AlloyDB cluster from a vaulted backup, ensure you have the required roles and permissions.

To get the permissions that you need to restore an AlloyDB cluster from a vaulted backup, ask your administrator to grant you the following IAM roles:

• To create the restore target: AlloyDB Admin (roles/alloydb.admin) on the project where the target cluster is located
• To read the backup from the vault: Backup and DR Restore User (roles/backupdr.restoreUser) on the project where the source backup exists

For more information about granting roles, see Manage access to projects, folders, and organizations.

These predefined roles contain the permissions required to restore an AlloyDB cluster from a vaulted backup. To see the exact permissions that are required, expand the Required permissions section:

You might also be able to get these permissions with custom roles or other predefined roles.

Service agent roles and key version requirements

Because backups are incremental, a single backup can be encrypted by multiple Cloud Key Management Service key versions of the vault key if the key was rotated over time. For the restore operation to succeed, ensure the following prerequisites are met:

• All Cloud Key Management Service key versions of the vault key used for an incremental backup must exist.

• The Backup and DR service agent in the backup vault project must have the Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) role on the vault key used for the backup.

KMS key behavior of the restored cluster

If no specific CMEK is provided during the restore process, the restored cluster defaults to being encrypted by a Google-managed encryption key. It isn't automatically encrypted by the vault key or the original source cluster key.

If a CMEK is provided during the restore configuration, the restored cluster is encrypted with the newly specified key.

Restore an AlloyDB cluster from a vaulted backup

To restore an AlloyDB for PostgreSQL cluster from a vaulted backup, complete the tasks in the following sections.

Restore the backup to a new cluster

gcloud beta alloydb clusters restore RESTORED_CLUSTER_ID \
    --project=WORKLOAD_PROJECT_ID \
    --region=REGION \
    --backupdr-backup=BACKUP_NAME

Create a primary instance

After Backup and DR finishes creating the cluster, create a primary instance for it.

When creating the new primary instance, you need to specify its configuration, including its size and flags; Backup and DR does not store instance configuration as part of the backup. Note that the configuration need not exactly match that of the original primary instance.

When Backup and DR finishes creating the instance, you can use it to access your restored data.

Set up read-pool instances

Finish configuring the new cluster by setting up read-pool instances, if necessary.

Restore an AlloyDB cluster to a point in time

To restore an AlloyDB for PostgreSQL cluster to a specific point in time, complete the tasks in the following sections.

Requirements

• For a successful point-in-time restore (PITR) of a CMEK-encrypted source cluster, both the source cluster key and the vault key must exist and be accessible.

• The AlloyDB for PostgreSQL service agent in the workload project must have the Cloud KMS CryptoKeyEncrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) role on the source cluster key, and the Backup and DR service agent in the backup vault project must have the Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) role on the vault key.

Restore the backup to a new cluster

Create a primary instance

After Backup and DR finishes creating the cluster, create a primary instance for it.

When creating the new primary instance, you need to specify its configuration, including its size and flags; Backup and DR does not store instance configuration as part of the backup. Note that the configuration need not exactly match that of the original primary instance.

When Backup and DR finishes creating the instance, you can use it to access your restored data.

Set up read-pool instances

Finish configuring the new cluster by setting up read-pool instances, if necessary.

List the backups in the backup vault

List the backups and select the backup to restore using gcloud CLI:

1. Find the data source ID using the following command:

      gcloud backup-dr data-source-references fetch-for-resource-type alloydb.googleapis.com/Cluster \
        --location=REGION \
        --project=WORKLOAD_PROJECT_ID \
        --filter='dataSourceGcpResourceInfo.gcp_resourcename="projects/WORKLOAD_PROJECT_NUMBER/locations/REGION/clusters/CLUSTER_NAME "'
    ```
   

2. List the backups using the following command:

      gcloud backup-dr backups list \
        --project=VAULT_PROJECT_ID \
        --location=REGION \
        --backup-vault=BV_ID \
        --data-source='projects/VAULT_PROJECT_ID/locations/REGION/backupVaults/BV_ID/dataSources/DS_ID'
   

Replace the following:

• REGION: the Google Cloud region.

• WORKLOAD_PROJECT_ID: the ID of the project where your AlloyDB cluster is located.

• WORKLOAD_PROJECT_NUMBER: the number of the project where your AlloyDB cluster is located.

• CLUSTER_NAME: the name of your AlloyDB cluster.

• VAULT_PROJECT_ID: the ID of the project that contains the backup vault.

• BV_ID: the ID of the backup vault.

• DS_ID: the ID of the data source.

What's next

• Back up AlloyDB clusters to a backup vault
• Manage data sources in the Google Cloud console
• Manage backups in the Google Cloud console