Backup and Restore


Cloud Spanner Backup and Restore lets you create backups of Cloud Spanner databases on demand, and restore them to provide protection against operator and application errors which result in logical data corruption. Backups are highly available, encrypted, and can be retained for up to a year from the time they are created. If you need longer retention times, we recommend exporting your database.

You can use Backup and Restore in the following ways:

For logical data corruption, Cloud Spanner also offers point-in-time recovery.

Key features

  • Data consistency: Backups are a transactionally and externally consistent copy of a Cloud Spanner database at the version_time of the backup.

  • Replication: Backups reside in the same instance as their source database and are replicated in the same geographic locations. For regional instances, a copy of the backup is stored in each of the three read-write zones. For multi-regional instances, a copy is stored in all zones that contain either a read-write or read-only replica.

  • Automatic expiration: All backups have a user-specified expiration date which determines when it will be automatically deleted. Cloud Spanner deletes expired backups asynchronously, so there can be a lag between when a backup is expired and when it's actually deleted.

Choose between Backup and Restore or Import and Export

Cloud Spanner Import and Export serve similar use cases as Backup and Restore. The following table describes similarities and differences between them to help you decide which one to use.

Backup and RestoreImport and Export
Data consistency Both backups and exported databases are transactionally and externally consistent.
Performance impact Backups have no impact on an instance's performance. Cloud Spanner performs backups using dedicated jobs that do not draw upon an instance's server resources. Export runs as a medium-priority task to minimize impact on database performance. For more information, see task priority.
Storage format Uses a proprietary, encrypted format designed for fast restore. Supports both CSV and Avro file formats.
Portability Backups reside in the same instance as their source database and cannot be moved.

You can restore a database to any instance in the project with the same instance configuration as the backup.
Exported databases reside in Google Cloud Storage and the data can be migrated to any system that supports CSV or Avro.
Retention Backups can be retained for up to 1 year. Exported databases are stored in Cloud Storage where, by default, they are retained until they are deleted. You can customize lifecycle and retention policies.
Billing Backups are billed to your Cloud Spanner project based on the storage used per unit time. For more details, see the Billing section. Billing for import and export is more complicated due to its use of Google Cloud Storage and Dataflow. For more information, see Database export and import pricing.
Restore time Restore happens in two operations: restore and optimize. The restore operation offers fast time-to-first-byte because the database directly mounts the backup without copying the data. After the restore operation completes, the database is ready for use, though read latency might be slightly higher while it is optimizing. For more information, see How restore works. Import is slower. You need to wait for all the data to be written into the database.

How backup works


Users can create a backup of any Cloud 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 will not be 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.


Cloud Spanner backups, like databases, can be protected by CMEK or Google-managed encryption. By default, a backup uses the same encryption config as its database, but you can override this behavior by specifying a different encryption config 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.

Creation process

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

To ensure external consistency of the backup, Cloud 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 done. 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.

Resource hierarchy

Backups are resources in Cloud 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 cannot outlive its parent instance. To prevent accidental deletion of backups, you cannot delete a Cloud Spanner instance if there are backups. For users who want to delete the instance, we recommend restoring the backup and then exporting the restored database, before deleting the backup and the instance.

Backup time and performance

When performing a backup, Cloud 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 database's instance and so 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 progress and completion of a backup operation, see Show backup progress.

If a backup is taking longer than usual when no other factors have changed, it may 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 as well.

How restore works

When you restore, you must specify a source backup and a new target database. You cannot restore to an existing database. The new database must be in the same project as the backup and be in an instance with the same instance configuration as the backup. For example, if a backup is in an instance configured us-west3, it can be restored to any instance in the project that is also configured us-west3. The compute capacity of the instances does not need to be the same.

The restored database will have all the data and schema from the original database at the create_time of the backup, including all database options that are set with the ALTER DATABASE SET OPTIONS command. It will not have any IAM permissions (except for those inherited from the instance containing the restored database), and you must apply appropriate IAM permissions after the restore completes.

The restore process is designed for high-availability. The database can be restored provided that the majority quorum of the regions and zones in the instance is available.

To restore a CMEK-enabled backup, both the key and key version must be available to Cloud Spanner. The restored database, by default, uses the same encryption config as the backup. You can override this behavior by specifying a different encryption config when restoring the database. For more information, see restore from a CMEK-enabled backup.

It's important to understand that a restored database transitions between three States which are tracked by two operations.

  • CREATING state: When you initiate a restore, the system creates a new database and long-running database operation with RestoreDatabaseMetadata to track the progress of the restoration. The new database begins and remains in the CREATING state, which means it is not ready for use, until the restore operation is complete. To provide fast restore times (typically under 10 minutes), the restore operation works by mounting the files in the backup without copying them to the database.

  • READY_OPTIMIZING state: Once the restore operation completes, the database transitions to the READY_OPTIMIZING state. In this state, it is ready for use, but you may experience some slightly higher read latencies while the database reads data from the backup. Any attempt to delete the backup will fail while it is still in use for database restoration or optimzation.

    When the restore operation completes, you will get another long-running database operation with OptimizeRestoredDatabaseMetadata to track the progress of the optimization. The optimize operation copies the data from the backup to the database. If you would like to speed up the optimize process, you can increase the instance's compute capacity.

  • READY state: Once the optimization operation completes, the database transitions to the READY state. At this point, the restored database is fully performant and no longer references the backup.

An instance can have at most one database in the restore CREATING state. You will not be able to restore another backup to the instance until the restored database transitions to the READY_OPTIMIZING or READY state.


You are billed based on the amount of storage used by your backups per unit time. Billing begins once the backup operation is complete and will continue until the backup has been deleted. There is no charge for restoring from a backup.

Backups are stored and billed separately. Backup storage does not affect billing for database storage or database storage limits.

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.

For more complete information on backup costs, see the Cloud Spanner Pricing page.

Access control with IAM

IAM lets you control access to Cloud Spanner resources, which include backups and restored databases. If you are new to IAM, roles, and permissions, see IAM Overview for an introduction.

Backup resources are organized under instances in the Cloud Spanner resource hierarchy. We recommend applying IAM policies at the project level or instance level. If you need finer grain control, IAM policies can also be applied at the backup and database level as well, but this is not recommended due to complexity. Remember that backups do not contain database metadata such as IAM policies, so when you restore a database, the database will initially inherit policies from its parent instance.

This section describes the predefined roles that have access to backup and restore.

The following roles are designed specifically for backup and restore:

  • spanner.backupAdmin: has access to create, view, update, delete backups. This role can also view and manage a backup's IAM policy. This role cannot restore a database from a backup.
  • spanner.restoreAdmin: has access to restore databases from backups. If you need to restore a backup to a different instance, apply this role at the project level or to both instances. This role cannot create backups.
  • spanner.backupWriter: has access to create backups, but cannot update, or delete them. This role is intended to be used by scripts that automate backup creation.

The following roles also have access to backup and restore:

  • spanner.admin: has full access to backup and restore. This role has complete access to all Cloud Spanner resources.
  • owner: has full access to backup and restore
  • editor: has full access to backup and restore
  • viewer: has access to view backups, backup operations, and restore operations. This role cannot create, update, delete, or restore a backup.

For more information, see Cloud Spanner IAM.