Informações gerais da recuperação pontual (PITR, na sigla em inglês)
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
A recuperação pontual (PITR, na sigla em inglês) do Spanner oferece proteção contra
exclusão ou gravações acidentais. Por exemplo, se um operador gravar dados inadvertidamente ou um lançamento de aplicativo corromper o banco de dados, com a PITR é possível recuperar os dados de um ponto no passado (até um máximo de sete dias) sem problemas. Se você precisar de uma retenção de dados de longo prazo, poderá usar as opções
Backup e restauração ou Exportar e importar.
Por padrão, seu banco de dados retém todas as versões dos dados e do esquema por uma hora. Você pode aumentar esse limite de tempo para até sete dias com a opção
version_retention_period. Para instruções, consulte Definir o período de retenção.
O Spanner armazena versões anteriores de dados com granularidade de microssegundos, e o banco de dados mantém um earliest_version_time, que representa o primeiro horário no passado em que você pode recuperar versões anteriores dos dados.
Maneiras de recuperar dados
Há duas maneiras de recuperar dados:
Para recuperar uma parte do banco de dados, execute uma leitura desatualizada
especificando uma condição de consulta e um carimbo de data/hora no passado. Em seguida, grave os
resultados no banco de dados ativo. Isso normalmente é usado em operações cirúrgicas em um banco de dados ativo. Por exemplo, se você excluir acidentalmente uma
linha específica ou atualizar incorretamente um subconjunto de dados, poderá recuperá-lo
com este método. Para receber instruções, consulte Como recuperar uma parte do banco de dados.
Para recuperar o banco de dados inteiro, faça backup ou
exporte-o especificando um carimbo de data/hora no
passado e restaure ou importe para um novo banco de dados. Isso normalmente é usado
para recuperar problemas de corrupção de dados quando você precisa reverter o
banco de dados para um momento anterior à corrupção. Observe que
fazer backup ou exportar um banco de dados pode levar várias horas e que não é possível
restaurar ou importar para um banco de dados existente. Para receber instruções, consulte
Como recuperar todo o banco de dados.
Considerações sobre desempenho
Bancos de dados com períodos de armazenamento mais longos e, principalmente, aqueles
que normalmente substituem dados, usam mais recursos do sistema. Isso pode afetar o desempenho do seu banco de dados, especialmente se a instância não for provisionada com uma capacidade de computação suficiente. Se seu banco de dados tiver uma taxa de substituição muito alta (por exemplo, se ele for substituído várias vezes ao dia), considere aumentar o período de armazenamento gradualmente e de maneira gradual.Monitorar o sistema de dados.
Veja a seguir alguns detalhes a serem considerados:
Maior uso do armazenamento. Recomendamos configurar
alertas de armazenamento para garantir que você
não exceda o limite de armazenamento. Quando você
aumenta o período de armazenamento, lembre-se de que o uso do armazenamento aumentará
gradualmente à medida que o banco de dados acumular versões mais antigas dos dados. Isso ocorre porque os dados antigos que expirariam no período de armazenamento anterior não expiram mais. Por exemplo, se você aumentar o período de armazenamento de três para sete dias, será necessário aguardar quatro dias para que o uso do armazenamento do banco de dados se estabilize. Também fornecemos instruções para
estimar o aumento do armazenamento.
Maior uso da CPU e latência. O Spanner usa recursos de computação adicionais para compactar e manter versões anteriores de dados.
Monitore a instância e o banco de dados
para garantir que a latência e a utilização da CPU permaneçam em níveis aceitáveis.
Não há cobrança extra pelo uso da PITR. No entanto, se você aumentar o período de armazenamento de versão do banco de dados além de uma hora, os custos de armazenamento e capacidade de computação poderão aumentar. O custo do backup sob demanda não é afetado porque apenas uma versão do banco de dados é armazenada. Para mais informações, consulte a seção Considerações sobre desempenho. Antes de aumentar o período de armazenamento da versão de um banco de dados, calcule o aumento esperado no armazenamento do banco de dados.
Para informações gerais sobre como o Spanner é cobrado, consulte
Preços do Spanner.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-11 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)."]]
