8-3 系统的备份方法 · 波仔的云计算课

📄 一句话概括

上一节讲的是【机器坏了怎么办】，这一节讲的是【数据怎么存】——备份方式只有三种基本手法：全量（每次都存全部）、增量（只存当天的变化）、差异（存自上次全量以来的全部变化）。三者的区别不在【存什么】，而在【省空间】和【省恢复力气】这两件事上，你要牺牲哪一头。而教材说的【暖备份】，就是在这两头之间取的那个折中。

📝 本节和前面几节的关系

它接着 8-2 往下走：上一节讲【备机】——机器层面的冗余；这一节讲【备份】——数据层面的副本。 两者是一套完整方案的两条腿：机器靠备机顶上，数据靠备份找回来。

而下一节 8-4 会问一个更靠后的问题：这些备份，到底该放在哪儿？ ——这一节先解决【怎么存】，下一节再解决【存到哪】。

一、三种基本手法

数据的备份方式，翻来覆去就三种。理解它们的差别，只需要抓住一个问题：每次备份的时候，到底存了多少东西？

全量备份：每一次都把全部数据完整存一份。 好处是恢复最简单——找到最近那份，直接还原就行；坏处是每次都要占一份完整的空间，而且越存越多。
增量备份：第一次存全量，之后每次都只存【自上次备份以来的变化】。 好处是每次存得最少、最省时间；坏处是恢复时要一环套一环——得先还原全量，再按顺序把所有增量一个个补上去，中间少一个都不行。
差异备份：第一次存全量，之后每次都存【自上次全量以来的全部变化】。 这是前两者的折中——每天存得比增量多一点（因为差异会累积），但恢复时只需要【全量 + 最后一份差异】两个文件。

三种手法的名字听着绕，用一个比喻就清楚了：全量是每天重新拍一张完整的全家福；增量是每天只拍今天新来的那个人；差异是每天拍【从上次全家福到现在所有新来的人】。

二、动手 Demo：三种备份方式一周的账

看到什么算成功：

==================================================================================================
【Demo 3】系统的备份方法：暖备份
==================================================================================================

  假设：初始数据 500 GB，每天新增变化 10 GB，连续备份一周。

  【一】三种备份方式的账

  方式      每次备份什么                      一周写入总量          恢复要几个文件
  ------------------------------------------------------------------------------------------
  全量      每一次都备份全部数据              7 x 500 = 3500 GB     1 个
  增量      只备份当天变化的部分              500 + 6 x 10 = 560 GB 1 全量 + 6 增量
  差异      备份自上次全量后的全部变化        500 + 210 = 710 GB    1 全量 + 1 差异

  差异累计：第 2 天 10，第 3 天 20，第 4 天 30，第 5 天 40，第 6 天 50，第 7 天 60，
  合计增量部分 10+20+30+40+50+60 = 210 GB。

  全量最省恢复力气、最费空间；增量最省空间、最费恢复力气。
  差异是折中：每天写得多一点，但恢复时只需要两个文件。

  【二】暖备份的恢复步骤

  第 1 步  从异地取回最近一次全量备份（约 500 GB）
  第 2 步  应用差异备份，补上之后的变化（约 60 GB）
  第 3 步  校验校验和，确认数据完整
  第 4 步  启动服务，跑健康检查
  第 5 步  切回业务流量

  暖备份的关键不在【备份存得下】，而在【恢复拿得回】。

读结果：

第一张表最值得看的是【一周写入总量】这一列。同样是保护这 500 GB 数据，全量一周写了 3500 GB，增量只写了 560 GB——差了 6 倍多。 这就是为什么大数据的系统几乎不可能用纯全量：数据越大，全量越不可行。
但代价藏在【恢复要几个文件】那一列。增量虽然最省空间，恢复时却要按顺序还原 1 份全量加 6 份增量——中间任何一份损坏，链条就断了，而且这个过程很慢。 差异备份就是冲着这个痛点来的：它每天多存一点（差异会累积到 60 GB），换来【恢复时只要两个文件】。
第二段那个【关键不在存得下，而在拿得回】是本节的题眼。很多人做备份时只关心能不能存进去，却很少问能不能顺利取出来。而现实里，恢复过程出问题的比例，远高于备份过程——这正是一个备份方案必须在设计阶段就考虑【恢复路径】的原因。

三、为什么叫【暖备份】

教材给这一节起的名字是【暖备份】，这个【暖】字很传神——它不是冷冰冰躺着的归档，也不是实时同步的镜像，而是【温热】的、随时能拿来用的那一份。

它可以这样理解：

档次	备份的【温度】	含义
冷备份	离线归档	存在磁带或冷存储里，取出来要几小时到几天
暖备份	定期可用	定期备份、能较快恢复，兼顾成本和可用性
热备份	实时同步	一直同步着，随时能顶上，最贵

所以【暖备份】不是某一种具体技术，而是一个【定位】：它牺牲掉【实时】这个最高要求，换取成本的大幅下降，同时保留【能在合理时间内恢复】这个能力。 对绝大多数企业和系统来说，这就是那个【最划算】的档位——因为真正需要【热】的场景，其实很少。

四、恢复才是备份的终点

做备份的人容易陷入一个误区：把【备份成功】当成目标。 但备份真正的终点是【恢复成功】——存进去不算数，取出来能用才算。

所以一个成熟的备份方案，至少要能回答三个问题：

恢复到哪个时间点？（RPO）——这由备份频率决定：每天一次，最坏就丢一天。
恢复要多久？（RTO）——这由恢复过程决定：全量+增量的链条越长，恢复越慢。
恢复出来的是干净的吗？——如果备份里已经混进了被勒索软件加密的文件，恢复回来也是坏的。 所以校验和验证、恢复演练，缺一不可。

这三个问题合起来，就是下一节 8-4 要接着讲的【备份放在哪】——因为 RPO 和 RTO 的实际表现，很大程度上取决于【备份存在什么介质上、离你有多远】。

五、2026 现状

① 【不可变备份】成了标配。 因为勒索软件会先找到并加密你的备份，所以 2026 年的主流做法是给备份加【对象锁】（写进去之后，在一定期限内任何账号都不能改也不能删）——哪怕管理员账号被攻破，备份也动不了。 这已经成了企业备份方案的默认要求。

② 备份的目标从【存下来】变成了【能验证】。 现代备份工具会把【自动恢复验证】做进流程：每备份一次，就在隔离环境里试着恢复一次，确认它真的能用。 因为没验证过的备份，只是【大概存在的数据】。

③ 备份和容灾在走向融合。 早年【备份系统】和【容灾系统】往往是两套独立的东西；现在云上的一体化方案让它们共享同一份数据副本——这也从技术上印证了本课反复强调的那句话：备份和容灾是两道防线，但可以共用同一套基础设施。

30 秒实验

打开你手机上的相册或网盘，做两件事：

看看它的备份设置——是【每次拍照就自动上传】，还是【每天 / 每周同步一次】？
想想如果手机今天坏了，你能找回到什么时候为止的照片？

做完你会对【RPO】这个概念有切身体会：如果它是自动同步的，你的 RPO 几乎是零（照片一张都不会丢）；如果它是一周同步一次，那么这一周拍的照片就悬了。同样一份数据，备份频率不同，你能承受的损失就完全不同——这就是【备份方式】这件事最实在的意义。

常见误区

错误：既然全量备份恢复最方便，那全部用全量就行了。——纠正：全量的代价是【空间和时间】，而且它随数据量线性增长。Demo 里一周写下 3500 GB，只是 500 GB 数据量下的账；如果数据是 50 TB，一周就要写 350 TB——存储扛不住，备份窗口也根本跑不完。 所以全量通常只用来做【每周或每月一次的基线】，日常靠增量或差异来补。
错误：增量备份最省空间，所以最划算。——纠正：省的是备份时的空间，费的是恢复时的时间和风险。恢复一条【1 份全量 + N 份增量】的链，任何一环出问题，整条链就断了——而且链越长，恢复越慢。所以增量适合数据变化快、但对恢复时间要求不苛刻的场景；对【必须快速恢复】的核心系统，差异或【定期全量】往往更稳妥。
错误：备份做得越频繁越好。——纠正：频率直接换成本——备份越频繁，占的存储、花的带宽、跑的时间都越多。而且高频备份会把【误删、写坏的数据】也快速复制好多份——如果你在下午三点误删了数据，而备份每五分钟一次，那你很快就会有多份【已经删掉的数据】。 所以频率要按【能承受丢多久】来定，不是越高越好。
错误：备份成功就等于数据安全了。——纠正：存进去不等于取出来。真实的翻车场景里，备份文件损坏、恢复脚本跑不通、备份里混进了被加密的文件——这些都要到真恢复的那一刻才会暴露。 所以成熟做法是定期做【恢复演练】，把【能不能恢复】这件事从【假设】变成【验证过】。这正是 3-2-1-1-0 原则里那个【0】（恢复验证零错误）要单独列出来的原因。

自测三问（点开对答案）

1. 为什么【差异备份】被认为是【全量】和【增量】之间的折中？ —— 因为**它同时从两头各让了一步**。相对**增量**：**差异每天多存了一点（因为差异会累积到像 60 GB 这样），但换来了【恢复只要两个文件】的简单**。相对**全量**：**差异不用每次存完整备份（一周 710 GB vs 3500 GB），省了空间，但恢复时要多应用一份差异（比全量慢一点点）**。**所以它的位置正好卡在【省空间】和【省恢复力气】中间**——**这也解释了为什么它常被当成企业日常备份的默认选择。** 2. 为什么说【备份的终点是恢复，不是备份成功】？ —— 因为**备份本身不产生任何价值，只有恢复出来能用才有价值**。**一个从没被验证过能恢复的备份，和没有备份在效果上是一样的**——**区别只是后者会让你更早去想办法。** 而现实中，**出问题最多的地方恰恰在恢复环节**：备份文件损坏、增量链条断裂、恢复脚本引用了过期的路径……**这些在【备份成功】的日志里都看不到**。**所以衡量备份体系的指标，不该是【备份成功率】，而是【恢复成功率】。** 3. 为什么【备份频率越高越好】是一个误区？ —— 因为**频率是有代价的，而且它复制的不只是【好数据】**。代价是**存储、带宽和时间**；更隐蔽的问题是**它会把错误同步放大**——**你误删了数据，高频备份会让【错误状态】很快扩散成很多份**。所以正确的做法是**按业务能承受的 RPO 来定频率**：**能容忍丢一天的，就不必做成每分钟一次**。**而在频率之外，还要靠【保留多个历史版本】来对冲【错误被复制】这件事**——**比如保留最近 30 天的每一天，这样误删之后还能往回找。**

☐ 下一节（8-4 备份的位置：灾难恢复）