Data backup and recovery overview

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

AlloyDB provides two ways to back up and recover your data:

  • Continuous backup and recovery, enabled on all clusters by default, is an AlloyDB feature that lets you create a new a cluster based on any recent state of another cluster in the same project and region.

  • Discrete backups are file-based resources that contain complete copies of your cluster's databases. AlloyDB creates them on-demand, or according to a regular schedule that you define. You can restore any of these backups into new clusters.

Continuous backup and recovery

AlloyDB lets you restore an existing cluster to any moment from its recent history, with microsecond granularity. By default, AlloyDB lets you choose any point in time up to 14 days into the past. You can configure your cluster to resize this window to as long as 35 days, or as short as one day.

Continuous backup and recovery is especially useful for restoring a cluster after an accidental large-scale data deletion, or any other situation where you need to rapidly recreate a cluster's state based on some point in the recent past.

In disaster-recovery terms, continuous backup and recovery lets AlloyDB have a recovery point objective (RPO) of zero. In other words, you can restore your cluster to the state that it held moments before a catastrophic incident, without the permanent loss of any data.

You can also use continuous backup and recovery to make an independent clone of a healthy cluster, with all its data copied over from the present moment.

On-demand or automated backups

In AlloyDB, a backup is a file-based resource containing a copy of a cluster's data from a particular moment in time.

AlloyDB has three ways of creating backups:

  • AlloyDB always creates one backup every day as part of its continuous backup and recovery system, unless you disable this feature.

    Continuous backups are incremental backups: AlloyDB stores only the data that has changed relative to previous backups, keeping the backup files as small as possible. This helps to reduce your backup storage costs.

  • You can create an on-demand backup at any time using the Google Cloud CLI, the Google Cloud console, or the API.

    On-demand backups are full backups: each backup includes all the data that was in its cluster's databases when the backup operation began.

  • If you enable an automated backup schedule, then AlloyDB creates additional backups regularly, according to your preferences.

    Automated backups are incremental, similar to continuous backups. If you configure automated backups to use a retention window longer than 35 days, then AlloyDB might store multiple chains of incremental backups to cover the necessary time span.

As with your cluster's databases, AlloyDB encrypts backup data through either the default Google-managed encryption or customer-managed encryption keys.

Backup creation requirements

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.

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 a backup exists independently 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.

Cluster restoration

You can restore a cluster in AlloyDB by creating a new cluster that contains all of the original cluster's data from some point in the past. The two ways that you can specify this point correspond to the two general kinds of backups that AlloyDB supports:

  • To perform a point-in-time restore of a cluster's recent state, specify both a source cluster and a timestamp when creating a new cluster. The new cluster must be in the same region as the source cluster, but can be in a different Google Cloud project.

  • To restore a cluster from a backup, specify that backup when creating a new cluster. The new cluster must be in the same region as the backup, but can be in a different Google Cloud project.

In both cases, AlloyDB creates a new cluster and then initiates a long-running operation to load the backed-up data into that cluster's storage. After this operation completes, you create a primary instance in that cluster to access the data.

To learn more, see Restore from a backup.

Backup retention and deletion

The files that AlloyDB creates to enable continuous backup and recovery have a default retention period of 14 days. You can adjust this period to any number of days between 1 and 35, or you can disable continuous backup to prevent AlloyDB from retaining these files at all.

On-demand and automated backups have a retention period of up to one year. If you enable automated backups on your cluster, you can either set a retention period, or use the default period of 14 days.

Backups older than their retention period might still appear when you view your project's backups. Expired backups don't incur storage costs, but they are subject to automated deletion. If you need to delete backups before the system deletes them, you can manually delete your backups.

What's next