Umut TEKIN：探索：CNPG 时间点恢复
内容提要
本文介绍用CloudNativePG结合Barman Cloud插件实现PostgreSQL时间点恢复（PITR）：先创建测试库表并记录WAL位置与时间戳，模拟误删表后，通过bootstrap.recovery配置新集群并指定恢复目标时间，从备份和WAL归档重放事务，成功恢复至删表前数据。PITR可按时间戳、LSN或时间线声明式恢复，有效应对误删等灾难。
延伸解读
PITR 在 CNPG 中的声明式实现
与传统的 PostgreSQL 恢复方式不同，CloudNativePG 将时间点恢复（PITR）完全声明式化。用户只需在集群清单中定义 bootstrap.recovery 部分，指定恢复目标时间、外部集群和 Barman Cloud 插件参数，CNPG 便会自动从对象存储拉取备份和 WAL 归档，并重放事务至指定时间点。整个过程无需手动操作，符合 Kubernetes 原生运维习惯。
恢复目标选择的灵活性
文章演示了基于时间戳的恢复，但 CNPG 的 recoveryTarget 还支持按 LSN（日志序列号）或时间线进行恢复。这意味着用户可以根据实际需求选择最精确的恢复点。例如，如果已知误操作对应的 LSN，可以直接指定该 LSN 实现更精准的恢复。这种灵活性使得 PITR 能应对多种误操作场景，而不仅限于时间点。
WAL 归档在 PITR 中的关键作用
PITR 依赖于完整的 WAL 归档。文章强调，在恢复过程中，CNPG 会从 Barman Cloud 获取备份和 WAL 文件，并重放事务直到指定时间戳。因此，确保 WAL 归档的连续性和可用性至关重要。如果 WAL 归档出现缺失，恢复可能无法达到预期时间点。这提醒运维人员必须监控备份和归档系统的健康状态。
恢复验证与数据一致性
恢复完成后，文章通过查询表结构和数据行数验证了恢复效果：表 test_data 重新出现，且 10000 行数据完整，其中 age=1 的记录有 15 条。这展示了 PITR 不仅能恢复表结构，还能保证数据的一致性。在实际操作中，建议在恢复后执行类似的验证查询，确保数据符合预期，避免因恢复不完整导致业务问题。
Q&A
CNPG 中如何实现 PostgreSQL 的时间点恢复（PITR）？
在 CNPG 中，通过定义新的集群清单，在 bootstrap.recovery 中指定恢复目标时间（targetTime），并配置 externalClusters 引用 Barman Cloud 插件和备份存储，即可从备份和 WAL 归档中重放事务，恢复到指定时间点。
PITR 可以恢复到哪些具体目标？
PITR 可以恢复到指定的时间戳（timestamp）、日志序列号（LSN）或时间线（timeline）。
在 CNPG 中做 PITR 需要哪些前提条件？
需要已经配置好备份和 WAL 归档系统（例如使用 Barman Cloud 插件），并且有可用的备份和 WAL 文件。
PITR 主要能应对哪些灾难场景？
PITR 能应对用户错误，如意外删除数据、错误更新、误删表甚至误删数据库等场景。
在 CNPG 中执行 PITR 时，如何指定恢复的目标时间？
在集群清单的 bootstrap.recovery.recoveryTarget 字段中设置 targetTime，例如 "2025-09-19 13:39:18.89106+00"。
使用 Barman Cloud 插件进行 PITR 时，externalClusters 需要配置哪些参数？
需要配置 name（外部集群名称）、plugin（插件名称，如 barman-cloud.cloudnative-pg.io）以及 parameters 中的 barmanObjectName 和 serverName。
