第二大脑

主题

2026-08-24
1219
4.3m

PostgreSQL 备份方案选型（逻辑 / 物理 / 复制） ​

为什么有这页：CSDN 那篇教程只讲了 pg_dump，读完容易得到一个危险结论——"备份 = pg_dump"。 但在 百 GB 量级以上 + 主从架构 的生产库上，pg_dump 是 错误工具。 这页把三条路摆在一起，给出选型判据。

三方对比 ​

维度逻辑备份
pg_dump/pg_restore		物理备份 + WAL 归档
pg_basebackup / pgBackRest		流复制主从
streaming replication
备份对象SQL 语句 + 数据（逻辑内容）数据目录磁盘块 + WAL 日志实时重放 WAL 到备库
是否算备份✅ 是✅ 是❌ 不是（见下方 "最大误区"）
恢复到任意时间点（PITR）❌ 不支持✅ 支持（秒级精度）❌ 不支持
百 GB 级恢复耗时量级数小时 ~ 十几小时（需重建索引）接近拷贝耗时，1~2 小时级切换即完成（分钟级）
备份期间对主库压力中（长事务、抑制 vacuum、WAL 堆积）低（读磁盘 + 限流）持续低
跨大版本/跨架构迁移✅ 唯一可行（PG10→PG16、x86→ARM）❌ 必须同版本同架构❌ 同上
表级/库级选择性恢复✅ 强项（-F c + -t）❌ 全实例粒度❌
防 "误删数据"✅（恢复到 dump 时点）✅✅（恢复到误删前 1 秒）❌ 误删会秒同步到备库
增量备份❌ 每次全量✅（pgBackRest/Barman 支持）—
额外磁盘需求需 ≈ 数据量级的空间全量 + WAL，可压缩去重一份完整副本

选型判据（按需求倒推） ​

你的需求该选
跨大版本升级、跨平台/信创迁移、换数据库编码逻辑备份（无替代品）
只想捞回某一张表 / 某个库逻辑备份（-F c 选择性恢复）
生产日常备份、要求 RPO 分钟级、能恢复到误操作前物理备份 + WAL 归档（PITR）
硬件故障时业务快速接管、高可用流复制主从（+ VIP 自动切换）
百 GB 级以上库的日常备份物理备份为主 + 逻辑备份仅做关键小库/表的冷归档

组合才是答案：主从保可用性、物理备份+WAL 保可恢复性、逻辑备份保可迁移性。三者互补，不互相替代。

最大误区：主从复制不是备份 ​

这是最需要写进不变量的一条。

  • 你在主库执行 DROP TABLE 或 DELETE 忘加 WHERE，备库会在毫秒内忠实地同步这个错误。
  • 主从解决的是 "机器挂了怎么办"（可用性），解决不了 "人错了怎么办"（可恢复性）。
  • 因此 "我们已经做了主从" 不等于 "我们有备份"——只覆盖了可用性那一半，可恢复性仍是缺口。

结论：主从 ≠ 备份，必须另建 PITR 能力。

迁移窗口的估算方法（自查用） ​

看到 "数据库迁移窗口 N 小时" 这类承诺时，用下面三条反推它是否成立：

  1. 逻辑 dump + restore：耗时由 恢复端重建索引 主导，与数据量近似线性但常数很大。百 GB 级基本以 "数小时起" 计，pg_restore -j 并行可压到 1/3 左右，但压不进 "1 小时"。
  2. 物理拷贝 / 存储快照：耗时 ≈ 数据量 ÷ 磁盘或网络吞吐，可预测，且 不重建索引。这是短窗口唯一现实路径。
  3. 主从切换（提升备库）：分钟级，但要求源与目标同版本同架构，且提前把复制建起来。

判据：只要窗口承诺 < 数据量能被逻辑恢复消化的时间，方案必然不是逻辑备份——去核对实际走的是哪条路径，别让两个假设并存。#待验证

落地建议（通用清单） ​

  1. 先确定迁移/恢复路径：逻辑 dump、物理拷贝、还是主从切换？这决定时间窗口与磁盘预算是否成立，两者不能混用同一套估算。
  2. 补齐 PITR：archive_mode = on + WAL 归档到独立挂载盘，工具建议 pgBackRest（增量 + 并行 + 校验）。
  3. 磁盘预算按路径重算：逻辑备份需预留 ≈ 数据量的空间；物理增量备份可压缩去重，空间模型完全不同——换路径必须重算，不要沿用旧假设。
  4. 加一条恢复演练制度：每季度"从备份还原到临时实例 + 数据校验"，把 PostgreSQL逻辑备份与恢复 的不变量⑦（未演练的备份=没有备份）变成流程。
  5. 逻辑备份保留但降级用途：仅用于跨版本迁移、单表捞回、配置类小库冷归档，并务必同时 pg_dumpall -g 导角色。

关联 ​

最近更新