敲黑板：云服务器备份关键技术大揭秘

我们知道，传统的企业存储系统中基本都包含快照功能，其作用主要是能够进行在线数据备份与恢复。当传统存储（包括：文件，块等）发生应用故障或者文件损坏时可以进行快速的数据恢复，将数据恢复某个可用的时间点的状态。

快照的另一个作用是为存储用户提供了另外一个数据访问通道，当原数据进行在线应用处理时，用户可以访问快照数据，还可以利用快照进行测试等工作。所有存储系统，不论高中低端，只要应用于在线系统，那么快照就成为一个不可或缺的功能。

华为作为拥有 10 余年研发经验的专业存储厂商，把其企业数据备份的软件能力进行了服务化，并且由华为云推出了云服务器备份服务。

什么是云服务器备份

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

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

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

一致性与一致性组

云服务器备份的“一致性”，是指在应用看来备份中的数据是同一时刻的，用该备份恢复后，应用能继续正常运行。存储领域通常将该一致性分为应用一致性（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，刷缓存；

（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 的记录，无法通过日志正确恢复数据，造成数据丢失。

云服务器备份的具体实现

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

3.1 云服务器备份实现应用一致性

图 3.1 云服务器备份实现应用一致性

（1） 开始进行云服务器备份

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

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

（4） 生产存储创建快照

（5） 解冻 IO

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

3.2 云服务器备份实现崩溃一致性

图 3.2 云服务器备份实现崩溃一致性

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

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

上文中我们详细讨论了云服务器备份的流程和一致性，由此我们得出一个概念，云服务器备份就是让虚拟机里面的“云硬盘们”能够 happy 地拍个“全家福”，通过这个“全家福”我们随时可以感受到当年的幸福状态（恢复到备份时的数据和状态）。所以，现在你知道云服务器备份是什么了吧。

本文转载自 华为云产品与解决方案 公众号。

原文链接：https://mp.weixin.qq.com/s/PIWgNdZpQbL188idZojyqQ