一、SaaS灾备概述：从“数据丢了”到“业务不停”

大家好，我是老张。做SaaS运维这些年，我见过太多因为数据丢失而彻夜难眠的团队。今天咱们聊聊灾备——这个听起来有点“重”的话题。

说实话，很多SaaS创业公司早期都不太重视灾备。觉得“数据量不大，出不了大事”。嗯，我当年也这么想，直到有一次……算了，先讲正题。

1.1 什么是SaaS系统？

SaaS，全称Software as a Service，软件即服务。说白了，就是你不用买软件安装包，不用自己搭服务器，直接通过浏览器就能用的系统。

比如你们公司用的钉钉、飞书、Salesforce，这些都是SaaS。用户按月付费，厂商负责维护。

但这里有个关键点：数据不在用户手里，在厂商的服务器上。这意味着什么？

• 用户的数据安全完全依赖厂商
• 一旦厂商出问题，用户可能什么都拿不回来
• 所以灾备不是“可选项”，是“必选项”

1.2 为什么需要灾备？

你可能觉得：“我的系统很稳定啊，一年都不出一次故障。” 我告诉你，这不是理由。

灾备不是为了应对“大概率事件”，而是为了应对“小概率但后果严重的事件”。

我在项目中遇到过这样的事：某SaaS平台因为运维人员误操作，删除了生产数据库的一个核心表。没有灾备，恢复花了整整3天。那3天，客户电话被打爆，CEO直接拍桌子。

所以，灾备解决的是三个问题：

1. 数据不丢——硬件坏了、误删了、被攻击了，数据还能找回来
2. 业务不停——就算主站点挂了，用户还能用备用站点继续工作
3. 合规要求——很多行业（金融、医疗）有明确法规，必须做灾备

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

做灾备方案，你一定会遇到两个词：RPO和RTO。这两个指标决定了你的灾备方案“好不好”。

指标	全称	中文	通俗理解
RPO	Recovery Point Objective	恢复点目标	你能容忍丢多少数据？
RTO	Recovery Time Objective	恢复时间目标	你能容忍停多久？

举个例子你就明白了：

• RPO=1小时：意味着最多丢失1小时的数据。如果每小时备份一次，出事后最多恢复到1小时前的状态。
• RTO=4小时：意味着从故障发生到系统恢复，必须在4小时内完成。

我个人的习惯是：先定RPO，再定RTO。因为RPO决定了备份策略（多久备份一次），RTO决定了恢复策略（用什么方式恢复）。

1.4 灾备等级标准

灾备不是“做或不做”的问题，而是“做到什么程度”的问题。国际上有个通用的分级标准，我整理了一下：

等级	名称	RPO	RTO	典型方案
0级	无灾备	无限制	无限制	啥也不做
1级	本地备份	24小时	24-72小时	磁带/磁盘备份
2级	异地备份	4-24小时	12-48小时	异地存储备份
3级	冷备	1-4小时	4-12小时	备用服务器+数据同步
4级	温备	15分钟-1小时	1-4小时	主备切换+准实时同步
5级	热备	秒级	分钟级	双活/多活架构

你想想看，大部分SaaS公司做到3级或4级就够用了。5级热备成本太高，一般只有银行、交易所这种才需要。

我记得有一次给一个电商SaaS做方案，客户非要上5级热备。我算了一笔账：年收入500万，灾备成本要300万。我说：“老板，你这等于拿60%的收入买保险，不划算。” 最后我们定了4级温备，成本降到50万，客户很满意。

1.5 小结

这一章我们聊了：

• SaaS系统的本质是“服务”，数据安全是命脉
• 灾备解决“数据不丢”和“业务不停”两个核心问题
• RPO和RTO是衡量灾备方案的两个关键指标
• 灾备等级从0到5，选择适合自己业务的就好

下一章，我会带你看看SaaS系统常见的故障场景，以及如何设计一个“够用又不贵”的备份策略。咱们到时候见。