一、灾备认知：什么是灾备、为什么需要灾备、灾备与备份的区别、RPO与RTO核心指标

1.1 到底什么是灾备？

灾备，全称叫「灾难备份与恢复」。

说白了，就是给你的业务系统买一份「保险」。这份保险不是保数据不丢，而是保当灾难来临时，你的业务还能继续跑。

我见过不少刚入行的朋友，一听到「灾备」就以为是多拷几份数据。嗯，这里要纠正一下——灾备的核心是业务连续性，不是数据冗余。

灾难分很多种：

• 硬件故障：磁盘坏了、服务器宕了、交换机烧了
• 软件故障：数据库崩了、操作系统挂了、应用出Bug了
• 人为事故：误删数据、误操作配置、恶意破坏
• 自然灾害：地震、洪水、火灾、雷击
• 网络攻击：勒索病毒、DDoS、APT攻击

灾备要解决的是：不管哪种灾难来了，你的业务都能在可接受的时间内恢复，或者干脆不中断。

1.2 为什么需要灾备？

这个问题我经常被问到。有些老板觉得：「我们数据量不大，每天备份一下不就行了？」

我讲个真实案例。几年前我帮一家电商公司做咨询，他们没做灾备，只有每天凌晨的冷备份。结果某天下午三点，核心数据库被误删了一张订单表。你猜恢复花了多久？

整整18个小时。因为冷备份恢复需要先搭环境、重放日志、校验数据……那18小时里，线上交易全部停摆。损失了多少？几百万。

为什么会这样？因为备份≠灾备。备份只管「数据在不在」，灾备管的是「业务能不能跑」。

需要灾备的原因，归纳起来就三条：

1. 业务不能停：停机就是损失，每秒钟都是钱
2. 数据不能丢：丢了客户数据、交易记录，后果可能是法律诉讼
3. 合规要求：金融、医疗、政务等行业，监管明确要求必须做灾备

1.3 灾备与备份的区别

很多人把备份和灾备混为一谈。我习惯用一个比喻来解释：

• 备份 = 你把重要文件复印了一份，锁在抽屉里
• 灾备 = 你不仅复印了文件，还在隔壁楼准备了一间一模一样的办公室，随时可以搬过去继续办公

区别很明显，我整理了一张表：

对比维度	备份	灾备
目标	保护数据不丢失	保证业务不中断
范围	数据层面	数据 + 应用 + 网络 + 基础设施
恢复对象	文件、数据库、虚拟机	整个业务系统
恢复时间	几小时到几天	几分钟到几小时
技术手段	定时备份、增量备份	主备切换、双活、异地容灾
成本	相对较低	相对较高

你想想看，备份是灾备的基础，但光有备份远远不够。灾备是在备份之上，再加了一层「业务连续性」的保障。

1.4 RPO与RTO：灾备的两个核心指标

做灾备，绕不开两个指标：RPO 和 RTO。

这两个指标决定了你的灾备方案长什么样。我每次做项目，第一件事就是跟业务方敲定这两个数字。

RPO（Recovery Point Objective）—— 你能丢多少数据？

RPO 衡量的是「数据丢失的容忍度」。单位是时间。

举个例子：

• RPO = 1小时，意味着最多丢1小时的数据
• RPO = 0，意味着数据零丢失

RPO 越小，对技术的要求越高。RPO=0 通常需要同步复制，成本也最高。

RTO（Recovery Time Objective）—— 你能停多久？

RTO 衡量的是「业务中断的容忍度」。单位也是时间。

举个例子：

• RTO = 4小时，意味着业务中断后必须在4小时内恢复
• RTO = 0，意味着业务永远不中断（双活架构）

RTO 越小，对基础设施的要求越高。RTO=0 需要两地三中心甚至多活架构。

RPO与RTO的关系

这两个指标不是独立的。我画了一张图来说明：

从图上可以看得很清楚：

• RPO 是灾难发生到数据恢复点之间的「数据黑洞」
• RTO 是灾难发生到业务恢复之间的「业务真空期」

我个人的经验是：先定 RTO，再定 RPO。因为业务中断的代价通常比数据丢失更大。你想想看，数据丢了还能补录，业务停了客户可就跑了。

常见场景的指标参考

业务类型	RPO	RTO	推荐方案
核心交易系统	0 ~ 5分钟	0 ~ 15分钟	双活 / 主备同步
一般业务系统	15分钟 ~ 1小时	1 ~ 4小时	主备异步 / 定时备份
非关键系统	1 ~ 24小时	4 ~ 24小时	每日备份 + 冷备
归档数据	24小时以上	24 ~ 72小时	离线备份 / 磁带库

1.5 本章小结

这一章我们聊了灾备最基础的东西：

• 灾备是什么——业务连续性的保险
• 为什么需要灾备——业务不能停、数据不能丢、合规要满足
• 灾备与备份的区别——备份保数据，灾保管业务
• RPO与RTO——衡量灾备方案的两个核心尺子