PostgreSQL 17 增量备份与 pg_verifybackup 实测：集中改动增量 35MB、随机改动接近全量，verified 也不等于数据页没坏

先跑全量：pg_basebackup -Fp -c fast 得到 637MB，四轮 1235–1788ms；pg_verifybackup 全量 190–218ms，打印 backup successfully verified。

然后做 A 类集中改动：UPDATE pgbench_accounts 前 1% 账户（aid <= 40000，4 万行）+ 往 pgbench_history 追加 1 万行 + 更新一个 branch，CHECKPOINT 后跑 --incremental=full/backup_manifest。增量 35MB，113–114ms，里面有 671 个 INCREMENTAL.* 文件（合计约 15MB）。pg_verifybackup 增量 15–16ms 通过。

pg_combinebackup full incr1 -o combined 用时 918–1148ms，合成目录 644MB，pg_verifybackup 通过。把合成目录改端口 5441 直接启动（约 112–124ms 起来，日志里 redo done、database system is ready to accept connections），然后比对 pgbench_accounts count/sum、history count/sum、branches sum，和源库在增量备份那一刻完全一致：accounts 4000000 / 40000，history 10000 / 10000，branches 50000（后面随机改动的两轮也一样一致）。

B 类改动直接跑 pgbench -T 20 -c 4，两轮分别处理 251309 / 217158 笔交易，tps 约 12568 / 10860。再跑增量备份，结果 642MB / 640MB，1477 / 1451ms——和全量差不多大。

第二轮我统计了一下：INCREMENTAL.* 文件 663 个，合计只有 2.8MB，剩下的都是整文件复制。原因在 PostgreSQL 17 源码 src/backend/backup/basebackup_incremental.c（REL_17_STABLE，我核对过）：一个文件需要发送的块超过 90%（nblocks * BLCKSZ > size * 0.9），就直接整文件备份。

pgbench_accounts 数据文件 542556160 字节，20 秒随机更新后几乎每个块都被改过，所以整文件进了增量。再合成 757–1225ms，657–658MB，校验通过。

我在备份副本上做了三种破坏。A：改写备份里 pgbench_accounts 数据文件（base/5/16468）中间 16 字节，pg_verifybackup 直接报 checksum mismatch for file "base/5/16468"，退出码 1。

B：删掉一个表文件，报 "base/5/16469" is present in the manifest but not on disk，退出码 1。C：删掉备份 pg_wal 里的 WAL 段，pg_waldump 先报 could not find any WAL file，pg_verifybackup 报 WAL parsing failed for timeline 1，退出码 1。

它按 backup_manifest 里的文件清单、大小和文件校验和（默认 CRC32C）逐个比对，再用 pg_waldump 解析恢复需要的 WAL。所以备份拷完以后被改、少文件、缺 WAL，都能抓到。

这组只在实验集群上做：建 t_corrupt 表 5000 行，停库，用 dd 改写它数据文件第 2 个块里的 16 字节，再启动。我跑了两遍（第二遍补查失败目录和 pg_checksums，表重建后文件号从 16478 变成 16483，下面两个文件号都会出现）。D1 用默认 pg_basebackup，输出 WARNING: checksum verification failed in file "./base/5/16478", block 2: calculated 491C but expected 8EFB，最后 pg_basebackup: error: checksum error occurred，退出码 1。

坑在哪？失败后备份目录还留在磁盘上（第二遍看的），644MB，有 backup_label，但没有 backup_manifest。如果定时任务只看目录在不在、大小对不对，会以为备份成功。对它跑 pg_verifybackup 直接 could not open file "full_d1/backup_manifest": No such file or directory。

D2 加 --no-verify-checksums 再备份，退出码 0，成功。D3 对这份备份跑 pg_verifybackup，打印 backup successfully verified，退出码 0——坏页被当成正常内容记进清单。也就是说 pg_verifybackup 验证的是备份和备份时拷到的内容一致，不是数据页健康。

要抓坏页得换工具。D4 我先直接对备份目录跑 pg_checksums --check，被拒：pg_checksums: error: cluster must be shut down。把备份目录在 5442 端口启动一次、正常关闭后再跑，输出 checksum verification failed in file "full_d/base/5/16483", block 2 …；Files scanned: 965，Blocks scanned: 80322，Bad checksums: 1，退出码 1。

D5 源库 SELECT count(*) FROM t_corrupt 也报 WARNING: page verification failed, calculated checksum 18716 but expected 36603 / ERROR: invalid page in block 2 of relation base/5/16478。D6 先装 amcheck 扩展，再 pg_amcheck -t t_corrupt，报 heap table "postgres.public.t_corrupt": ERROR: invalid page in block 2，退出码 2。

实验做完后用本文只读 SQL 查 pg_stat_database：postgres 库 checksum_failures = 2，checksum_last_failure 2026-10-20 10:37:07（正是 pg_amcheck 那一刻）。这个计数只在某个进程真的读到坏页时才涨，所以 0 也不代表没有坏页。

第一步，每份备份做完立刻跑 pg_verifybackup，退出码非 0 就告警；备份任务看 pg_basebackup 的退出码，不看目录大小。D1 的教训就是目录还在 644MB 但 manifest 没了。

第二步，用本文只读 SQL 检查关键参数和 WAL 汇总状态：data_checksums、summarize_wal、wal_level；pg_get_wal_summarizer_state() 和 pg_available_wal_summaries() 看汇总在不在跑。实验集群 summary_files 30、summarized_lsn 1/58000028。

第三步，增量链要全量 + 增量一起保留，恢复先 pg_combinebackup 再 pg_verifybackup；随机写多的库，增量未必省空间，先用演示脚本量一次再定全量周期。wal_summary_keep_time 默认 14400 分钟（10 天），全量太旧、汇总被清掉时增量会失败——官方文档写，本次未实测。

第四步，每周至少一次把备份真正启动起来读数据，本次用 count/sum 比对；正式演练用我们之前的备份恢复演练脚本。