Create a backup

You can create a backup of any Spanner database. These backups are complete, in the sense that they contain all of the data in the database (including the schema and secondary indexes) at the version_time of the backup. Any modifications to the data or schema after the version_time are not included in the backup. Backups include all database options that are set with the ALTER DATABASE SET OPTIONS command, but do not include Identity and Access Management (IAM) policies. When you create a backup, the backup resides in the same instance, region, and project as its source database.

You can create a backup in the following ways:

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

How create a backup works

When you create a backup, you must specify a source database, a name for the backup resource, and an expiration date (up to 1 year from backup creation time). You can also optionally specify a version_time, which lets you backup your database to an earlier point in time. The version_time field is typically used to either synchronize the backups of multiple databases or recover data using point-in-time recovery. If version_time is not specified, then it is set to the create_time of the backup. The system creates a backup resource and a long-running backup operation to track the progress of the backup. The newly created backup resides in the same instance, region, and project as its source database.

To ensure external consistency of the backup, Spanner pins the contents of the database at create_time. This prevents the garbage collection system from removing the relevant data values for the duration of the backup operation. Then, every read-write and read-only zone in the instance begins copying the data in parallel. If any zone is temporarily unavailable, the backup is not complete until the zone comes back online and finishes. Backups are restorable as soon as the operation is complete. For multi-region instances, all read-write and read-only zones in all regions must complete their backup replicas before the backup is marked as restorable.

Backups also include the schema of a database's change streams, but not any existing change records. Change stream data is meant to be streamed out and consumed near-simultaneously with the changes it describes. As such, Spanner excludes this data from backups.


Spanner backups, like databases, are encrypted by either Google-managed or customer-managed encryption. By default, a backup uses the same encryption configuration as its database, but you can override this behavior by specifying a different encryption configuration when creating the backup. If the backup is CMEK-enabled, it is encrypted using the primary version of the KMS key at the time of backup creation. Once the backup is created, its key and key version cannot be modified, even if the KMS key is rotated. For more information, see create a CMEK-enabled backup.

Resource hierarchy

Backups are resources in Spanner. Each backup resource is organized under the same instance as its source database in the resource hierarchy and has a resource path in the form projects/<project>/instances/<instance>/backups/<backup>. A backup continues to exist even after its source database has been deleted, but it cannot outlive its parent instance. To prevent accidental deletion of backups, you cannot delete a Spanner instance if there are backups. If you want to delete the instance, we recommend restoring the backup, then exporting the restored database, before deleting the backup and the instance.

Backup time and performance

When performing a backup, Spanner creates a backup job to copy data directly from the database to backup storage, and sizes this job based on the size of the database. This backup job does not use CPU resources allocated to the database's instance so it does not affect the instance's performance. Moreover, compute load on the database's instance does not affect the speed of the backup operation. To track the progress and completion of a backup operation, see Show backup progress.

As a general point of reference, most backups take 1-4 hours. Some backups might take longer due to their size or because there is an internal queueing for resources. If a backup is taking longer than usual when no other factors have changed, it might be due to a delay in scheduling the backup task in a zone. This can sometimes take up to 30 minutes. We recommend that you do not cancel and restart the backup, as it's likely you'll encounter the same scheduling delay with the new backup operation.

Access control (IAM)

The roles spanner.backupAdmin and spanner.backupWriter give you permission to create a backup. With either of these roles, you can invoke a create backup request on the instance. For more information, see Access control with IAM.


You are billed based on the amount of storage used by your backups per unit time. Billing begins once the create backup operation is complete and will continue until the backup has been deleted. A completed backup is billed for a minimum of 24 hours. If you create a backup, then delete it a minute after it finishes, you are still billed for 24 hours.

What's next