1. 课程导入与灾备体系全景
在开始学习 PostgreSQL 备份恢复之前，先建立一个整体认知：备份恢复不是“把数据拷出来”这么简单，它是一套围绕数据可恢复性构建的工程体系。这套体系要回答三个问题：数据丢了能恢复到什么时间点？恢复需要多长时间？在什么故障场景下仍然可用？这三个问题分别对应 RPO、RTO 和灾备分层设计。
一、两个核心目标：RPO 与 RTO
RPO（Recovery Point Objective，恢复点目标）衡量的是“允许丢失多少数据”，通常以时间表示。若 RPO = 5 分钟，意味着故障发生后，最多可以接受丢失最近 5 分钟内产生的数据。RPO 越小，对备份频率和日志归档连续性的要求越高。
RTO（Recovery Time Objective，恢复时间目标）衡量的是“允许中断多久”，即从故障发生到业务重新可用的最长时间。RTO = 30 分钟，意味着必须在半小时内完成恢复并让数据库重新提供服务。RTO 越小，对恢复流程自动化、备份介质读取速度、备用节点就绪程度的要求越高。
两者常被混淆，但方向完全不同：RPO 关注数据损失量，RTO 关注停机时长。一个常见误区是“备份做得越频繁，恢复就越快”——实际上高频备份改善的是 RPO，而 RTO 取决于恢复路径的设计。例如每天全量备份 + 持续 WAL 归档，RPO 可以做到秒级，但如果恢复时需要重放数小时的 WAL，RTO 可能仍然很长。
二、备份类型分类
PostgreSQL 的备份可以从多个维度分类，理解这些维度是选择方案的基础。
- 按物理与逻辑划分：物理备份直接复制数据文件（如
pg_basebackup、文件系统快照），保留完整集群结构，适合整库恢复；逻辑备份导出 SQL 或自定义格式（如pg_dump、pg_dumpall），可跨版本、跨平台迁移，适合单表或单库恢复。 - 按完整性划分：全量备份包含全部数据；增量备份只记录自上次备份以来的变化；差异备份记录自上次全量以来的变化。PostgreSQL 原生通过“基础备份 + WAL 归档”实现增量恢复能力，而非传统意义上的块级增量。
- 按一致性划分：一致性备份（在线热备）在数据库运行中完成，依赖 WAL 保证恢复一致性；离线冷备需停库，简单但影响可用性。
需要特别理解 PITR（Point-In-Time Recovery，时间点恢复）：它把“基础备份”和“WAL 归档”组合起来，可以将数据库恢复到任意一个已归档的时间点。这是 PostgreSQL 灾备能力的核心，也是后续章节的重点。
三、灾备体系分层框架
灾备不是单一技术，而是分层建设的。从低到高大致可分为：
- 备份层：定期全量/增量备份 + WAL 归档，解决“数据可找回”。
- 恢复层：PITR、单表恢复、逻辑恢复，解决“能恢复到目标点”。
- 高可用层：流复制、同步/异步备库、自动故障切换，解决“故障时快速接管”。
- 容灾层：异地副本、跨机房/跨云部署，解决“站点级灾难”。
- 演练与治理层：定期恢复演练、备份校验、监控告警，解决“方案真的有效”。
这五层不是必须全部具备，而是根据业务等级逐层加强。一个只做每日逻辑备份的系统，RPO 可能是一天；加上 WAL 归档后 RPO 可降到分钟级；再叠加流复制，RTO 可降到秒级。理解这个递进关系，才能在设计时知道“加什么、能换来什么”。
四、学习路径与本章定位
本课程共 30 章，整体遵循“先建立目标与框架，再掌握工具与操作，最后形成体系与演练”的路径。第 1 章建立全景认知；后续将依次深入物理备份与逻辑备份的具体工具、WAL 归档配置、PITR 恢复实操、流复制与高可用、异地容灾、备份校验与恢复演练，以及监控与治理。
学习时建议始终带着三个问题：这个手段改善的是 RPO 还是 RTO？它依赖什么前提？失效时如何发现？ 例如配置 WAL 归档时，要关注归档是否连续、失败是否告警；配置流复制时，要关注延迟和切换条件。只有把“目标—手段—验证”串起来，灾备体系才真正成立。
接下来进入具体工具与操作之前，请先记住这张全景图：底层是备份，中间是恢复与高可用，上层是容灾与治理；左侧是 RPO/RTO 目标，右侧是达成目标的手段。后续每一章，都是在为这张图补充一个可落地的细节。