Cloud Spanner backup and restore lets you create backups of 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. When you create a backup, the backup resides in the same instance, region, and project as its source database. If you need to restore the backup in a different region or project for compliance or business continuity reasons, you can copy the backup to an instance in a separate region or project. To retain backups longer than a year, we recommend exporting your database. For protection against logical data corruption, Spanner also offers point-in-time recovery. You can also enable database deletion protection to prevent the accidental deletion of databases.
You can backup and restore in the following ways:
- In the Google Cloud console
- Using the gcloud CLI
- Using the client libraries
- Using the REST or RPC APIs.
Data consistency: Backups are a transactionally and externally consistent copy of a Spanner database at the
version_timeof the backup.
Replication: Backups reside in the same instance as their source database and are replicated in the same geographic locations. For regional instances, the backup is stored in each of the three read-write zones. For multi-regional instances, the backup is stored in all zones that contain either a read-write or read-only replica. If you need to store the backup of your database in a different region or project, you can copy the completed backup from the source instance to a destination instance located in a different region or project. For more information, see copy a backup.
Automatic expiration: All backups have a user-specified expiration date which determines when it will be automatically deleted. Spanner deletes expired backups asynchronously, so there can be a lag between when a backup is expired and when it's actually deleted.
Recommended approaches for your data recovery plan
The following table describes several data recovery plans, the recommended approach to implement the plan, and the maximum retention time for the approach suggested.
|Data recovery plan||Recommended approach||Maximum retention time for suggested approach|
|Storing the backup of a database in the same instance, region, and project as its source database||Create a backup.||1 year|
|Storing the backup of a database in a different instance, region, or project from its source database (i.e., a cross-region or cross-project backup)||Create a backup, then copy it to an instance in a different region or project.||1 year|
|Storing the backup in Google Cloud Storage||Export the database to a Google Cloud Storage bucket. For a detailed comparison between backup and export, see Choose between backup and restore or import and export.||Unlimited (retained until deletion)|
|Point-in-time recovery (PITR)||To recover data from a point-in-time in the past, choose PITR. You can change the database
Access control with Identity and Access Management (IAM)
IAM lets you control access to 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 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, copy, and 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 and copy 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 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, copy, or restore a backup.
For more information, see Cloud Spanner IAM.
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. 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.
A copy of a backup is subject to the same storage costs as an original backup. If you create a copy between two instances that occupy different regions, then network egress transfer costs apply.
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. For more information, also see Storage utilization metrics.
For more complete information on backup costs, see Cloud Spanner pricing.
Learn about choosing between backup and restore or import and export.
Learn more about how to create a backup.
Learn more about how to copy a backup.
Learn more about how to restore from a backup.