Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Pemulihan point-in-time (PITR) Spanner memberikan perlindungan terhadap penghapusan atau penulisan yang tidak disengaja. Misalnya, jika operator tidak sengaja menulis data atau peluncuran sebuah aplikasi merusak database, Anda dapat memulihkan data dari satu titik waktu sebelumnya dengan PITR (hingga maksimum tujuh hari) dengan lancar. Jika Anda memerlukan retensi data jangka panjang, Anda dapat menggunakan
Pencadangan dan Pemulihan atau Ekspor dan Impor.
Secara default, database Anda mempertahankan semua versi data dan skemanya selama satu jam. Anda dapat memperpanjang batas waktu ini hingga tujuh hari melalui opsi
version_retention_period. Untuk mengetahui petunjuknya, lihat Menetapkan periode retensi.
Spanner menyimpan versi data sebelumnya dengan perincian mikrodetik dan database mempertahankan earliest_version_time,
yang merepresentasikan waktu paling awal di masa lalu yang dapat Anda gunakan untuk memulihkan versi data sebelumnya.
Cara memulihkan data
Ada dua cara untuk memulihkan data:
Untuk memulihkan sebagian database, lakukan stale read
dengan menentukan kondisi kueri dan stempel waktu yang lampau, lalu tuliskan
hasilnya kembali ke database live. Hal ini biasanya digunakan untuk operasi bedah pada database live. Misalnya, jika Anda tidak sengaja menghapus
baris tertentu atau salah memperbarui subset data, Anda dapat memulihkannya
dengan metode ini. Untuk mengetahui petunjuknya, lihat memulihkan sebagian database Anda.
Untuk memulihkan seluruh database, cadangkan atau
ekspor database yang menentukan stempel waktu di
masa lalu, lalu pulihkan atau impor ke database baru. Opsi ini biasanya digunakan untuk memulihkan dari masalah kerusakan data saat Anda harus mengembalikan database ke titik waktu sebelum kerusakan terjadi. Perhatikan bahwa
mencadangkan atau mengekspor database dapat memerlukan waktu beberapa jam dan Anda
tidak dapat memulihkan atau mengimpor ke database yang ada. Untuk mengetahui petunjuknya, lihat memulihkan seluruh database.
Pertimbangan performa
Database dengan periode retensi yang lebih lama, dan khususnya yang sering menimpa data, menggunakan lebih banyak resource sistem. Hal ini dapat memengaruhi performa database Anda, terutama jika instance Anda tidak disediakan dengan kapasitas komputasi yang memadai. Jika database Anda memiliki rasio penimpaan yang sangat tinggi
(misalnya, jika database Anda ditimpa beberapa kali per hari), Anda dapat
mempertimbangkan untuk meningkatkan periode retensi secara bertahap dan
memantau sistem.
Berikut beberapa hal yang perlu diketahui:
Peningkatan pemanfaatan penyimpanan. Sebaiknya siapkan
pemberitahuan penyimpanan untuk memastikan Anda
tidak melebihi batas penyimpanan. Saat Anda
meningkatkan periode retensi, perlu diingat bahwa penggunaan penyimpanan akan meningkat
secara bertahap saat database mengumpulkan versi data sebelumnya. Hal ini karena
data lama yang akan berakhir masa berlakunya dalam jangka waktu retensi sebelumnya, tidak
lagi berakhir masa berlakunya. Jadi, misalnya, jika Anda meningkatkan periode retensi dari 3 hari menjadi 7 hari, Anda harus menunggu selama 4 hari agar penggunaan penyimpanan database stabil. Kami juga memberikan petunjuk untuk
memperkirakan peningkatan penyimpanan.
Peningkatan penggunaan CPU dan latensi. Spanner menggunakan resource komputasi tambahan untuk memadatkan dan mempertahankan versi data sebelumnya.
Pantau instance dan database Anda
untuk memastikan latensi dan penggunaan CPU tetap berada pada tingkat yang dapat diterima.
Peningkatan waktu untuk melakukan pembaruan skema. Periode retensi yang lebih lama berarti versi skema harus dipertahankan untuk durasi yang lebih lama sehingga berpotensi menyebabkan pembaruan skema menjadi throttled saat menunggu resource server. Pastikan Anda mengikuti
praktik terbaik untuk pembaruan skema
dan tetap berada dalam batas untuk pembaruan skema.
Harga
Tidak ada biaya tambahan untuk menggunakan PITR. Namun, jika Anda
meningkatkan periode retensi versi database dari satu jam default,
biaya penyimpanan dan kapasitas komputasi database Anda mungkin meningkat. Biaya
pencadangan sesuai permintaan Anda tidak terpengaruh karena hanya satu versi
database Anda yang disimpan. Untuk mengetahui informasi selengkapnya, lihat bagian Pertimbangan performa. Sebelum memperpanjang periode retensi versi database, Anda dapat memperkirakan peningkatan penyimpanan database yang diharapkan.
Untuk mengetahui informasi umum tentang cara penagihan Spanner, lihat
Harga Spanner.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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)."]]