Descripción general de la recuperación de un momento determinado (PITR)
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
La recuperación de un momento determinado (PITR) de Spanner brinda protección contra escrituras o eliminaciones accidentales. Por ejemplo, si un operador escribe datos de forma inadvertida o el lanzamiento de una aplicación daña la base de datos, con la PITR, puedes recuperar los datos de un momento determinado en el pasado (hasta un máximo de siete días) sin problemas. Si necesitas una retención de datos a más largo plazo, puedes usar Backup and Restore o Export and Import.
De forma predeterminada, tu base de datos retiene todas las versiones de sus datos y su esquema durante una hora. Puedes aumentar este límite de tiempo hasta siete días con la opción version_retention_period. Para obtener instrucciones, consulta Cómo establecer el período de retención.
Spanner almacena versiones anteriores de los datos con un nivel de detalle de microsegundos, y la base de datos mantiene un earliest_version_time, que representa el momento más antiguo en el pasado en el que puedes recuperar versiones anteriores de los datos.
Cómo recuperar datos
Existen dos maneras de recuperar datos:
Para recuperar una parte de la base de datos, realiza una lectura inactiva que especifique una condición de consulta y una marca de tiempo en el pasado. Luego, vuelve a escribir los resultados en la base de datos activa. Por lo general, se usa para realizar operaciones quirúrgicas en una base de datos activa. Por ejemplo, si borras accidentalmente una fila en particular o actualizas un subconjunto de datos de forma incorrecta, puedes recuperarlos con este método. Para obtener instrucciones, consulta Recupera una parte de tu base de datos.
Para recuperar la base de datos completa, crea una copia de seguridad o exporta la base de datos especificando una marca de tiempo anterior y, luego, restablécela o impórtala a una base de datos nueva. Por lo general, se usa para recuperarse de problemas de corrupción de datos cuando debes revertir la base de datos a un momento anterior a que se produjera la corrupción. Ten en cuenta que
crear una copia de seguridad de una base de datos o exportarla puede tardar varias horas y que no puedes restablecer ni importar a una base de datos existente. Para obtener instrucciones, consulta Cómo recuperar toda la base de datos.
Consideraciones de rendimiento
Las bases de datos con períodos de retención más largos y, en particular, las que reemplazan los datos con frecuencia, usan más recursos del sistema. Esto puede afectar el rendimiento de tu base de datos, en especial si tu instancia no se aprovisiona con suficiente capacidad de procesamiento. Si tu base de datos tiene una tasa de reemplazo muy alta (por ejemplo, si se reemplaza varias veces al día), puedes considerar aumentar el período de retención de forma gradual y supervisar el sistema.
Estos son algunos aspectos que debes tener en cuenta:
Mayor uso del almacenamiento Te recomendamos que configures alertas de almacenamiento para asegurarte de no exceder el límite de almacenamiento. Cuando aumentes el período de retención, ten en cuenta que el uso del almacenamiento aumentará gradualmente a medida que la base de datos acumule versiones anteriores de los datos. Esto se debe a que los datos antiguos que habrían vencido según el período de retención anterior ya no están vencidos. Por ejemplo, si aumentas el período de retención de 3 a 7 días, debes esperar 4 días para que se estabilice el uso del almacenamiento de la base de datos. También proporcionamos instrucciones para estimar el aumento de almacenamiento.
Aumento del uso de CPU y la latencia Spanner usa recursos de procesamiento adicionales para compactar y mantener versiones anteriores de los datos.
Supervisa tu instancia y base de datos para asegurarte de que la latencia y el uso de CPU permanezcan en niveles aceptables.
No se aplican cargos adicionales por usar PITR. Sin embargo, si aumentas el período de retención de versiones de tu base de datos más allá de la hora predeterminada, es posible que aumenten los costos de almacenamiento y capacidad de procesamiento de la base de datos. El costo de tu copia de seguridad bajo demanda no se ve afectado, ya que solo se almacena una versión de tu base de datos. Para obtener más información, consulta la sección Consideraciones sobre el rendimiento. Antes de aumentar el período de retención de versiones de una base de datos, puedes estimar el aumento esperado en el almacenamiento de la base de datos.
Para obtener información general sobre cómo se cobra Spanner, consulta Precios de Spanner.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-05 (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)."]]