一、灾备基础：什么是灾备？为什么需要灾备？RPO与RTO核心指标
1.1 先聊聊我理解的灾备
灾备，全称是「灾难备份与恢复」。说白了，就是给你的业务系统买一份「保险」。这份保险不是防止出险，而是保证出险后你能快速恢复。
我见过不少刚入行的朋友，觉得灾备就是「多买几台服务器，把数据拷过去」。嗯，这个理解太浅了。真正的灾备，要回答三个问题：
- 数据丢了能找回多少？—— 丢1条记录还是丢1天记录？
- 系统挂了多久能恢复？—— 5分钟还是5小时？
- 恢复后还能正常用吗？—— 数据一致不一致？业务逻辑通不通？
我在2018年帮一家金融客户做灾备演练，他们的备份脚本跑了三年没出过问题。结果真到演练那天，恢复出来的数据库少了两张表。为什么？因为脚本只备份了主库，没备份归档日志。你看，灾备不是「做了就行」，而是「做了且验证过才行」。
核心定义：灾备 = 数据备份 + 系统冗余 + 恢复流程 + 定期演练。四者缺一不可。
1.2 为什么需要灾备？—— 我踩过的坑
这个问题，我建议你反过来想：没有灾备，最坏的结果是什么？
我曾经服务过一家电商客户，他们的核心数据库跑在一台物理机上。没有备库，没有异地备份，连定期导出都没有。运维小哥说：「我们这台机器用了五年没出过事。」结果呢？硬盘坏了。数据全丢。公司直接停业三天，损失超过200万。
你想想看，这个代价够不够买一套完整的灾备方案？
常见的灾难场景，我列一下：
| 灾难类型 | 典型场景 | 发生概率 | 影响范围 |
|---|---|---|---|
| 硬件故障 | 硬盘损坏、电源烧毁、内存故障 | 高 | 单机或单集群 |
| 软件故障 | 操作系统崩溃、数据库损坏、配置错误 | 中 | 单系统或单应用 |
| 人为误操作 | 误删表、误改配置、误执行脚本 | 中 | 单库或单表 |
| 逻辑错误 | 程序bug导致数据写坏、批量更新出错 | 低 | 全业务 |
| 自然灾害 | 火灾、地震、洪水、雷击 | 极低 | 整个数据中心 |
| 网络攻击 | 勒索病毒、DDoS、数据篡改 | 中 | 全业务 |
你看，硬件故障和人为误操作是最常见的。我个人的习惯是：先防高频，再防低频。别一上来就搞两地三中心，先把本地备份做好，把误删恢复练熟。
避坑指南：我曾经见过一个团队，花了大价钱做异地灾备，结果本地备份策略是「每天全量一次」。某天凌晨数据库坏了，恢复时发现昨天的全量备份文件损坏了。异地灾备倒是好的，但网络带宽只有10Mbps，恢复1TB数据需要23小时。这就是典型的「重架构、轻验证」。
1.3 RPO与RTO：灾备的「两把尺子」
聊灾备，绕不开两个指标：RPO 和 RTO。我习惯把它们叫做「灾备的两把尺子」。
1.3.1 RPO —— 你能接受丢多少数据？
RPO（Recovery Point Objective），恢复点目标。它衡量的是：灾难发生时，你能容忍丢失多长时间的数据。
举个例子：
- RPO = 0：数据零丢失。每次写入都要同步到灾备端。
- RPO = 1小时：最多丢1小时的数据。每小时做一次备份或同步。
- RPO = 1天：每天做一次全量备份，最多丢1天的数据。
我在项目中遇到过最极端的RPO要求是金融核心交易系统，RPO必须为0。这意味着每一笔交易都要实时同步到灾备中心。我们用了同步复制 + 分布式一致性协议，延迟控制在5毫秒以内。代价呢？网络带宽成本翻了3倍。
1.3.2 RTO —— 你能等多久恢复？
RTO（Recovery Time Objective），恢复时间目标。它衡量的是：从灾难发生到业务恢复，你能容忍多长时间。
还是举例子：
- RTO = 5分钟：系统挂了，5分钟内必须恢复。
- RTO = 4小时：4小时内恢复就行，可以接受手动切换。
- RTO = 24小时：明天上班前恢复就行。
RTO越短，技术方案越复杂，成本越高。我建议你根据业务重要性来定RTO，别一刀切。
关键认知：RPO和RTO是业务指标，不是技术指标。它们应该由业务部门提出，技术部门负责实现。我见过太多「技术部门自己定RPO/RTO」的案例，结果业务部门根本不认。
1.3.3 RPO与RTO的关系
这两个指标不是独立的。我画了一张图，帮你理解它们的关系：
1.3.4 不同场景下的RPO/RTO参考值
我整理了一份常见业务场景的RPO/RTO参考值，你可以直接拿来用：
| 业务场景 | 典型RPO | 典型RTO | 推荐方案 |
|---|---|---|---|
| 金融核心交易 | 0 | < 5分钟 | 同步复制 + 自动切换 |
| 电商订单系统 | < 1分钟 | < 15分钟 | 异步复制 + 半自动切换 |
| 企业ERP | < 1小时 | < 4小时 | 定时备份 + 手动恢复 |
| 开发测试环境 | < 1天 | < 24小时 | 每日全量备份 |
| 归档数据 | < 1周 | < 1周 | 冷备 + 磁带/对象存储 |
我的建议：别追求「极致RPO/RTO」。我见过一个客户，非要把内部OA系统的RPO做到0，RTO做到5分钟。结果一年花了200万，OA系统本身才值50万。灾备投入要和业务价值匹配，这是基本原则。
1.4 灾备的三种常见模式
根据RPO/RTO的不同，灾备模式可以分为三种。我简单说一下：
- 冷备（Cold Standby）：灾备端不运行，只有数据备份。恢复时需要手动搭建环境、恢复数据。RTO通常以小时计。
- 温备（Warm Standby）：灾备端运行基础环境，数据定期同步。恢复时只需启动应用。RTO通常以分钟计。
- 热备（Hot Standby）：灾备端完全运行，数据实时同步。故障时自动切换。RTO通常以秒计。
我个人习惯用「车」来比喻：冷备是「备胎在车库」，温备是「备胎在车上」，热备是「已经换好备胎在跑了」。你想想看，你的业务需要哪种？
1.5 本章小结
灾备不是「买几台服务器、装个备份软件」就完事了。它是一套完整的体系：数据备份 + 系统冗余 + 恢复流程 + 定期演练。RPO和RTO是衡量灾备能力的核心指标，它们决定了你的技术方案和投入成本。
最后说一句：没有经过演练的灾备方案，等于没有灾备。这是我从业十年最深刻的教训。