08 真出故障时靠什么救命: 备份、恢复与高可用基本盘

很多系统表面上“有备份、有主从”，但真正出故障时依然手忙脚乱。原因通常不复杂: 备份只是做了，没有验证；高可用只是搭了，没有边界认知；恢复流程写了，但从来没演练过。数据库领域最值钱的能力之一，就是把“有方案”变成“真能恢复”。

先分清三件事

目标是保住数据。

目标是把数据和服务恢复到可用状态。

目标是降低主库故障对业务的中断时间。

这三件事互相关联，但不能混为一谈。高可用不等于能回到正确时间点，备份存在也不等于恢复一定成功。

如果这两个指标没人定义，备份策略、高可用策略、恢复演练就没有统一目标，最后通常会变成“能配多少配多少”，但真正关键的地方反而没配对。

对绝大多数业务系统来说，下面这套策略已经是比较稳的基本盘:

这几样各自解决的问题不同，合在一起才构成完整恢复体系。

常见原因包括:

数据库恢复最怕的不是技术难，而是“平时从没认真做过”。

如果主库误删数据、误执行 DDL、误更新大量记录，错误同样可能被复制出去。高可用提升的是可用性，不是数据时间回退能力。

同步复制能降低数据丢失风险，但也会抬高提交延迟和故障复杂度。是否启用，必须结合 RPO/RTO 和业务特征判断。

对抗人为误操作时，延迟副本往往比普通热备更有价值。它不是用来提升性能的，而是用来争取修复窗口。

如果一套方案没有演练过，这套方案最多只能叫“设计”，还不能叫“能力”。

问团队三个问题:

这三个问题如果回答不清楚，高可用和恢复体系大概率都不算成熟。

真正可靠的 PostgreSQL 体系，不是备份做得多，而是恢复路径清晰、边界明确、演练真实。