题干与适用场景
一个大型 PostgreSQL 集群希望减少全量备份的窗口和存储成本。请设计基于增量 base backup 的备份链，说明 pgbasebackup、WAL 依赖、backup manifest、pgcombinebackup、校验、保留策略和恢复演练。
PostgreSQL 文档指出，增量备份不能直接用于恢复，必须与其依赖的旧备份合成为 synthetic full；工具会检查链条关系，但不会替你追踪依赖，也不会证明每个备份内容完整。面试重点是恢复可证明性，不是只会执行一条备份命令。
面试官考察点
面试官会看你能否区分 full、incremental、WAL 与 manifest；能否解释 reference backup、依赖链和合成全量；能否设计 pg_verifybackup、校验和、对象存储不可变版本和完整性检查；能否处理链断裂、备份来自 standby、复制槽/WAL 保留、加密与恢复时间目标；能否用演练证明 RPO/RTO。
回答前需要澄清的问题
恢复目标
确认 RPO、RTO、目标时间点、是否需要跨区域恢复、是否允许恢复到较低 PostgreSQL 版本，以及数据库是否包含多 tablespace。
备份工作负载
确认全量大小、每日变化量、WAL 速率、备份窗口、网络带宽、对象存储生命周期和并发备份限制。
一致性与合规
确认备份加密和密钥轮换、不可变保留、删除权限、manifest 校验算法、审计记录和恢复演练频率。
30 秒回答框架
“我会以一份可验证的 full backup 为链起点，按变化量生成 incremental，并保存每份 backup manifest、依赖关系和连续 WAL。增量不能直接恢复，恢复前按时间顺序用 pgcombinebackup 生成 synthetic full，再应用所需 WAL。对象存储启用不可变版本和加密，定期用 pgverifybackup 与抽样恢复验证内容；丢失任何依赖就让调度器阻止清理相关备份。最终用真实大小和故障演练证明 RPO、RTO，而不是只看备份成功率。”
分步骤深入解答
第一步：建立备份链模型
记录 full、每份 incremental 的 reference backup、LSN 时间范围、manifest、加密密钥版本和存储 URI。链上的每个节点都指向其前置依赖；删除策略必须先计算仍可恢复的最早时间点。
第二步：生成增量备份
pg_basebackup 可用 reference manifest 请求增量，增量文件只包含相对参考备份发生变化的块。备份仍针对整个集群，而不是单个数据库对象；复制连接需要 REPLICATION 权限或超级用户，并配置足够的 walsender。
full_0 = pg_basebackup(full)
inc_1 = pg_basebackup(incremental, reference=full_0.manifest)
inc_2 = pg_basebackup(incremental, reference=inc_1.manifest)第三步：保留连续 WAL
基备份期间生成的 WAL 必须可获取。使用 stream 方法会并行打开第二个复制连接；使用 fetch 方法则需要保证 walkeepsize 或归档在传输完成前不回收所需 WAL。复制槽能减少过早清理风险，但也可能造成磁盘增长，必须监控最老 required LSN。
第四步：验证 manifest 与链条
pgcombinebackup 只验证输入备份之间的合法关系，不验证每个备份本身是否完整；每个节点应另用 pgverifybackup 和 manifest checksum 校验。对象存储上传完成后再登记状态，校验失败的节点不得进入可恢复链。
第五步：合成恢复输入
恢复到某个时间点时，按 full 到目标 incremental 的顺序调用 pg_combinebackup，输出 synthetic full。它可以作为下一次合并的起点，但不能替代 WAL；随后把从备份结束 LSN 到目标时间点的 WAL 放入恢复目录并配置恢复目标。
第六步：处理链断裂与保留
调度器维护依赖图和最早可恢复时间。任意前置备份丢失、校验失败或密钥不可用，就标记所有后继节点不可恢复，禁止自动删除前置节点。周期性创建新的 full 或 synthetic full，压缩链长度和恢复时间。
第七步：演练 RPO/RTO
在隔离环境恢复随机时间点，核对系统目录、tablespace、WAL、扩展和应用一致性。记录下载字节、合并耗时、WAL 回放速率、恢复完成时间和数据校验结果；模拟对象存储 404、坏 manifest、密钥撤销与主库故障。
高质量示范回答
我会把备份当成带依赖的有向链：full 是根，incremental 指向 reference backup，WAL 补齐时间点。每个节点保存 manifest、checksum、LSN、密钥版本和不可变对象 URI。恢复先用 pgcombinebackup 按顺序生成 synthetic full，再回放连续 WAL；pgcombinebackup 的链关系检查不能代替 pg_verifybackup 的内容检查。保留策略通过依赖图计算，恢复演练覆盖链断裂、WAL 缺失、密钥撤销和多 tablespace，并以实测 RPO/RTO 放行发布。
常见错误
- 错误表现： 把 incremental 当作可独立启动的目录。→ 失败原因： 它依赖 reference backup，不能直接恢复。→ 修正方法： 先合成 full，再应用 WAL。
- 错误表现： 只看 pg_combinebackup 返回成功。→ 失败原因： 它不证明各备份内容完整。→ 修正方法： 对每个节点执行 manifest/checksum 验证和抽样恢复。
- 错误表现： 清理旧 full 只按时间判断。→ 失败原因： 后继增量仍依赖它。→ 修正方法： 用依赖图和最早可恢复时间决定保留。
- 错误表现： 备份成功却没有连续 WAL。→ 失败原因： 目标时间点无法重放。→ 修正方法： 监控 required LSN、归档延迟和复制槽占用。
追问及应对
full、synthetic full 和 incremental 有什么区别？
full 是独立的集群文件副本；incremental 只包含相对参考备份变化的块；synthetic full 是用链条重建出的可作为恢复输入的目录，但仍需要目标时间点之后的 WAL。
为什么不能无限延长增量链？
链越长，下载、合并、校验和失败面越大，RTO 也会上升。按变化率、存储成本和演练数据定期插入新 full 或 synthetic full。
如何处理 manifest 丢失？
将节点标记为不可自动使用，不凭文件名猜依赖。若能从受信任副本恢复 manifest，先校验文件 checksum、LSN 和链关系，再重新登记。
如何验证备份加密不会阻塞恢复？
在隔离环境定期用当前和历史密钥恢复样本，验证密钥轮换、撤销、权限和跨区域 KMS 可用性；密钥不可用时应明确告警并阻止宣称该时间点可恢复。