About Backups

Stay organized with collections Save and categorize content based on your preferences.

This page describes the backup and recovery features that you can use to protect your data in AlloyDB for PostgreSQL databases.

Backups are efficient and independent

Backups you create from your AlloyDB data are managed entirely by AlloyDB's storage layer. This means that backup and restore operations have no impact on the read and write performance of your AlloyDB cluster, as they are performed by separate resources from those that store and query that cluster's data.

This separation of storage resources also means that a backup is wholly independent from its original cluster. You can restore from that backup even if its source cluster has been deleted.

To learn more about how AlloyDB's storage layer enables this, see AlloyDB for PostgreSQL under the hood: Intelligent, database-aware storage.

Taking backups

You can take backups on demand whenever you want, and you can schedule automatic backups to be taken on a recurring basis.

On-demand backups remain until you delete them. Automatic backups also remain until you delete them, unless you specify a retention period for them when you define the backup schedule.

Whether the backup is on-demand or automatic, AlloyDB prepares to create a new backup by checking the following about the cluster to back up:

  • The cluster's state is "Ready".
  • The cluster has a primary instance.
  • The primary instance's state is "Ready".

If all of these checks pass, then AlloyDB starts a long-running operation to create the backup.

Restoring from a backup

When your restore from a backup, you specify a new cluster in the same region as the backup. AlloyDB creates that cluster and then initiates a long-running operation to restore the data in the backup to that cluster's data storage. After this operation completes, you create a primary instance in that cluster in order to access the data.