This document provides an overview of Spanner backups andbackup schedules.

Spanner lets you create full backups ofdatabases on demand and full or incremental backups using a backup schedule.Full backups store the entire data of a database, whereas incremental backupscontain only the data that has changed since a previous backup.

You can restore the backups when operator or application errorscause logical data corruption.

Backups are highly available, encrypted, and canbe retained for up to a year from the time they are created. When you create abackup, the backup resides in the same instance, region, and project as itssource database. If you need to restore the backup in a different region orproject for compliance or business continuity reasons, you can copy the backupto an instance in a separate region or project.

Each backup has an associatedcreateTime andversionTime. ThecreateTime is thetimestamp when Spanner starts creating the backup.TheversionTime is the timestamp when the database contents are capturedin the backup. The backup contains a consistent view of the database at theversionTime.

For on-demand backups, thecreateTime andversionTime are the same bydefault. If needed, you can specify an olderversionTime when creatingan on-demand backup if it's within theversion retention periodof the database.

For scheduled backups, theversionTime is the time you choose when you createthe backup schedule. Spanner starts creating the backup within four hours oftheversionTime, so thecreateTime falls within this four-hour window.This is unlike on-demand backups, where Spanner starts creatingthe backup when it receives the request.

For example, suppose you create a backup schedule with a frequency of0 7 * * * UTC orevery day at 7:00 AM UTC. This means that for each backup, theversionTimeis set to 7:00 AM UTC and thecreateTime is a timestamp within thefour-hour window between 7:00 AM UTC and 11:00 AM UTC.

For more information about usingcreateTime andversionTime using the API,seeBackup API reference.

Key features

• Data consistency: Backups of a Spanner database aretransactionally andexternally consistent at theversionTime of the backup.

• Replication: Backups reside in the same instance as their source databaseand are replicated in the same geographic locations.Forregional instances,the backup is stored in each of the three read-write zones. Fordual-regionandmulti-regional instances,the backup is stored in all zones that contain either a read-write orread-only replica. If you need to store the backup of your database in adifferent region or project, you can copy the completed backup from the sourceinstance to a destination instance located in a different region orproject. For more information, seecopy a backup.

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

Backup creation

When you create a backup, the backup resides in the same instance,region, and project as its source database.

A backup contains the following information from the database at theversionTime of the backup:

• A full backup contains all of the data. An incremental backup contains onlythe data that has changed since a previous backup.
• Schema information, including table names, fields, data types, secondaryindexes, change streams, and the relationships between these entities.
• All database options that are set with theALTER DATABASE SET OPTIONScommand.

A Spanner backup does not include the following information:

• Any modifications to the data or schema after theversionTime.
• Identity and Access Management (IAM) policies.
• Change stream data records. Although the change streams schema is stored,the change stream data is meant to be streamed out and consumednear-simultaneously with the changes it describes.

To help ensure external consistency of the backup, Spanner pinsthe contents of the database atversionTime.This prevents the garbage collectionsystem from removing the relevant data values for the duration of the backupoperation. Then, every read-write and read-only zone in the instance beginscopying the data in parallel. If any zone is temporarily unavailable, the backupis not complete until the zone comes back online. Backups arerestorable as soon as the operation is complete. For multi-region instances, allread-write and read-only zones in all regions must complete their backupreplicas before the backup is marked as restorable.

Backup schedules

Spanner lets you schedule full orincremental backups for databases. An incremental backup contains only thedata that has changed since a previous backup, whereas full backups store theentire contents of the database. You can specify the backupschedule type (full or incremental) and frequency for Spannerto create backups.

A full backup schedule can create a backup every 12 hoursor more. An incremental backup schedule can create a backup every 4 hours ormore.

Spanner offers incremental backups for your databasethrough a backup schedule. You can't create an incremental backup on demand.

The backup creation begins within a four-hour window of the scheduled time.You can have a maximum of four backup schedules per database.

Note: This feature is available with the Spanner Enterprise edition and Enterprise Plus edition. For more information, see theSpanner editions overview.

Incremental backups formchains between full backups. The first backupcreated by an incremental backup schedule is a full backup.The consecutive backups created in the chain are incremental backups,each containing only the data that has changed since the previous backup in thechain.

Spanner permits up to 13 incremental backups per chain, inaddition to the initial full backup. A chainis identified by the correspondingincrementalBackupChainId value.When a chain reaches its maximum length,Spanner creates a new chain, beginning with the initial fullbackup.

In some scenarios, Spanner might create a new chain beforethe maximum chain length occurs. The following are a few of the scenarios:

• The oldest full backup was taken 28 or more days ago.
• The newest backup in the chain is deleted.
• The incremental backup schedule is modified.

Here are some factors that can help you make a decisionabout using incremental backups:

• Encryption: Incremental backups support encryption usingGoogle-owned and Google-managed encryption keys only, even if the database isencrypted by a customer-managed encryption key (CMEK).

• Restoration: Restoring an incremental backup might take longer thanrestoring a full backup that contains the same data.

• Deletion: If you delete a backup in a chain or it expires,Spanner might still keep the backup to support newer backupsin the chain, if any exist. Spanner needs all the older backupsin the chain to restore an incremental backup. To delete all the data in achain of backups, including that of expired or deleted backups, delete allthe backups in the chain.

• Retention: Each backup schedule has the following terms that offerinformation about the schedule:

  • creation_interval: represents the specified schedule frequency for thebackupschedule.
  • retention_duration: represents how long the backups created by theschedule are retained.For a given chain, the oldest full backup is retained past its originalexpiration date if it is needed to support newer backups in the chain.The total retention duration for the full backup is at most the lower of thefollowing values:
    • retention_duration + 28 days
    • retention_duration + (creation_interval*14)

• Backup copy: When you copy an incremental backup, Spanneralso copies all the older backups in the chain required to restore the copiedbackup. If the destination instancealready contains a backup chain ending with an older backup that was copiedfrom the same source chain, Spanner avoids creating redundantcopies of existing backups. Instead, Spanner copies only theincremental backup and any older backups not present in the destination chain,and appends these backups to the existing chain. Spannercharges you based on the total storage used.

  For example, if you set up a daily incremental backup schedule and copy thelatest backup each day, the destination instance maintains a backup chain thatmirrors the source chain. Spanner doesn't duplicatepreviously copied backups within the chain during subsequent copy operations.

  While Spanner aims to avoid redundant copies, in raresituations, Spanner might need to copy all the older backupsin the chain, even if previously copied backups already exist in thedestination instance.

For more information about creating incremental backups, seeCreate and manage backup schedules.

Default backup schedules

When you create a new Spanner instance, you can specify if youwant Spanner to create a default backup schedule for every newdatabase in the instance. The default backup schedule creates a full backupevery 24 hours. These backups have a retention period of 7 days. You can editor delete the default backup schedule once it's created.

Default backup schedules are automatically enabled for all new instances. Youcan enable or disable default backup schedules in an instance when creatingthe instance or by editing the instance later.

You can enable default backup schedules for existing instances.However, default backup schedules don't apply to existing databases in theinstance. Default backup schedules only apply to new databases in the instance.

The default backup schedule takes 24 hours to become active and start creatingbackups.

You must delete all backups in an instance before you delete an instance. If youare creating and deleting instances for testing purposes, you can delete the newinstance within 24 hours to avoid manually deleting its backups.

For instructions on enabling or disabling default backup schedules, seeEdit the default backup schedule type.

Storage costs for full and incremental backups

Each Spanner backup has the following fields that offerinformation about storage consumption:

• exclusiveSizeBytes: shows the number of bytes required by the backup. Thissize represents the billable size of the backup.
• freeableSizeBytes: shows the number of bytes that are released if youdelete the backup.
• oldestVersionTime: shows theversionTime of the oldest full backup inthe chain, even if that backup has expired. You can use this field tounderstand which data is being stored.

Incremental backups can save you storage costs. An incremental backup mighthave a significantly smallerexclusiveSizeBytesfield than a full backup as the incremental backup only needs to store thechanges since the previous backup in the chain.Adding this field value for each backup in the chainreflects the total number of bytes used by thebackups in the chain.

An incremental backup is dependent on all older backups in the same chainfor restoration.This means that if a newer incremental backup exists, the data of all olderbackups in the chain cannot be deleted from the system and thefreeableSizeBytes field for all older backups in the same chain is zero.

Consider that you created a full backup schedule and an incremental backupschedule for a database that has a size of 100 GB and increases by10 GB every day. The following table shows possible storage costs forthese backup schedules:

Over 5 days, the full backup schedule uses 600 GB of storage, while theincremental backup schedule uses about 140 GB of storage.For an incremental backup schedule, the full backup size is the sum of the sizesof all backups in the chain, up to that backup and is reflected in thesizeBytes field.

Comparing backup storage to database storage

The storage size of a backup can be smaller or larger than the storage size ofthe source database when the backup was created.

A backup's storage can be smaller than the database's storage because the backupcontains only one version of the data, whereas the live database can containmultiple versions of data due to ongoing operations. Differences in data formatand compression can also result in a smaller backup size.

Conversely, the storage of a backup can be larger than the database's storage,depending on the situation of the database and the time when you take thebackup.

For similar reasons, when you restore a database from a backup, the backup'sstorage can be larger than the database's storage. This might occur if a largeset of data was deleted and compacted after the backup was taken. Therefore, thebackup size depends on when the backup was taken and the subsequent operationson the database.

There is no formula to predict the exact ratio of a backup's size relative tothe live database. For a database with a high rate of writes (ahot database),the backup is likely smaller than the live database. However, in some raresituations, the backup size can be larger.

How backup copying works

Spanner lets you copya backup of your Spanner database from one instance to anotherinstance in a different region or project, to provide additionaldata protection and compliance capabilities.

You can't copy a backup if the target or source Google Cloud region is down.To protect your data if there's a region outage, you need to periodically copyyour backups to a location outside of the affected region.

The copied backup hasthe samekey features as the originalbackup. Additionally, you canrestorea copied backup in the same instance as the copied backup to supportcross-region and cross-project backup and restore use cases.

Where Spanner backups are stored

Backups are resources in Spanner.Eachbackup resource is organizedunder the same instance as its source database in theresource hierarchyand has a resource path that uses the following format:

projects/PROJECT_ID/instances/INSTANCE_ID/backups/BACKUP_NAME

Replace the following:

• PROJECT_ID: the project ID.
• INSTANCE_ID: the instance ID.
• BACKUP_NAME: the backup name.

A backup continues to exist even after its source database has been deleted,but it can't outlive its parent instance. To prevent accidental deletion ofbackups, you can't delete a Spanner instance if it hasbackups. If you want to delete the instance, we recommend restoring thebackup, thenexporting the restored database, beforedeleting the backup and the instance.

Encryption

Spanner backups, like databases, are encrypted by eitherGoogle-owned and Google-managed encryption keys or bycustomer-managed encryption keys (CMEK). By default, abackup uses the sameencryption configurationas its database, but you can override this behavior by specifying a differentencryption 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 backupcreation. After the backup is created, its key and key version can't bemodified, even if the KMS key is rotated. For more information, seecreate a CMEK-enabled backup.

A copied backup uses the same encryption configuration, eitherGoogle-owned and Google-managed encryption keys orcustomer-managed encryption keys (CMEK), as its sourcebackup encryption.You can override this behavior by specifying a different encryptionconfiguration when copying the backup. If you want the copied backup to beencrypted with CMEK when copying across regions, specify theCloud KMS keykey corresponding to the destination region.

You can specify the encryption configuration when creating or modifyingthe backup schedule. If you want the backup schedule to create backups that areencrypted by CMEK keys, you need to specify the key path.

Incremental backups support encryption using onlyGoogle-owned and Google-managed encryption keys, even if the database is encrypted bya CMEK key.

Performance

This section describes optimal backup performance in Spanner.

Performance when backing up

When performing a backup, Spanner creates a backup job to copydata directly from the database to backup storage, and sizes this job based onthe size of the database. This backup job does not use CPU resources allocatedto 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 ofthe backup operation. To track the progress and completion of a backupoperation, seeShow backup progress.

Generally, most backups take 1-4 hours. Some backups mighttake longer due to their size or because there is internal queueing forresources. If a backup is taking longer than usual when no other factors havechanged, 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 canceland restart the backup, as it's likely you'll encounter the same schedulingdelay with the new backup operation.

Performance when copying a backup

The time it takes to copy a backup depends on factors such as the size of thesource backup and the destination region chosen for the copied backup.Generally, most copies complete in 1-4 hours. Some copies might take longerdepending on the backup size and destination region. Copying a backupdoesn't have any performance implications on the source instance or database.You can make multiple, concurrent copies of the source backup to instances indifferent regions without any performance implications.

When you copy an incremental backup, Spanner also copies all ofthe older backups in the chain required to restore the copied backup. To improveperformance, Spanner copies all the backups simultaneouslyinstead of sequentially. Spanner also attempts to avoid copyingolder backups in the same chain when possible. For more information, seeIncremental backups.

Delete a backup

When you delete a backup in an incremental backup chain, you can't recoverstorage if there are newer backups present in the chain. The newer backupsdepend on the data present in the deleted backup and theolder backups in the chain. Spanner retains thedata and only releases the storage when all the newer incremental backupsexpire. ThefreeableSizeBytes field shows how much storage space you canregain if you delete the backup.

Pricing

You are billed based on the amount of storage used by your backups per unittime. Billing begins after the backup operation is complete and continuesuntil the backup is deleted. A completed backup is billed for a minimumof 24 hours. If you create a backup and then delete it soon after it finishes,you are still billed for 24 hours.

A copy of a backup is subject to thesame storage costsas an original backup. If you create a copy between two instances that occupydifferent regions, thenoutbound data transfer costsapply.

For example, if you copy your database from the source multi-region instanceconfigurationnam7 to the destination multi-region instance configurationnam-eur-asia3, the following charges apply:

• No charge for overlappingus-central1 region
• No charge for witnessus-central2 region
• Inter-continental data transfer charge apply twice: once for each newcontinent (Europe and Asia)
• Data transfer between regions within the same continent charge apply onceforus-east1
• Data transfer between regions within the same continent charge apply oncein Europe

Spanner optimizes the copying process to minimize the number ofcross-region transfers. This helps to minimize the data transfer costs whileproviding a fast copy backup experience.

Backups are stored and billed separately. Backup storage does not affectbilling for database storageordatabase storage limits. For moreinformation, also seeStorage utilization metrics.

For more complete information on backup costs, seeSpannerpricing.

What's next

• To create backups, seeCreate backups.

• To manage backups, seeManage backups.