Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Il recupero point-in-time (PITR) di Spanner offre protezione da eliminazioni o scritture accidentali. Ad esempio, se un operatore scrive inavvertitamente
dati o l'implementazione di un'applicazione danneggia il database, con PITR puoi recuperare
i dati da un momento specifico del passato (fino a un massimo di sette giorni)
senza problemi. Se hai bisogno di conservare i dati per un periodo più lungo, puoi utilizzare Backup e ripristino o Esportazione e importazione.
Per impostazione predefinita, il database conserva tutte le versioni dei dati e dello schema per un'ora. Puoi aumentare questo limite di tempo fino a sette giorni tramite l'opzione
version_retention_period. Per istruzioni, vedi Impostare il periodo di conservazione.
Spanner archivia le versioni precedenti dei dati con una granularità di microsecondi e il database gestisce un earliest_version_time, che rappresenta il momento più remoto nel passato in cui è possibile recuperare le versioni precedenti dei dati.
Metodi per recuperare i dati
Esistono due modi per recuperare i dati:
Per recuperare una parte del database, esegui una lettura obsoleta specificando una condizione di query e un timestamp nel passato, quindi riscrivi i risultati nel database live. Viene in genere utilizzato per operazioni
chirurgiche su un database attivo. Ad esempio, se elimini per errore una
determinata riga o aggiorni in modo errato un sottoinsieme di dati, puoi recuperarlo
con questo metodo. Per istruzioni, vedi Recuperare una parte del database.
Per recuperare l'intero database, esegui il backup o
esporta il database specificando un timestamp nel
passato, quindi ripristinalo o importalo in un nuovo database. Questo viene in genere utilizzato per risolvere i problemi di danneggiamento dei dati quando devi ripristinare il database a un momento precedente al danneggiamento. Tieni presente che
il backup o l'esportazione di un database potrebbero richiedere diverse ore e che
non puoi ripristinare o importare in un database esistente. Per le istruzioni, vedi
Recuperare l'intero database.
Considerazioni sulle prestazioni
I database con periodi di conservazione più lunghi e, in particolare, quelli che
sovrascrivono frequentemente i dati utilizzano più risorse di sistema. Ciò può influire sulle prestazioni del database, soprattutto se l'istanza non è sottoposta a provisioning con una capacità di calcolo sufficiente. Se il tuo database ha una velocità di sovrascrittura molto elevata
(ad esempio, se il database viene sovrascritto più volte al giorno), potresti
valutare la possibilità di aumentare gradualmente il periodo di conservazione e
monitorare il sistema.
Ecco alcuni aspetti da tenere presenti:
Maggiore utilizzo dello spazio di archiviazione. Ti consigliamo di configurare
avvisi di spazio di archiviazione per assicurarti di
non superare il limite di spazio di archiviazione. Quando aumenti il periodo di conservazione, tieni presente che l'utilizzo dello spazio di archiviazione aumenterà gradualmente man mano che il database accumula le versioni precedenti dei dati. Questo perché
i vecchi dati che sarebbero scaduti nel periodo di conservazione precedente non
sono più scaduti. Ad esempio, se aumenti il periodo di conservazione da 3 giorni a 7 giorni, devi attendere 4 giorni prima che l'utilizzo dello spazio di archiviazione del database si stabilizzi. Forniamo anche istruzioni per
stimare l'aumento dello spazio di archiviazione.
Aumento dell'utilizzo della CPU e della latenza. Spanner utilizza risorse di calcolo aggiuntive per compattare e gestire le versioni precedenti dei dati.
Monitora l'istanza e il database
per assicurarti che la latenza e l'utilizzo della CPU rimangano a livelli accettabili.
Non è previsto alcun costo aggiuntivo per l'utilizzo del recupero point-in-time. Tuttavia, se aumenti il periodo di conservazione delle versioni del database rispetto all'ora predefinita, i costi di archiviazione e capacità di calcolo del database potrebbero aumentare. Il costo del backup on demand non viene modificato perché viene archiviata una sola versione del database. Per ulteriori informazioni, consulta la sezione Considerazioni
sul rendimento. Prima di aumentare il periodo di conservazione delle versioni di un database, puoi stimare l'aumento previsto dello spazio di archiviazione del database.
Per informazioni generali su come vengono addebitati i costi di Spanner, consulta la pagina
Prezzi di Spanner.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)."]]