【云硬盘大咖秀】【第一期】整机备份之一家人就要整整齐齐

在除夕的24：00，还有许多家人没有回家，大家相约拍下各自的笑脸制作成一张全家福：

大表哥：亲们，来，我们准备拍照啦！

海南度蜜月的表姐：茄子！

留学美国的堂弟：茄子！

还在工作岗位上的码农表哥：茄子！

……

最后所有的照片拼在一起，一家人保持一个表情和口型，气势还是很完美的！

发挥一下想象力，如果每一个家庭是一台服务器，每一个家人都是一块云硬盘，每个人给自己拍的照片都是一个快照，最后所有照片拼在一起就定格了除夕24:00点全家人的笑脸，咦~~这个全家福听起来怎么很像存储技术中的整机备份？

1.    什么是整机备份

整机备份又称云服务器备份（Cloud Server Backup Service，CSBS），可以为弹性云服务器（Elastic Cloud Server，ECS）提供备份服务，支持基于一致性组快照技术的多云硬盘备份服务，并支持利用备份数据恢复弹性云服务器数据，最大限度保障用户数据的安全性和正确性，确保业务安全。

简而言之，就是在病毒入侵、人为误删除、软硬件故障等场景下，通过整机备份能将数据恢复到备份的时间点。

要做到整机备份，首先必须要保证各个云硬盘备份的一致性，这就涉及到一致性和一致性组。

2.    一致性与一致性组

整机备份的“一致性”，是指在应用看来备份中的数据是同一时刻的，用该备份恢复后，应用能继续正常运行。存储领域通常将该一致性分为应用一致性（Application Consistency）和崩溃一致性（Crash Consistency）。

业界权威的观点：

Application Consistency ：Consistent copies are created after applications are gracefully shut down, quiesced, or put in hot backup mode。

Crash Consistency：Creates point-in-time copy of storage that is usable with crash recovery applications，Creates crash consistent copies without coordinating with applications. However, write ordering is maintained for dependent writes in copies across volumes. It’s a logical dependency,not a time dependency.

英文很拗口？那我们就来通俗的说一说——

应用一致性，简而言之就是打快照的时候业务不下IO。实现方法：（1）冻结IO，刷缓存（hold住情绪，把之前的表情从脸上刷走、保持微笑）；（2）对一组云硬盘打快照（拍照）；（3）解冻IO（拍完了照、想摆啥表情就摆啥表情）。

崩溃一致性指系统崩溃（突然掉电或死机）时数据所处的一致性状态，理论上任何应用都应该能处理突然掉电或死机的情况，即系统恢复后应用能根据崩溃时数据的状态继续业务或正常开始新业务。崩溃一致性对应用下IO的顺序有时序上的要求，满足崩溃一致性的备份要保证数据之间时序上的依赖关系不被破坏。整机备份满足崩溃一致性的实现方法：打一致性组快照。

说到一致性组快照，要先介绍一下什么是一致性组。典型的企业应用，譬如数据库场景，数据往往分布在多个云硬盘上，数据之间的依赖关系也在多个云硬盘之间存在，这多个云硬盘就组成了一致性组。

图2.1 日志盘与数据盘组成的一致性组

譬如，在图2.1的例子中，应用必须等待写日志(IO1)完成才会去写数据(IO2)，且必须等待写数据(IO2)完成才会去删日志(IO3)，因此该Log disk与Data disk组成了一个简单的崩溃一致性组。

为了使一致性组快照满足崩溃一致性，底层存储对各个云硬盘创建出来的快照有时序上的要求。

下面我们来看创快照的时序正确的场景：

场景一：在t1ϵ(T1,T2)时刻对Log disk打快照；在t2ϵ(T1,T2)时刻对Data disk打快照

图2.2   正确时序：一致性组快照中只能读到IO1

如图2.2所示， Snap_log中可以读到IO1， Snap_data中不包含IO2。这种情况是从一致性组快照中只读到了IO1，满足时序。如果系统崩溃，我们可以将数据恢复到t2。

场景二：在t1ϵ(T1,T2)时刻对Log disk打快照；在t3ϵ(T2,T3)时刻对Data disk打快照

图2.3  正确时序：一致性组快照中能读到IO1和IO2

如图2.3所示， Snap_log中可以读到IO1，Snap_data中可以读到IO2，这种情况是从一致性组快照中读到了IO1和IO2，满足时序。如果系统崩溃，我们可以将数据恢复到t3。

换言之，Log disk和Data disk打快照的时序需要满足：在这两个快照中，要么三个IO都没有，要么只能读到IO1，要么能读到IO1和IO2，要么能读到IO1、IO2和IO3，即这两个快照对于这三个IO满足时序依赖。

下面我们看一个错误的打快照的时序：

场景三：在t0ϵ(0,T1)时刻对Log disk打快照；在t3ϵ(T2,T3)时刻对Data disk打快照

图2.4  错误时序：一致性组快照中不能读到IO1可以读到IO2

如图2.4所示， Snap_log中读不到IO1， Snap_data中可以读到IO2，这种情况违背了IO1->IO2->IO3的时序依赖。假如写IO2的过程中出错，此时Snap_log中没有对IO1的记录，无法通过日志正确恢复数据，造成数据丢失。

3、整机备份的具体实现

第2部分，我们介绍了应用一致性和崩溃一致性，对应这两种不同的一致性，整机备份有两种实现方式。

      3.1整机备份实现应用一致性

图3.1    整机备份实现应用一致性

（1）    开始进行整机备份

（大表哥说：准备拍照了哦）

（2）    查询虚拟机中的云硬盘列表

（全家人分别用手机对准自己）

（3）    后端存储收到消息后，对虚拟机冻结IO，刷缓存

（大家控制表情，把之前的表情刷到脑后，脸上只留下这一刻的笑容）

（4）    生产存储创建快照

（ “啪”地一声按快门拍照）

（5）    解冻IO

（拍完了照，想咋样就咋样）

（6）    备份软件将快照备份到“备份存储”中

（照片自动存到手机里）

3.2整机备份实现崩溃一致性

      图3.2    整机备份实现崩溃一致性

对比图3.1和图3.2，可以看出实现崩溃一致性，对上层应用不可见，不需要冻结和解冻IO，但是要在生产存储中打一致性快照，一致性组快照需要满足时序依赖，详见本文第2部分。

综上，应用一致性备份间隔不能太短，否则应用需要频繁刷数据，影响业务；崩溃一致性组快照则可以在1秒内完成且应用不感知。应用一致性与崩溃一致性各有其特点，上层可根据不同的应用场景灵活选择。

Finally~

上文中我们详细讨论了整机备份的流程和一致性，由此我们得出一个概念，整机备份就是让虚拟机里面的“云硬盘们”能够一家人happy地拍个“全家福”，通过这个“全家福”我们随时可以感受到当年的幸福状态（恢复到备份时的数据和状态）。所以，现在你知道整机备份是什么了吗？哈哈，是的，整机备份就是一家人要整整齐齐~~在此给大家拜个晚年，祝大家新年快乐！