为什么PostgreSQL做PITR时除了WAL还需要basebackup？

首先纠正一个核心认知误区：WAL是数据变更预写日志，不是集群的完整数据副本，它记录的是数据页的修改动作，而非所有数据页的当前完整状态。

你提到的“持有从t=0（集群初始化initdb完成的时刻）开始的所有完整WAL就能恢复”的结论理论上是成立的，但这里有一个被你忽略的前提：你做恢复时必须持有t=0时刻的完整一致的集群数据快照作为WAL重放的基底——而这个t=0时刻的集群数据目录，本质就是你生成的第一个basebackup。

生产场景下必须定期生成新的basebackup，核心原因有三个：

• 极大降低恢复耗时：如果你的集群已经运行了几个月甚至几年，累积的WAL可能达到几十TB，从t=0的初始快照开始重放所有WAL可能需要数天时间，完全无法满足业务的RTO（恢复时间目标）要求。而如果每周做一次basebackup，恢复时只需要重放最近一周的WAL，通常几小时就能完成恢复。
• 降低WAL链路故障的影响范围：WAL是持续流式生成、归档的，只要归档链路出问题（比如存储满、归档脚本故障、单个WAL文件损坏），整个WAL重放链就会在断点处直接失效。如果只有t=0的初始快照，你会直接丢失断点之后的所有数据。而定期做basebackup相当于给恢复链路做多个 checkpoint，最多只会损失上一次basebackup到WAL断点之间的数据，风险可控。
• 减少存储成本开销：长时间保留所有历史WAL的存储成本远高于定期保留几份最近的basebackup+对应时间段的WAL。比如你保留最近4周的basebackup，只需要同时保留4周的WAL即可，更早的WAL可以直接删除，能节省大量存储成本。

只有在极端测试场景下才会出现“只用初始快照+所有历史WAL恢复”的情况，生产环境中这种方案没有任何实用价值，所以所有PITR配置教程都会要求你开启WAL归档的同时定期执行basebackup。

内容的提问来源于stack exchange，提问作者Digital Impermanence