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:
- 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 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.
Encryption
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.
Pricing
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
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.