对大部分团队来说,PostgreSQL 的备份历史几乎就是一段「周末全量 + 工作日归档」的循环:pg_dump 跑一遍要四小时,WAL 一边写入一边归档,恢复演练要等到下个月窗口期才敢做一次。这套节奏跑了十几年,它不是因为好用才留下来,而是因为没人替它。17 系列引入的页面级增量备份和服务器端汇总策略,把这条老路上最难走的那一段拆掉了。
页面级增量:从 WAL 流到物理位图
过去 WAL 归档看起来是「增量」,但它的单位是一条事务日志,不是一块磁盘页面;如果只想快速拿到「昨天到今天」之间的数据变化,工程师只能从基础备份开始回放 WAL,回放深度一长,时间和磁盘都吃不消,跨 TB 量级基本属于不敢在生产高峰期做的动作。
17 系列允许 pg_basebackup 输出一份摘要文件:它记录了从某一时刻起,每一个数据文件里被修改过哪些页。恢复时,先取最近一次全量,再按这份位图把增量块叠回到全量之上。增量体积不再由「日志长度」决定,而是由「真正被改写的页数」决定,这条差异在大表稀疏更新的场景里特别明显——日志里 100 GB,被改写的页可能只有几百 MB。
服务器端汇总:不再把临时块拖回家
位图文件本身不大,但「被改写的页」在网络层面是要被传输的。早期的工具链往往让运维先在本地拼一份完整的 .tar,再 rsync 到异地,中间会消耗大量临时磁盘和带宽。新机制允许把若干份增量合成一份新的「基础」增量,让 DBA 可以在远端归档节点上做这件事,数据库服务器只管吐出当前块,不必保留太多历史。
对自建机房、磁盘预算紧张的团队来说,这意味着你可以保留一份全量在 1 号机,剩下的 2 号到 7 号机只保留按周合并后的增量副本,恢复时只需要拉一份全量加上最新一份合并后的增量。这条工作流在云上的对象存储里同样适用:写入是 append-only 的,每个对象对应一个时间窗口,清理策略可以做得非常直接。
它没解决的几个老问题
增量做细了,并不等于恢复做快了。真正到了「线上数据库挂了」那一刻,从备份恢复到对外服务,中间往往还有一致性校验、PITR 时间点选择、回放控制台交互,这些步骤的耗时和增量体积关系不大。有些团队做完漂亮的页面级备份之后,演练时却发现恢复瓶颈出在归档恢复本身——这是工具解决的问题,不是流程解决的问题。
另外,页面级增量是物理备份,它的语义和逻辑备份完全不同。如果你依赖 pg_dump 拿一份跨版本兼容的数据来做迁移,物理增量无法替代它;反过来,如果你只是想要一个可恢复的快照点,物理增量在体积和速度上都比逻辑备份便宜得多。混用的时候,运维手册要写清楚「哪种备份用于哪种恢复」,不然真出事的那天,所有人都会去拉错的那一份。
对小机房和单机部署的实际意义
大型云数据库厂商早就在内部做过类似的优化,只是把它藏在了「自动备份」按钮后面。对中小团队、自建机房、单节点开发者来说,这次改动带来的好处是第一次能本地用上同等级的工具:一台 32 GB 内存、几 TB SSD 的机器,过去一周只能跑一次全量,现在可以把窗口缩短到一天甚至几个小时,恢复点目标从「昨天夜里」变成「二十分钟前」。
更微妙的是它和复制的关系。当 standby 节点长时间落后主节点,传统做法是让它重新走一遍基础备份;页面级增量让追赶成本和落后时长成线性而非超线性,对网络抖动和长距离复制的容错能力也跟着提升。这套能力对地理多活的团队来说,不只是一个备份工具,而是补齐了同步复制和异步复制之间那块一直尴尬的空白。
它改变了 DBA 这份工作的边界
备份脚本、恢复剧本、归档清理策略——这些工作过去是 DBA 的「内功」,也是他们夜里被叫醒最多的原因。页面级增量和服务器端汇总把一部分体力活挪给了工具,DBA 的注意力可以转向备份验证、恢复时延评估、跨地域一致性策略,以及更重要的一件事:演练频率本身。
备份行业里有一句老话:「没演练过的备份不算备份」。当恢复一个 TB 级库的时长从「几小时」压到「几十分钟」,演练的边际成本随之下降,团队敢于把它放进每月一次的自动化流水线里。这条变化比工具本身的算账更难量化,但它对整个数据库可靠性文化的拉动,往往比省下来的那一点磁盘和带宽更值钱。
一次迟到的能力补齐
页面级增量备份和服务器端汇总,本质上是把 Postgres 拉回到它早该站的位置:与商用数据库在备份粒度上拉平,与新兴 OLAP 引擎在恢复灵活性上对齐。它不是革命,只是一次迟到的、对十几年来「全量 + 归档」单一模式的修补。对今天还在按周跑全量的团队来说,这条工具链值得花一个季度的备份预算去试一次,哪怕只是为了把夜里被叫醒的次数,减少那么一两次。