上一篇建立了基于等待、执行计划和统计信息的性能诊断闭环。本篇解决更冷酷的问题主机损坏、误删表或机房中断后允许丢多少数据、多久恢复服务。先写 RPO恢复点目标和 RTO恢复时间目标再选择备份与复制没有经过恢复演练的备份只能叫“文件”。一、逻辑备份用于可移植恢复pg_dump产生事务一致的单数据库逻辑备份不阻塞普通读写但不包含角色和 tablespace 等集群级对象。自定义格式配合pg_restore可并行、选择对象并查看目录适合升级迁移、小中型库和单表恢复。它不是增量备份大库恢复时间必须实测。以下脚本创建带校验信息的备份目录。密码应从受限.pgpass、证书或密钥系统获得不能写进脚本。恢复演练使用新的空数据库避免覆盖源库。set-eubackup_root/tmp/pg-backup-labbackup_file$backup_root/app.dumpmanifest_file$backup_root/manifest.txtmkdir-p$backup_rootchmod700$backup_rootpg_dump\--host127.0.0.1\--usernameapp_admin\--dbnameapp\--formatcustom\--compress6\--file$backup_filepg_restore--list$backup_file$backup_root/contents.listsha256sum$backup_file$backup_root/SHA256SUMS{printfcreated_at%s\n$(date-u%FT%TZ)pg_dump--versionpsql--host127.0.0.1--usernameapp_admin--dbnameapp\-X-Atcselect server_version || current_setting(server_version);stat-cbytes%s$backup_file}$manifest_filesha256sum--check$backup_root/SHA256SUMShead-n5$manifest_file运行输出/tmp/pg-backup-lab/app.dump: OK created_at2026-08-16T15:00:00Z pg_dump (PostgreSQL) 17.6 server_version17.6 bytes48231备份文件大小和版本随环境变化。pg_dump客户端大版本应不低于服务器大版本恢复目标则要经过兼容验证。全局角色可另用pg_dumpall --globals-only保存但其中可能有密码哈希应加密并严格控制访问。二、恢复必须有自动校验恢复不是看到命令退出零就结束。要验证 schema、关键行数、约束、扩展、序列、权限和业务不变量再跑一组只读冒烟查询。恢复到不同角色环境时--no-owner与显式--role能避免所有权失败但也会改变权限语义需要单独复核。set-eubackup_file/tmp/pg-backup-lab/app.dumprestore_dbapp_restore_drilldropdb--host127.0.0.1--usernameapp_admin --if-exists$restore_dbcreatedb--host127.0.0.1--usernameapp_admin$restore_dbpg_restore\--host127.0.0.1\--usernameapp_admin\--dbname$restore_db\--exit-on-error\--jobs2\$backup_filepsql--host127.0.0.1--usernameapp_admin--dbname$restore_db\-X-vON_ERROR_STOP1SQL SELECT current_database() AS restored_database; SELECT count(*) AS user_tables FROM pg_class WHERE relkind IN (r,p) AND relnamespace NOT IN (pg_catalog::regnamespace, information_schema::regnamespace); SELECT count(*) AS invalid_indexes FROM pg_index WHERE NOT indisvalid; SQL运行输出restored_database ------------------- app_restore_drill user_tables ------------- 1 invalid_indexes ----------------- 0样板库表数可能不同验收应与备份清单中的期望值比较而非硬编码“一张表”。演练结束保留日志、耗时、恢复点和失败项再按保留策略删除演练库。三、PITR、复制和故障切换的边界物理基础备份加连续 WAL 归档可以执行时间点恢复PITR先恢复基础备份再重放 WAL 到时间、事务或命名恢复点。archive_command必须只在文件安全落地后返回成功并做到重复执行无害归档目标要跨故障域、加密、监控滞后并定期校验。只保留基础备份而缺少所需 WAL无法恢复到目标时间。流复制把 WAL 发送给备库可降低故障切换时间。异步复制提交快但主库突然损坏可能丢尚未到达备库的事务同步复制降低 RPO却把网络与备库状态放进提交延迟路径。级联复制、复制槽和延迟备库各有用途复制槽若消费者停止会无限保留 WAL必须监控restart_lsn与磁盘。高可用管理器可以选主和重配置但无法替业务决定数据新旧也不能消除脑裂。切换流程必须有 fencing确认旧主不可写提升目标备库更新连接入口验证时间线与数据再恢复冗余。客户端需要有限重试、重新建连和幂等写一个悬挂的旧连接不会自动理解新主。复制会忠实传播误删和逻辑错误所以绝不是备份。合理体系同时具备异地不可变备份、WAL 归档、至少一个可提升副本和定期恢复/切换演练。备份加密还要备份密钥并验证轮换否则灾难时得到无法解密的安全文件。可交付的灾备证据包括最后成功备份时间、最近可恢复 WAL、校验结果、实测 RPO/RTO、恢复脚本版本和责任人。下一篇将把前九篇合并成生产运行手册容量、连接、变更、监控、升级、安全和一次完整事故处置。保留策略也应按恢复场景设计而不是简单写“保留七天”近期基础备份配连续 WAL 支持精确恢复较长期快照用于发现很晚的逻辑错误年度归档满足业务合规。每类副本都记录删除日期、加密密钥版本和不可变策略并定期从最老仍承诺可恢复的备份启动演练才能证明保留窗口真实有效。参考来源PostgreSQLSQL DumpPostgreSQL文件系统级备份与连续归档PostgreSQL热备与流复制PostgreSQLpg_basebackup 觉得有用就点个赞 收藏方便回头查阅有疑问直接在评论区留言我看到都会回。 本文属于《PostgreSQL 实战进阶》系列持续更新关注不迷路。 文章里的代码都能直接跑。想要可直接 clone 的完整工程 配套部署脚本 / 踩坑清单评论一声或发邮件到cj2664qq.com我免费发你。如果你正好在做类似系统、或有工程化难题想找人做也欢迎邮件聊一句——我按实际情况评估能落地的就接单或出方案。评论和邮件都能直接找到我不用跳别的平台。