Copy a backup

Spanner backup and restore lets you copy a backup of your Spanner database from one instance to another instance in a different region or project, to provide additional data protection and compliance capabilities. The copied backup has the same key features as the original backup. Additionally, you can restore a copied backup in the same instance as the copied backup to support cross-region and cross-project backup and restore use cases.

You can copy a backup in the following ways:

For an overview of backup and restore, see About backup and restore.

Common cross-region use cases

Some common cross-region use cases for copying a backup include the following:

  • Maintain a backup in another region for compliance and regulatory requirements.

    For example, you can copy a backup of your database to an instance in a region that is at a minimum distance away from your production data to meet compliance requirements.

  • Maintain a backup in a separate region for disaster recovery and business continuity purposes.

    For example, you can copy a backup database to a destination instance for disaster recovery purposes with non-zero Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Then, when needed, you can restore the database from the copied backup in the destination instance. (If your application has zero-RTO and zero-RPO requirements, we recommend Spanner multi-region configurations for your disaster recovery plans.)

Common cross-project use cases

Some common cross-project use cases for copying a backup include the following:

  • Maintain a backup copy in a separate project to meet operational, security, or compliance requirements.

  • Copy and move data among development, test, and production projects.

    For example, if you want to move data from your production project to a test project, you can create a backup of your production data, then copy your backup to the test project. Once the copy operation is complete, you can restore the copied backup to an instance in the test project.

  • Move your database from one project to another (Note that there might be some downtime during the migration).

How copy backup works

You can copy a backup to a destination instance in a different region or project by specifying a source backup, a destination backup, and an expiration date up to one year from the source backup creation time. This means that the value for expiration_date must be at least six hours from the time the current copy request is processed and at most 366 days after the source backup create_time.

At the beginning of the copy backup request, Spanner creates a backup resource and a long-running backup operation to help track the progress of the backup. The backup is copied to every read-write and read-only zone in the destination instance. If a zone is temporarily unavailable, the backup copy does not complete until the zone comes back online. You are not able to delete the destination instance during the copy. To track the progress and completion status of the copy backup operation, follow the steps in Show backup progress. After the copy is complete, you can delete the source backup if you don't need it anymore. Once the copying completes, you can use operations such as GetBackup, UpdateBackup, and DeleteBackup with the copied backup.

Prerequisites for initiating copy of a backup

If you are copying a backup to an instance in a different region or project, you need to set up and configure the destination instance first. The destination instance is the instance where the copy of your backup resides. It can be as small as 100 processing units, and it does not need to have the same instance configuration as the source instance (the instance where your source backup lives). Before restoring, make sure that the destination instance has enough nodes or processing units provisioned to support the database size according to the 4TB per node storage limit (e.g. You need at least 2 nodes to restore a 8TB backup). To create a new destination instance, see Create and manage instances.

Additional considerations

Additional considerations include the following:

  • When you copy a backup from a source instance to a destination instance, the copied backup exists independently from its source backup. Once the copy operation is complete, there is one backup in the source instance and one backup in the destination instance. If you don't need the backup in the source instance anymore, you can delete it.
  • When you copy a backup to a regional instance, backup data is copied to each of the three read-write zones in the destination instance.
  • When you copy a backup to a multi-regional instance, the backup data is copied to each zone in the instance that contains either a read-write or read-only replica.
  • You can copy multiple backups at the same time.
  • You can update or delete the destination backup while a copying process is still in progress. If you delete the destination backup, the ongoing copy operation will cancel as a result.
  • You can restore a backup in the source instance while there is a copying operation in progress.
  • You can cancel a copy operation before it completes.

The following operations are not allowed during the copying process:

  • You cannot delete the source backup while a copy operation is in progress.
  • You cannot initiate a new copy or restore on the destination copied backup while the copy is still in progress. Once a copy has been completed, it can be copied again or restored.

Encryption

By default, a copied backup uses the same encryption configuration, either Google-managed or customer-managed (CMEK), as its source backup encryption. You can override this behavior by specifying a different encryption configuration when copying the backup. If you want the copied backup to be encrypted with CMEK when copying across regions, specify the KMS key corresponding to the destination region.

Copy time and performance

The time it takes to copy a backup depends on factors such as the size of the source backup and the destination region chosen for the copied backup. Generally, most copies complete in 1-4 hours. Some copies might take longer depending on the backup size and destination region. Copying a backup does not have any performance implications on the source instance or database. You can make multiple concurrent copies of the source backup to instances in different regions without any performance implications issues.

Access control (IAM)

To copy a backup, you must have spanner.backups.copy permission on the source backup and spanner.backups.create permission on the destination instance. These permissions are included in the roles spanner.backupAdmin and spanner.backupWriter so if you have a spanner.backupAdmin or spanner.backupWriter role on a source instance, you can invoke a copy backup request on the source backup.

Pricing

A copy of a backup is subject to the same storage costs as an original backup. Once the backup copy is complete, you are billed for the backup storage at the destination instance. If you create a copy between two instances that are in different regions, then data transfer costs apply.

For example, if you copy your database from the source multi-region instance configuration nam7 to the destination multi-region instance configuration nam-eur-asia3, the following charges apply:

  • No charge for overlapping us-central1 region
  • No charge for witness us-central2 region
  • Inter-continental data transfer charge apply twice: once for each new continent (Europe and Asia)
  • Data transfer between regions within the same continent charge apply once for us-east1
  • Data transfer between regions within the same continent charge apply once in Europe

Spanner optimizes the copying process to minimize the number of cross-region transfers. This helps to minimize the data transfer costs while providing a fast copy backup experience.

What's next