Spanner 时间点恢复 (PITR) 可防止意外删除或写入。例如，如果操作者无意中写入了数据或者应用发布损坏了数据库，则使用 PITR 可以从过去的某个时间点（最多 7 天）无缝恢复数据。如果您需要长期保留数据，可以使用备份和恢复或导出和导入。
默认情况下，您的数据库的所有数据和架构版本都会保留 1 小时。您可以通过 version_retention_period 选项将此时间上限增加到 7 天。有关说明，请参阅设置保留期限。
Spanner 以微秒级粒度存储旧版本的数据，数据库会维护一个 earliest_version_time，它表示过去可以恢复旧版本数据的最早时间。
恢复数据的方法
您可以通过以下两种方式恢复数据：
如需恢复数据库的一部分，请执行指定过去查询条件和时间戳的过时读取，然后将结果写回实时数据库。此数据库通常用于对实时数据库进行外科操作。例如，如果您不小心删除了特定行或错误地更新数据子集，可以使用此方法恢复。如需查看相关说明，请参阅恢复数据库的一部分。
如需恢复整个数据库，请备份或导出指定了时间戳的数据库，然后将其恢复或导入新数据库。这通常用于在需要将数据库还原为损坏发生之前的某个时间点时，从数据损坏问题中恢复。请注意，备份或导出数据库可能需要数小时，并且您无法恢复或导入现有数据库。如需了解相关说明，请参阅恢复整个数据库。
性能考虑因素
保留期限较长的数据库（尤其是经常覆盖数据的数据库）会使用更多系统资源。这可能会影响数据库的性能，尤其是当您的实例未供应足够的计算容量时。如果您的数据库具有非常高的覆盖率（例如，如果您的数据库每天被覆盖多次），您可以考虑逐渐增加保留期并监控系统。请注意以下事项：
增加了存储空间用量。我们建议您设置存储空间提醒，确保不会超出存储空间上限。如果增加保留期限，请注意，随着数据库不断累积旧版数据，存储空间用量将逐渐增加。这是因为在上一个保留期限下将要过期的旧数据不再过期。例如，如果您将保留期限从 3 天增加到 7 天，则需要等待 4 天才能使数据库存储空间用量稳定。我们还会提供用于估算存储空间增量的说明。
增加了 CPU 使用率和延迟时间。Spanner 使用额外的计算资源来压缩和维护旧版数据。 监控实例和数据库，确保延迟时间和 CPU 利用率保持在可接受的水平。
增加了执行架构更新的时间。保留期限延长意味着架构版本必须保留较长时间，这可能会导致架构更新在等待服务器资源时变为
throttled。请确保遵循架构更新最佳实践，并遵守架构更新限制。
后续步骤
- 详细了解如何使用 PITR 恢复数据。