Stay organized with collections
Save and categorize content based on your preferences.
Spanner point-in-time recovery (PITR) provides protection against
accidental deletion or writes. For example, if an operator inadvertently writes
data or an application rollout corrupts the database, with PITR you can recover
the data from a point-in-time in the past (up to a maximum of seven days)
seamlessly. If you need longer-term retention of data, you can use either
Backup and Restore or Export and Import.
By default, your database retains all versions of its data and schema for one
hour. You can increase this time limit to as long as seven days through the
version_retention_period
option. For instructions, see Set the retention period.
Spanner stores earlier versions of data at microsecond granularity and the
database maintains an earliest_version_time,
which represents the earliest time in the past that you can recover earlier versions
of the data.
Ways to recover data
There are two ways to recover data:
To recover a portion of the database, perform a stale read
specifying a query-condition and timestamp in the past, and then write the
results back into the live database. This is typically used for surgical
operations on a live database. For example, if you accidentally delete a
particular row or incorrectly update a subset of data, you can recover it
with this method. For instructions, see recovering a portion of your database.
To recover the entire database, backup or
export the database specifying a timestamp in the
past and then restore or import it to a new database. This is typically used
to recover from data corruption issues when you have to revert the
database to a point-in-time before the corruption occurred. Note that
backing up or exporting a database could take several hours and that you
cannot restore or import to an existing database. For instructions, see
recovering the entire database.
Performance considerations
Databases with longer retention periods and, in particular, those that
frequently overwrite data, use more system resources. This can affect how your
database performs, especially if your instance is not provisioned with enough
compute capacity. If your database has a very high overwrite rate
(for example, if your database is overwritten multiple times per day), you might
consider increasing the retention period gradually and
monitoring the system.
Here are some things to be aware of:
Increased storage utilization. We recommend setting up
storage alerts to ensure that you
don't exceed the storage limit. When you
increase the retention period, keep in mind that storage usage will increase
gradually as the database accumulates earlier versions of data. This is because
the old data that would have expired under the previous retention period, is no
longer expired. So, for example, if you increase the retention period from 3
days to 7 days, you need to wait for 4 days for database storage usage to
stabilize. We also provide instructions for
estimating the storage increase.
Increased CPU usage and latency. Spanner uses additional computing
resources to compact and maintain earlier versions of data.
Monitor your instance and database
to ensure that latency and CPU utilization remain at acceptable levels.
Increased time to perform schema updates. An increased retention period
means that schema versions
must be retained for longer durations potentially causing schema updates to be
throttled while
waiting for server resources. Make sure that you are following
best practices for schema updates
and staying within the limits for schema updates.
Pricing
There is no additional charge for using PITR. However, if you
increase the version retention period of your database from the default one hour,
your database storage and compute capacity costs might increase. Your on-demand
backup cost is unaffected because only a single version
of your database is stored. For more information, see the Performance
considerations section. Before increasing a database's version
retention period, you can estimate the expected increase in database storage.
For general information about how Spanner is charged, see
Spanner pricing.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-28 UTC."],[],[],null,["# Point-in-time recovery (PITR) overview\n\nSpanner point-in-time recovery (PITR) provides protection against\naccidental deletion or writes. For example, if an operator inadvertently writes\ndata or an application rollout corrupts the database, with PITR you can recover\nthe data from a point-in-time in the past (up to a maximum of seven days)\nseamlessly. If you need longer-term retention of data, you can use either\n[Backup and Restore](/spanner/docs/backup) or [Export and Import](/spanner/docs/export).\n\nBy default, your database retains all versions of its data and schema for one\nhour. You can increase this time limit to as long as seven days through the\n[`version_retention_period`](/spanner/docs/reference/rest/v1/projects.instances.databases#Database.FIELDS.version_retention_period)\noption. For instructions, see [Set the retention period](/spanner/docs/use-pitr#set-period).\nSpanner stores earlier versions of data at microsecond granularity and the\ndatabase maintains an [`earliest_version_time`](/spanner/docs/reference/rest/v1/projects.instances.databases#Database.FIELDS.earliest_version_time),\nwhich represents the earliest time in the past that you can recover earlier versions\nof the data.\n| **Note:** PITR provides additional insurance against logical data corruption, but does not protect you in case a user accidentally deletes the database. Make sure that you have other recovery options in place and that access to roles that include the [`spanner.databases.drop`](/spanner/docs/iam#databases) permission are set appropriately. For more information, see [Using IAM securely](/iam/docs/using-iam-securely). You can also enable [database deletion protection](/spanner/docs/prevent-database-deletion) to prevent the accidental deletions of databases.\n\nWays to recover data\n--------------------\n\nThere are two ways to recover data:\n\n- To **recover a portion of the database** , perform a [stale read](/spanner/docs/reads#perform-stale-read)\n specifying a query-condition and timestamp in the past, and then write the\n results back into the live database. This is typically used for surgical\n operations on a live database. For example, if you accidentally delete a\n particular row or incorrectly update a subset of data, you can recover it\n with this method. For instructions, see [recovering a portion of your database](/spanner/docs/use-pitr#recover-portion).\n\n- To **recover the entire database** , [backup](/spanner/docs/backup) or\n [export](/spanner/docs/export) the database specifying a timestamp in the\n past and then restore or import it to a new database. This is typically used\n to recover from data corruption issues when you have to revert the\n database to a point-in-time before the corruption occurred. Note that\n backing up or exporting a database could take several hours and that you\n cannot restore or import to an existing database. For instructions, see\n [recovering the entire database](/spanner/docs/use-pitr#recover-entire).\n\nPerformance considerations\n--------------------------\n\nDatabases with longer retention periods and, in particular, those that\nfrequently overwrite data, use more system resources. This can affect how your\ndatabase performs, especially if your instance is not provisioned with enough\n[compute capacity](/spanner/docs/compute-capacity). If your database has a very high overwrite rate\n(for example, if your database is overwritten multiple times per day), you might\nconsider increasing the retention period gradually and\n[monitoring the system](/spanner/docs/monitoring-cloud#storage).\nHere are some things to be aware of:\n\n- **Increased storage utilization** . We recommend setting up\n [storage alerts](/spanner/docs/storage-utilization#alerts) to ensure that you\n don't exceed the [storage limit](/spanner/quotas#database_limits). When you\n increase the retention period, keep in mind that storage usage will increase\n gradually as the database accumulates earlier versions of data. This is because\n the old data that would have expired under the previous retention period, is no\n longer expired. So, for example, if you increase the retention period from 3\n days to 7 days, you need to wait for 4 days for database storage usage to\n stabilize. We also provide instructions for\n [estimating the storage increase](/spanner/docs/use-pitr#estimate-storage).\n\n- **Increased CPU usage and latency** . Spanner uses additional computing\n resources to compact and maintain earlier versions of data.\n [Monitor your instance and database](/spanner/docs/monitoring-console#view-current-status)\n to ensure that latency and CPU utilization remain at acceptable levels.\n\n- **Increased time to perform schema updates** . An increased retention period\n means that [schema versions](/spanner/docs/schema-updates#schema_versions_created_during_schema_updates)\n must be retained for longer durations potentially causing schema updates to be\n [`throttled`](/spanner/docs/reference/rest/v1/UpdateDatabaseDdlMetadata#FIELDS.throttled) while\n waiting for server resources. Make sure that you are following\n [best practices for schema updates](/spanner/docs/schema-updates#best-practices)\n and staying within the [limits for schema updates](/spanner/docs/schema-updates#frequency).\n\nPricing\n-------\n\nThere is no additional charge for using PITR. However, if you\nincrease the version retention period of your database from the default one hour,\nyour database storage and compute capacity costs might increase. Your on-demand\n[backup](/spanner/docs/backup) cost is unaffected because only a single version\nof your database is stored. For more information, see the [Performance\nconsiderations](#performance) section. Before increasing a database's version\nretention period, you can [estimate the expected increase in database storage](/spanner/docs/use-pitr#estimate-storage).\n\nFor general information about how Spanner is charged, see\n[Spanner pricing](/spanner/pricing).\n\nWhat's next\n-----------\n\n- Learn more about how to [recover data with PITR](/spanner/docs/use-pitr)."]]