只有成功恢复过的备份才真正可信。备份方案需要同时满足恢复点目标 RPO 和恢复时间目标 RTO，并覆盖数据文件、WAL、角色、扩展、配置与加密密钥等完整依赖。

核心原则

  • 小型或对象级迁移使用 pg_dump，自定义格式便于并行和选择性恢复。
  • 大规模实例结合物理基础备份与连续 WAL 归档，实现时间点恢复。
  • 备份文件加密后存入独立故障域，并设置不可变保留与访问审计。
  • 每次任务记录大小、耗时、校验和和归档连续性，失败立即告警。
  • 定期在隔离环境执行全流程恢复，测量实际 RPO、RTO 并验证业务数据。

推荐的实践步骤

恢复演练要像真实事故一样从空环境开始：准备匹配版本，恢复基础数据，重放到目标时间，检查数据库启动日志，然后运行行数、约束和核心业务查询验证。还要记录 DNS、应用连接、只读切换与回切步骤，使数据库恢复能够真正转化为业务恢复。

pg_dump -Fc -d appdb -f appdb.dump
pg_restore --list appdb.dump > contents.txt
createdb appdb_restore
pg_restore --clean --if-exists   -d appdb_restore appdb.dump
psql -d appdb_restore -c "select count(*) from orders;"

示例用于说明实现思路，实际项目还应结合所使用的框架版本、部署环境和业务约束进行调整。重要配置要进入版本管理，并在测试环境验证后再发布。

常见误区

  • 只看到备份任务显示成功，却从未进行恢复，会遗漏损坏和权限问题。
  • 备份与主库放在同一磁盘或同一账号下，无法抵御故障和误删除。
  • 忽略 PostgreSQL 主版本、扩展与排序规则差异，可能导致恢复失败。

上线前检查清单

  • 确认“小型或对象级迁移使用 pg_dump，自定义格式便于并行和选择性恢复”已经通过代码审查或运行验证。
  • 确认“大规模实例结合物理基础备份与连续 WAL 归档，实现时间点恢复”已经通过代码审查或运行验证。
  • 确认“备份文件加密后存入独立故障域，并设置不可变保留与访问审计”已经通过代码审查或运行验证。
  • 确认“每次任务记录大小、耗时、校验和和归档连续性，失败立即告警”已经通过代码审查或运行验证。
  • 为失败路径、边界条件和回滚方案准备测试或演练记录。
  • 上线后观察错误率、延迟和资源消耗，确认变化符合预期。

总结

PostgreSQL 备份恢复与灾难演练实战的关键在于把隐含假设变成可执行的约束，并通过测试、监控和复盘持续验证。先从影响最大的真实场景开始，小步调整并保留回滚能力，通常比一次性大范围改造更安全，也更容易积累可复用的工程经验。