1. 灾备基础：什么是灾备？RPO与RTO核心概念、灾备等级标准（SHARE 78）、常见灾备架构（主备、双活、多活）
1.1 到底什么是灾备？
灾备，全称是「灾难备份与恢复」。
说白了，就是给你的系统买一份「保险」。你想想看，机房断电、光纤被挖断、勒索病毒、甚至地震火灾——这些事不是会不会发生，而是什么时候发生。我做了十几年灾备，见过太多「出事之前觉得没必要，出事之后追悔莫及」的案例。
灾备的核心就两件事：
- 备份：把你的数据在别处存一份。
- 恢复：出事之后，能快速把业务拉起来。
嗯，这里要注意——备份不等于灾备。很多人以为做了磁带备份就万事大吉了。我曾经有个客户，每天老老实实做全量备份，结果机房着火了，备份磁带就在机房的柜子里……全烧没了。这叫「备份」，不叫「灾备」。真正的灾备，要求备份数据必须存放在物理隔离的另一个地点。
一句话总结：灾备 = 异地数据副本 + 可执行的恢复流程 + 定期验证。
1.2 RPO与RTO：灾备的两个核心指标
做灾备方案，永远绕不开两个数字：RPO 和 RTO。这两个指标直接决定了你要花多少钱、用什么技术。
RPO（Recovery Point Objective）—— 你能丢多少数据？
RPO 衡量的是「数据丢失量」。举个例子：
- 如果 RPO = 1 小时，意味着最多丢失最近 1 小时的数据。
- 如果 RPO = 0，就是零数据丢失，所有写入操作必须实时同步到灾备端。
我在项目中遇到过一家银行，核心交易系统要求 RPO = 0。这意味着每次交易落盘，必须等灾备端确认写成功，主库才能返回「成功」给客户。延迟确实高了点，但金融监管要求摆在那，没得商量。
RTO（Recovery Time Objective）—— 你多久能恢复？
RTO 衡量的是「业务中断时间」。从灾难发生到业务恢复，这中间的每一分钟都是钱。
- RTO = 30 分钟：意味着 30 分钟内必须拉起业务。
- RTO = 4 小时：可以接受半天左右的停机。
我个人习惯，跟客户聊需求时一定会追问一句：「如果系统挂了，老板能接受停多久？」很多客户一开始说「越快越好」，但一听到成本，就变成「4 小时也行」。RPO 和 RTO 本质上是个成本选择题。
| 指标 | 含义 | 典型场景 | 技术手段 |
|---|---|---|---|
| RPO | 数据丢失量 | 银行交易、订单系统 | 同步复制、异步复制 |
| RTO | 恢复耗时 | 门户网站、OA 系统 | 冷备、热备、双活 |
避坑指南：我曾经见过一个项目，RPO 写的是「接近零」，RTO 写的是「秒级切换」。结果一测试，数据丢了 20 分钟，切换花了 40 分钟。为什么？因为方案设计时没考虑网络抖动和人工确认环节。记住：RPO/RTO 必须是经过实测验证的数字，不是 PPT 上拍脑袋写的。
1.3 灾备等级标准：SHARE 78
说到灾备等级，业界最经典的标准是 SHARE 78。这是 1990 年代由 SHARE 组织（一个大型机用户组织）定义的 7 个灾备等级。虽然年代久远，但今天几乎所有灾备方案都能在这个框架里找到对应位置。
| 等级 | 名称 | RPO | RTO | 典型方案 |
|---|---|---|---|---|
| Tier 0 | 无灾备 | 无限制 | 无限制 | 啥也没做 |
| Tier 1 | 磁带备份 | 24 小时 | 24~72 小时 | 每日磁带，异地存放 |
| Tier 2 | 备份 + 热备机房 | 24 小时 | 12~24 小时 | 磁带 + 预配机房 |
| Tier 3 | 电子链路 | 4~12 小时 | 4~12 小时 | 磁盘到磁盘复制 |
| Tier 4 | 快照 + 批量传输 | 1~4 小时 | 2~8 小时 | 定时快照 + 异步复制 |
| Tier 5 | 两阶段提交 | 分钟级 | 1~4 小时 | 同步复制 + 自动切换 |
| Tier 6 | 零数据丢失 | 0 | 分钟级 | 同步复制 + 自动切换 + 一致性组 |
| Tier 7 | 自动化灾备 | 0 | 秒级 | 双活/多活 + 自动化编排 |
我个人的经验是：大部分企业做到 Tier 4~Tier 5 就够用了。Tier 6 和 Tier 7 的成本是指数级上升的，只有金融、电信、政务这些行业才需要。别一上来就追求「零丢失」，先问问业务部门到底能接受丢多少。
1.4 常见灾备架构：主备、双活、多活
架构选型，说白了就是 RPO/RTO 和成本之间的博弈。我按复杂度从低到高给你捋一遍。
1.4.1 主备架构（Active-Passive）
这是最常见的架构。平时只有主站点提供服务，备站点只同步数据，不对外服务。出事后手动或自动切换到备站。
- 优点：架构简单，成本低。
- 缺点：备机资源浪费，切换有延迟。
- 适用场景：OA、邮件、非核心业务。
我记得有个客户，用了主备架构，RPO 设的是 15 分钟。结果某次光纤被挖断，备站数据落后了 12 分钟。业务部门炸了，说丢了 12 分钟订单数据。但当初签 SLA 时白纸黑字写的就是 15 分钟，所以……也没办法。这就是主备的局限性。
1.4.2 双活架构（Active-Active）
两个站点同时对外提供服务，流量分摊。任何一个站点挂了，另一个站点直接接管全部流量。
- 优点：资源利用率高，切换无感知。
- 缺点：架构复杂，需要解决数据冲突和一致性问题。
- 适用场景：核心交易、支付、实时业务。
双活最头疼的问题是什么？是「脑裂」。两个站点之间的网络断了，两边都以为对方挂了，各自开始接管——数据就乱套了。我曾经处理过一个双活集群的脑裂事故，花了整整一个通宵才把数据对回来。嗯，从那以后，我每次做双活方案都会强制要求加仲裁节点。
1.4.3 多活架构（Multi-Active）
三个或更多站点同时提供服务。这是目前大型互联网公司和金融机构的主流选择。
- 优点：容灾能力最强，单点故障不影响全局。
- 缺点：成本极高，运维复杂度指数级上升。
- 适用场景：全球化业务、金融核心、云原生架构。
多活架构里，我最推荐的是「单元化」模式。每个站点处理特定区域或特定用户的请求，数据按维度分片。这样即使某个站点全挂了，也只影响一部分用户，而不是全局瘫痪。
我的建议：别一上来就搞双活或多活。先问自己三个问题：业务能接受多少数据丢失？能接受多长停机时间？预算有多少？这三个问题回答清楚了，架构自然就出来了。
1.5 本章知识体系总览
下面这张图把本章的核心逻辑串起来了。从灾备定义出发，到 RPO/RTO 两个指标，再到 SHARE 78 等级，最后落到三种架构选型。你可以把它当作一张「灾备入门地图」。
1.6 本章小结
这一章我们聊了灾备的底层逻辑。说白了，就三句话：
- 灾备不是备份——备份是手段，灾备是体系。
- RPO 和 RTO 是方案的起点——这两个数字定下来，后面的技术选型才有依据。
- 架构选型要务实——主备、双活、多活没有的好坏，只有合不合适。
我见过太多「为了双活而双活」的项目，最后运维团队累得半死，业务也没感受到什么好处。记住：灾备的目标是让业务在灾难面前能活下去，不是让架构图看起来好看。