You can restore a backup of a Cloud Spanner database into a new database. The
restored database will have all the data and schema from the original database
version_time of the backup, including all database options that are set
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.
It will not include the internal data of any change streams. When you restore
from a backup, the restored backup resides in the same instance, region, and
project as its source backup. If you need to restore from 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, then restore from the copied backup.
You can use restore from a backup in the following ways:
- In the Google Cloud console
- Using the Google Cloud CLI
- Using the client libraries
- Using the REST or RPC APIs
For an overview of backup and restore, see About backup and restore.
How restore from a backup works
When you restore a Spanner database, you must specify a source
backup and a new target database. You cannot restore to an existing database.
The newly restored 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
compute capacity of the instances does not need to be the same.
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 Spanner. The restored database, by default, uses the same encryption configurations as the backup. You can override this behavior by specifying a different encryption configuration when restoring the database. For more information, see restore from a CMEK-enabled backup.
Restore a backup to a different region or project
If you need to restore the backup to a different region or project, first, copy the backup to the desired region or project. Copied backups are restorable as soon as the copy finishes. You can restore the backup either in the destination instance or in any instance that has the same instance configuration as the destination instance. 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). If you have copied the backup to a different project, and if you want to restore it there, make sure that your destination project has enough node quotas required for the restore. Restoring a copied backup works the same way as a normal restore.
CREATING: Spanner begins restoring by creating a new database and mounting files from the backup. During this initial
CREATINGstate, the restored database is not yet ready for use. This state typically completes within one hour. Once the
CREATINGstate is complete, your database is ready to use.
Note the following caveats regarding the
- If you are restoring to a different instance, the restore operation belongs to the instance containing the restored database, not the instance containing the backup.
- Spanner will not allow you to delete the backup while it is
being restored. You can delete it after the restore completes and the
database enters the
READYstate, or if you cancel the restore operation.
- An instance can have at most ten databases in the
CREATINGstate due to restoration from backups. You will not be able to restore another backup to the instance until one of the ten restored databases transitions to the
READYstate, described below.
READY_OPTIMIZING: After Spanner mounts the backup, it starts to copy the backup's data into the new database while optimizing its stored size. Your database is ready for use during this process. Depending on the amount of data involved, this phase of the restore might take days to complete.
While you can use your database as usual during
READY_OPTIMIZING, the following caveats apply:
- Read latencies might be slightly higher than usual.
- Storage metrics display the size of the new database, not the backup. Therefore, with the data transfer still in progress, Spanner storage metrics might show results that do not reflect the total size of all your data.
- As with the
CREATINGstate, Spanner will not allow you to delete the mounted backup.
READY: Once the copy-and-optimize operation completes, the database transitions to the
READYstate. The database is fully restored, and no longer references or requires the backup.
Access control (IAM)
spanner.restoreAdmin gives you permission to restore from a backup.
For more information, see Access control with IAM.
There is no charge for restoring from a backup.
Learn more about backup and restore.
Learn about working with backups using Google Cloud console.
Learn about working with backups using Google Cloud CLI.
Learn about working with backups using client libraries.