PostgreSQL 数据库备份与灾备怎么做？恢复目标和演练方法

备份范围：哪些数据必须保护，哪些可以豁免

很多团队在规划 PostgreSQL 备份时，第一反应是“全量备份数据库”。但实际项目中，真正需要保护的往往不只是数据库本身，还包括配置文件、表空间路径、自定义扩展以及归档日志。反过来，并非所有数据库都需要同等保护。

从工程实践看，备份范围应覆盖以下几类：

• **数据库数据目录**：这是核心，包含所有用户数据和系统表。使用 pg_basebackup 或文件系统快照可以完整捕获。
• **WAL 归档**：连续归档的 WAL 是实现时间点恢复（PITR）的前提。如果 WAL 归档丢失，全量备份只能恢复到备份完成时刻，丢失的数据量取决于备份间隔。
• **配置文件**：postgresql.conf、pg_hba.conf、pg_ident.conf 等。很多灾备演练中，数据库能恢复但无法启动，原因就是配置文件丢失或版本不匹配。
• **自定义表空间路径**：如果表空间指向了数据目录之外的位置，必须单独纳入备份策略。
• **扩展和函数**：PostgreSQL 的扩展（如 PostGIS、pg_stat_statements）和自定义 C 函数通常安装在共享库目录下，需要单独备份或在恢复后重新安装。

可以豁免或降低保护级别的数据包括：

• **临时表**：生命周期短，重启即消失，无需备份。
• **日志文件**：pg_log 下的运行日志，通常由外部日志系统收集，不需要纳入数据库备份流程。
• **实验性数据库**：如果某个数据库仅用于开发测试且数据可重新生成，可以只保留全量备份，不启用 WAL 归档。

关键判断：备份范围不是越大越好。每多保护一项，存储成本和恢复复杂度都会增加。企业应根据数据的重要性和恢复需求，明确哪些数据必须纳入备份，哪些可以容忍丢失。

RPO 与 RTO：如何设定合理的恢复目标

RPO（Recovery Point Objective）和 RTO（Recovery Time Objective）是灾备方案的核心指标，但很多项目在设定时容易走向两个极端：要么追求“零丢失”导致成本失控，要么完全不做量化导致恢复失败。

RPO：允许丢失多少数据

RPO 取决于 WAL 归档的频率和全量备份的间隔。

• **WAL 归档频率**：PostgreSQL 的 WAL 默认每 16MB 切换一次，在低负载下可能几分钟才切换一次。如果使用 archive_mode=on 配合 archive_command 实时归档，理论上 RPO 可以做到接近零。但实际项目中，网络延迟和归档目标写入速度会导致几秒到几十秒的延迟。如果使用同步流复制，RPO 可以降到零，但会牺牲写入性能。
• **全量备份间隔**：如果只做全量备份而不启用 WAL 归档，RPO 就等于全量备份间隔。例如每天凌晨 2 点全量备份，那么最多可能丢失 24 小时的数据。

工程建议：对于大多数企业应用，RPO 设定在 5 到 15 分钟已经足够。这可以通过每 1 分钟归档一次 WAL 并配置流复制备库来实现。如果业务要求 RPO 小于 1 分钟，必须使用同步复制或双节点强同步方案，同时评估对写入吞吐量的影响。

RTO：恢复需要多长时间

RTO 由数据量、硬件性能、恢复流程的自动化程度和运维人员熟练度共同决定。

• **全量恢复时间**：从全量备份恢复一个 500GB 的数据库，在普通 SSD 上大约需要 30 到 60 分钟。如果使用 pg_restore 从逻辑备份恢复，速度会更慢，因为需要重建索引和约束。
• **WAL 回放时间**：恢复全量备份后，需要回放 WAL 日志以达到目标时间点。回放速度通常比正常写入慢 2 到 5 倍。如果 WAL 归档积压了数小时的日志，回放时间可能超过 1 小时。
• **验证和切换时间**：恢复完成后，需要检查数据一致性、启动服务、切换 DNS 或 VIP，这部分通常需要 10 到 30 分钟。

综合来看，一个 1TB 的 PostgreSQL 数据库，在合理配置下 RTO 可以控制在 1 到 2 小时。如果业务要求 RTO 小于 30 分钟，必须使用流复制备库并配置自动故障转移，同时定期演练切换流程。

关键判断：RPO 和 RTO 的设定必须基于业务容忍度，而不是技术极限。建议先做一次恢复测试，记录实际耗时，然后根据测试结果调整目标。不要在没有实测的情况下承诺“5 分钟恢复”，因为实际环境中的网络、磁盘和并发情况远比实验室复杂。

备份策略：全量、增量与 WAL 归档的组合

PostgreSQL 提供多种备份方式，每种方式在速度、存储成本和恢复灵活性上各有优劣。企业需要根据数据量和恢复需求组合使用。

物理备份 vs 逻辑备份

• **物理备份**：使用 pg_basebackup 或文件系统快照，备份的是数据文件的二进制副本。恢复速度快，支持 PITR，适合大型数据库。缺点是跨版本恢复困难，备份文件体积大。
• **逻辑备份**：使用 pg_dump 或 pg_dumpall，导出 SQL 或自定义格式。恢复速度慢，但可以跨版本、跨平台恢复，也允许选择性恢复单个表或 schema。适合小数据量或需要迁移的场景。

工程建议：生产环境应优先使用物理备份 + WAL 归档的组合。逻辑备份作为补充，用于数据迁移或紧急情况下的单表恢复。

全量备份频率

全量备份的频率取决于数据变化量和 WAL 归档的完整性。

• **每日全量**：适用于数据量小于 200GB、变化不频繁的系统。备份窗口通常在凌晨低峰期。
• **每周全量 + 增量备份**：对于数据量超过 500GB 的系统，每日全量会占用大量存储和网络带宽。可以使用 pg_basebackup 的增量备份功能（基于 WAL 的差异），但 PostgreSQL 原生不支持真正意义上的增量备份。实践中，多数团队采用每周一次全量备份，配合连续 WAL 归档实现增量保护。

关键点：WAL 归档本身就是一种增量保护。只要 WAL 归档完整，即使全量备份是上周的，也能通过回放 WAL 恢复到任意时间点。因此，全量备份的频率可以适当降低，但必须确保 WAL 归档的连续性和完整性。

WAL 归档策略

WAL 归档的配置要点：

• **归档目标**：建议使用独立的存储设备，如 NFS、S3 兼容对象存储或专用备份服务器。不要将归档存放在数据库服务器本地磁盘，否则服务器故障时归档也会丢失。
• **归档命令可靠性**：archive_command 必须返回非零退出码以通知 PostgreSQL 归档失败。常见的错误是使用 cp 命令但不检查返回值，导致归档失败而 PostgreSQL 继续写入新 WAL，最终造成归档断层。
• **归档保留策略**：WAL 文件可以很大，一个繁忙的系统每小时可能生成数 GB 的 WAL。建议设置保留窗口，例如保留最近 7 天的 WAL，同时保留对应的全量备份。如果使用对象存储，可以配置生命周期策略自动删除过期文件。

关键判断：WAL 归档是最容易出问题的环节。归档命令的稳定性、归档目标的可用性以及磁盘空间的监控，必须纳入日常运维检查清单。

异地保存：为什么必须做，以及怎么做

本地备份只能应对逻辑错误（如误删除表）和硬件故障，但无法抵御机房级灾难（如火灾、断电、网络中断）。异地保存是灾备方案的底线。

异地保存的三种模式

• **远程备份服务器**：在另一个机房或云区域部署一台备份服务器，通过 rsync 或 pg_basebackup 定期同步全量备份和 WAL 归档。优点是成本可控，恢复速度较快；缺点是需要自行维护传输链路和存储。
• **对象存储**：将备份文件上传到 S3、阿里云 OSS 或 MinIO 等对象存储。优点是存储成本低、容量弹性大、支持跨区域复制。缺点是从对象存储下载大文件恢复时，带宽可能成为瓶颈。
• **异地备库**：在异地部署一台流复制备库，实时同步主库数据。RPO 可以做到秒级甚至零。优点是恢复速度最快，缺点是成本最高，需要两倍的硬件和带宽。

选择建议

• 数据量小于 500GB、RPO 容忍 1 小时以上：使用远程备份服务器或对象存储，每日同步全量备份和 WAL 归档。
• 数据量大于 500GB、RPO 要求 15 分钟以内：必须使用流复制备库，同时将 WAL 归档同步到对象存储作为第二层保护。
• 跨地域容灾：使用对象存储的多区域复制或部署备库在另一个地理区域。注意跨地域网络延迟对同步复制的影响，通常只能使用异步复制。

关键判断：异地保存不是“把备份文件复制一份到远程”那么简单。传输链路的带宽、加密、完整性校验以及恢复时的下载速度，都需要提前测试。很多项目在演练时才发现，异地备份文件损坏或传输不完整，导致无法恢复。

恢复演练：验证备份是否真的可用

没有经过验证的备份，本质上只是心理安慰。恢复演练是灾备方案中唯一能暴露真实问题的手段。

演练频率

• **全量恢复演练**：每季度至少一次。在隔离环境中从全量备份恢复数据库，并验证数据完整性和应用可用性。
• **PITR 演练**：每半年至少一次。选择一个随机时间点，尝试恢复到该时刻，并检查数据是否一致。
• **故障转移演练**：如果使用了流复制备库，每季度至少演练一次手动或自动故障转移。验证备库能否正常接管，以及应用连接是否能自动切换到新主库。

演练步骤

1. **准备恢复环境**：使用与生产环境相同或接近的硬件配置和 PostgreSQL 版本。如果使用 Docker 或虚拟机，确保资源限制不会影响恢复速度。
2. **恢复全量备份**：使用 pg_basebackup 或 tar 恢复数据目录。记录恢复耗时。
3. **配置 WAL 归档恢复**：在 recovery.conf（PostgreSQL 12 之前）或 recovery.signal 文件中指定恢复目标时间点。启动数据库，观察日志中是否有错误。
4. **验证数据一致性**：连接数据库，执行 count(*) 检查关键表记录数，运行自定义的校验脚本，或者与应用进行集成测试。
5. **记录问题和耗时**：记录每一步的实际耗时、遇到的错误以及解决方法。这些数据将用于优化 RTO 和备份策略。

常见失败原因

根据 SystemDo 在多个项目中的经验，恢复演练中最常见的问题包括：

• **WAL 归档不完整**：归档命令失败但未被监控发现，导致恢复时缺少必要的 WAL 段。
• **配置文件丢失或版本不匹配**：恢复时使用了错误的 postgresql.conf，导致数据库无法启动或性能异常。
• **表空间路径不一致**：恢复环境中的表空间目录与备份时不同，导致恢复失败。
• **权限问题**：备份文件的所有者或权限不正确，导致 PostgreSQL 进程无法读取。
• **时间点选择错误**：指定的恢复目标时间点超出了 WAL 归档的范围，导致恢复不完整。

关键判断：恢复演练不是一次性的任务，而是一个持续改进的过程。每次演练后，应更新备份策略、完善监控告警、优化恢复流程。如果演练中发现了问题，不要等到下次演练再解决，而是立即修复并重新测试。

备份与灾备的常见风险

存储成本失控

WAL 归档和全量备份会消耗大量存储空间。一个每天生成 50GB WAL 的系统，保留 7 天的 WAL 就需要 350GB 存储，再加上全量备份，每月存储成本可能超过预期。建议对 WAL 归档启用压缩，或者使用对象存储的冷存储层降低成本。

备份窗口不足

对于 24x7 运行的系统，全量备份可能无法在低峰期完成。如果备份时间过长，会影响数据库性能。解决方案包括：使用 pg_basebackup 的 --checkpoint=fast 选项减少 checkpoint 时间，或者使用文件系统快照（如 LVM、ZFS）实现秒级快照。

网络带宽瓶颈

异地备份和流复制都需要网络带宽。如果带宽不足，WAL 归档可能积压，备库可能延迟过大。建议对网络带宽进行监控，并在带宽紧张时使用压缩传输或调整归档频率。

人为错误

误删除备份文件、错误配置归档命令、忘记切换备份目标等，都是实际项目中反复出现的问题。自动化脚本和监控告警是减少人为错误的关键，但脚本本身也需要测试和版本管理。

总结与行动建议

PostgreSQL 数据库的备份与灾备，核心不在于技术选型，而在于持续验证。无论选择哪种备份方式、设定多高的 RPO/RTO，如果不定期演练，所有方案都只是纸上谈兵。

对于正在规划或优化备份方案的项目团队，建议按以下顺序行动：

1. **评估数据量和业务容忍度**：确定 RPO 和 RTO 的合理目标，而不是直接套用“零丢失”或“5 分钟恢复”的理想值。
2. **配置 WAL 归档并监控其完整性**：这是实现 PITR 的基础，也是最容易出错的环节。
3. **建立全量备份和异地保存机制**：根据数据量选择物理备份或逻辑备份，并确保备份文件存储在独立于数据库服务器的位置。
4. **制定恢复演练计划并执行**：从最简单的全量恢复开始，逐步增加 PITR 和故障转移演练。
5. **持续优化**：根据演练结果调整备份频率、存储策略和恢复流程。

记住，备份的价值在于恢复，而恢复的唯一验证方式就是演练。如果今天还没有做过一次完整的恢复测试，那么你的备份方案可能并不像你想象的那么可靠。