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. These backups vary in size, depending upon various factors. Some continuous backups might be as large as full backups, especially after previous backups have been deleted.

  • 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.

On-demand backups locations

For on-demand backups, AlloyDB backup locations include:

Default backup location

If you don't specify a storage location, your backups are stored in the location of your AlloyDB cluster. For example, if your AlloyDB instance is in us-central1 (Iowa), your backups are stored in the us-central1 (Iowa) location by default.

Cross-region backup location

AlloyDB lets you select a custom cross-region location for your backup data, which expands the set of regions where you can store your backups. This is useful for retaining the ability to restore if your cluster region becomes unavailable.

When selecting a cross-region location for a backup, consider the following:

  • Cost: one cluster in your instance may be in a lower-cost region than the others.
  • Proximity to your application server: you might want to store the backup as close to your serving application as possible.
  • Storage utilization: you need enough storage space to keep your backup as it grows in size. Depending on your workload, you might have clusters of different sizes or with different disk usages. This might factor into which cluster you choose.

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