Spanner PITR(point-in-time recovery)은 실수로 인한 삭제나 쓰기를 방지합니다. 예를 들어 운영자가 실수로 데이터를 쓰거나 애플리케이션 출시가 데이터베이스를 손상시키는 경우 PITR을 사용하면 (최대 7일 이내의) 과거 시점으로 데이터를 원활하게 복구할 수 있습니다. 데이터를 장기간 보관해야 하는 경우에는 백업 및 복원 또는 내보내기 및 가져오기를 사용하면 됩니다.
기본적으로 데이터베이스는 모든 버전의 데이터와 스키마를 1시간 동안 보관합니다. version_retention_period 옵션을 통해 이 시간 제한을 최대 7일까지 늘릴 수 있습니다. 자세한 내용은 보관 기간 설정을 참고하세요.
Spanner는 이전 버전의 데이터를 마이크로초 단위로 세분화하여 저장하고 데이터베이스는 이전 버전의 데이터를 복구할 수 있는 가장 이른 시간을 나타내는 earliest_version_time을 유지합니다.
데이터 복구 방법
데이터를 복구하는 방법에는 두 가지가 있습니다.
데이터베이스의 일부를 복구하려면 이전의 쿼리 조건과 타임스탬프를 지정하여 비활성 읽기를 수행한 후 결과를 다시 실시간 데이터베이스에 기록합니다. 이는 일반적으로 실시간 데이터베이스의 소위 외과적 수술을 위해 사용됩니다. 예를 들어 특정 행을 실수로 삭제하거나 데이터 하위 집합을 잘못 업데이트한 경우 이와 같은 방법으로 복구할 수 있습니다. 자세한 내용은 일부 데이터베이스 복구를 참조하세요.
전체 데이터베이스를 복구하려면 이전의 타임스탬프를 지정하여 데이터베이스를 백업하거나 내보낸 후 새 데이터베이스로 복원하거나 가져옵니다. 일반적으로는 데이터베이스를 손상이 발생하기 전의 시점으로 되돌려야 할 때 데이터 손상 문제를 복구하는 데 사용됩니다. 데이터베이스를 백업하거나 내보내는 데 몇 시간이 걸릴 수 있으며 기존 데이터베이스로 복원하거나 가져올 수 없습니다. 자세한 내용은 전체 데이터베이스 복구를 참조하세요.
성능에 대한 고려사항
보관 기간이 긴 데이터베이스, 특히 데이터를 자주 덮어쓰는 데이터베이스에서는 시스템 리소스를 더 많이 사용합니다. 특히 인스턴스에 충분한 컴퓨팅 용량이 프로비저닝되지 않으면 데이터베이스 성능에 영향을 미칠 수 있습니다. 데이터베이스의 덮어쓰기 속도가 매우 높은 경우(예: 데이터베이스를 하루에 여러 번 덮어쓰는 경우) 보관 기간을 점진적으로 늘리고시스템을 모니터링하는 것이 좋습니다.
다음과 같은 몇 가지 유의사항이 있습니다.
스토리지 사용량 증가. 스토리지 한도를 초과하지 않도록 스토리지 알림을 설정하는 것이 좋습니다. 보관 기간을 늘리면 데이터베이스에 이전 버전의 데이터가 누적되므로 스토리지 사용량이 점진적으로 증가합니다. 이전 보관 기간 동안 만료되었을 이전 데이터가 더 이상 만료되지 않기 때문입니다. 예를 들어 보관 기간을 3일에서 7일로 늘리면 데이터베이스 스토리지 사용량이 안정화될 때까지 4일을 기다려야 합니다. Google에서는 스토리지 증가 예측에 대한 안내도 제공합니다.
CPU 사용량 및 지연 시간 증가. Spanner는 추가 컴퓨팅 리소스를 사용하여 이전 버전의 데이터를 압축하고 유지합니다.
인스턴스와 데이터베이스를 모니터링하여 지연 시간과 CPU 사용률이 허용 수준으로 유지되는지 확인합니다.
PITR 사용에 대한 추가 비용은 없습니다. 하지만 데이터베이스의 버전 보관 기간을 기본 1시간에서 늘리면 데이터베이스 스토리지 및 컴퓨팅 용량 비용이 늘어날 수 있습니다. 데이터베이스의 단일 버전만 저장되므로 주문형 백업 비용은 영향을 받지 않습니다. 자세한 내용은 성능 고려사항 섹션을 참조하세요. 데이터베이스의 버전 보관 기간을 늘리기 전에 예상되는 데이터베이스 스토리지 증가를 예측할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 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)."]]