详解云与备份之VMware虚机备份和恢复

(编辑：jimmy 日期: 2024/11/16 浏览：3 次 )

1. 与备份有关的VMWare基础知识

1.1 VMware 虚机磁盘在 ESXi 宿主机上的文件

简单来说，虚机的每个虚拟磁盘由ESXi 宿主机上的三个文件组成（这里的虚机名字是 sammy-target-win-small，下面是其第一个磁盘对应的三个文件）：

sammy-target-win-small.vmdk （配置文件，大小 633 字节）
sammy-target-win-small-flat.vmdk （二进制文件，大小 12884901888 字节）
sammy-target-win-small-ctk.vmdk （二进制文件，大小 78694 字节）

其中，

第一个文件保存的是该磁盘的元数据，其中包括另外两个文件的信息

# Extent description
RW 25165824 VMFS "sammy-target-win-small-flat.vmdk"

# Change Tracking File
changeTrackPath="sammy-target-win-small-ctk.vmdk"

第二个文件是 Extent description 文件，二进制数据保存在这个文件中。下面会介绍使用API获取该文件中数据的方法。

第三个文件是 CTK 文件。下面讲到 CTK 的时候再说。

1.2 快照（Snapshot）

虚机的快照是虚机在某个时间点的状态和数据，其中，状态是指虚机的状态，包括运行状态，配置等；数据是指虚机的虚拟磁盘中的数据。快照的基本操作包括：

创建快照（create）
删除快照（delete）
快照合并（consolidate）
恢复到快照（revert）

1.2.1 创建快照

对上面的虚机创建一个快照，除了快照定义文件以外，对该磁盘，新增了三个文件：

-rw-------  1 root   root    786944 Jul 11 10:55 sammy-target-win-small-000001-ctk.vmdk
-rw-------  1 root   root     28672 Jul 11 10:55 sammy-target-win-small-000001-delta.vmdk
-rw-------  1 root   root      428 Jul 11 10:55 sammy-target-win-small-000001.vmdk

第一个依然是 ctk 文件，第二个是 delta 文件，第三个是非二进制文件。然后再创建第二个快照，就成了这样子：

（RW = 读写，RO = 只读）

从数据的角度看：

（绿色部分是从虚机视角看数据；最下面的红框是 base vmdk 中的数据；中间的红框是 delta vmdk 中的数据）

现在可以简单总结一下 VMware 快照的特点：

快照保存虚机在某一个时间点的状态和数据
对一个虚机做快照，相当于将虚机当前的磁盘设为只读模式，然后创建 delta vmdk 文件，它将会接受新的数据写操作。在存在多个快照的情况下，之前的快照磁盘变为只读。
写损失：写的时候，遵循 Copy-on-write 机制，按照数据分块，当需要修改某一块中的数据时，先将它从父vmdk 中拷贝到 delta vmdk，然后再对它修改。
读损失：当读取某一块数据时，ESXi 需要判断从哪里去读：对于没有修改的数据块，从父 vmdk 读；对已经修改了的数据块，从 delta vmdk 读。可见，客户端的一次读操作，可能需要从不同的 vmdk 上读取数据。
delta vmdk 的大小不会超过 base vmdk 的大小，因为极限情况是所有的数据都被拷贝到delta vmdk 并且都没修改了。
因为快照会带来读和写损失，因此一个虚机不能有太多的快照。vSphere 限定一个虚机最多有 32 个快照，但是建议最多只有 2-3 个，而且快照的保留时间不超过一天。

1.2.2 删除快照

显然，快照只是内部数据，保存的是过去某时间点虚机的状态，对外部不可见，因此，删除快照不能影响虚机当前的状态和数据。因此，这里有三种可能：

（1）快照是基于原始虚机的：delta vmdk 中的数据会向 base vmdk 合并，然后 delta vmdk 被删除。（如下图中的s1）

（2）待删除快照在虚机的数据路径上：delta vmdk 中的数据会想父快照的 vmdk 合并，然后delta vmdk 被删除。（如下图中的s2）

（3）待删除快照不再虚机的数据路径上：不需要合并，直接删除。（如下图中的 s3）

现在可以简单总结一下删除快照的特点：

删除快照意味着快照之后的改变会被合并进快照之前的数据，因此，虚机再也无法回到所做快照之时的状态了。
删除快照过程包括两个异步的操作：从 Snapshot manager 中将快照删除，vmdk 数据合并。如果第一步成功而第二步失败，那么将有残留的 delta 文件被保留下来，这是就需要下面将介绍的手工合并操作。
删除快照可能会打来大量的数据写操作，这期间，虚机的性能会受到负面影响
删除快照有时候要花费很长的时间，特别是对于长时间存在的大容量磁盘的快照。 VMware 专门出了一个KB来让用户估计所需要的时间：Estimating the time required to consolidate snapshots during the snapshot removal for VMware ESX and VMware ESXi (2053758)
当删除所有快照时，自从 vSphere 4 Update 2 开始起过程有了优化，不再是重定向下一层一层地合并，而是各层都直接合并到 base disk。

1.2.3 快照合并（consolidation）

上面谈到了快照删除操作的数据合并可能会失败。这种失败会带来很多问题，包括不必要的磁盘空间占用，以及虚机性能下降。因此，当出现这种情况时，vCenter 会向用户提示需要做 consolidation 了。该操作会检查虚机当前所有的 vmdk 分层，将冗余的 delta 文件先合并再删除。

1.2.4 恢复到快照

恢复到快照操作也比较好理解，就是将虚机的 base vmdk 指向目标快照的 vmdk，其结果是自从目标快照创建后的一切改动都没有了。

1.3 VMware API

VMware 提供非常丰富的 API：

其中，我们可以将与与备份相关的API分为两类，一类是控制平面的API，它们主要用做管理 vSphere 虚拟化环境；另一类是数据平面API，它们用于操作虚机的虚拟磁盘。

1.3.1 VMware API 和 SDK

VMware 通过 Web Service 向客户端提供访问接口，这些接口可用于管理虚机和其他虚拟设施，包括数据中心（datacenter），数据存储（datastore）, 网络（network）等。它还提供了包括Java, .NET, Python, Perl, REST, 以及 Ruby 等几种语言在内的 SDK。对于其他语言，则需要通过 SOAP 协议访问其 web service，gSoap 是一种比较常见的用于C/C++语言编写 web service 客户端程序的套件。

详细情况请阅读 https://www.vmware.com/support/pubs/sdk_pubs.html

1.3.2 VDDK 和 VADP

VDDK 全称是 Virtual Disk Development Kit（虚拟磁盘开发包），它能帮助开发人员创建访问虚机存储的应用。VDDK 基于 Virtual disk API。

Virtual disk API，即 VixDiskLib，是一组操作 VMDK 格式的虚拟磁盘文件的函数。它的主要功能包括：

create, convert, expand, defragment, shrink, and rename 虚拟磁盘文件
创建 redo logs 和删除 vmdk 文件
访问 vmdk 文件中任意数据，以及读取元数据
连接到远端 vSphe 存储，使用高级的传输方式，包括 SAN （备份程序所在的服务器能够直接通过 FC 或者 iSCSI 和虚机磁盘所在的存储连接），hotadd （虚拟磁盘附加到备份程序所在虚机成为其一个磁盘）和 LAN （备份程序通过 LAN 访问虚拟磁盘）。

VADP 全称是 VMware Storage APIs - Data Protection（VMware 存储API-数据保护），它使用 virtual disk API 和部分 vSphre API 来创建和管理虚机的快照，支持全量和增量备份。

1.4 CBT (Changed Block Tracking 块修改跟踪)

CBT 是 VMware 在 vSphere 4.0 版本引入的为了实现增量备份的一个功能。VDAP 使用该功能，使得基于它开发的各种虚机备份应用能够做到增量备份。

相对于全量备份时将vmdk 的全部数据块都保存下来（左图），基于 CBT 的增量备份只保存自从上次备份以来的发生了变化了的数据块（右图）。ESXi 为每个开启了 CBT 的虚机的虚拟磁盘都创建了一个 ctk 文件，它用于保存变化块的元数据。该功能将会对磁盘带来一点性能损失，因为，不使用的时候，可以关闭它，但是它对备份带来的好处是显而易见的。

获取 CBT 变化块的函数的定义为：QueryChangedDiskAreas(snapshot, deviceKey, startOffSet, changeID)。其中，

snapshot 代表当前的快照，也就是“变化”时间段的后端点；
deviceKey 是目标虚拟磁盘的 device ID；
startOffSet 是开始获取变化块的offset；
changeID 是指“变化”时间段的前端点，即老的快照的 changeID。

其结果类似 “(117768192, 65536),(132120576, 65536),(145096704, 43122688),(265289728, 65536),(958398464, 65536)”，每项的格式为（offset，length），表示一个发生变化的数据块。

1.5 Quiseced Snapshot 和 VMware Tools

虚机快照按照不同的一致性可以分为三种：

崩溃一致快照（crash-consistent snapshot）：当虚机上的应用还在运行，IO 还在进行时进行快照会得到这种快照。它相当于电脑突然断电了磁盘时的状态。
文件系统一致快照（file-system-consistent snapshot）: 在做快照之前，虚机的文件系统被暂时冻结，内存中的脏数据都被刷进磁盘；在快照做完之后，文件系统被解冻。此时的快照是文件系统一致的。
应用一致性（application-consistent snapshot）：在做快照之前，应用被暂时冻结，内存中应用的所有数据都被刷到磁盘，在快照做完之后，应用被解冻。

默认的快照是第一种，要得到后两种快照，需要增加相应的步骤。其实现方式主要可以分为两种：

在较新的 Windows 客户机上，Windows 提供了 VSS（Volume Shadow Copy Service）服务，它可以通过 requester-writer 方式来实现有冻结需求的应用和文件系统在快照之前进行冻结和快照之前进行解冻。Microsoft VSS 服务能够通过协调商务应用（比如SQL Server，Exchange server 以及 Oracle 等），文件系统，备份应用，快速恢复应用，以及存储硬件等来提供一致的阴影复制（shadow copies）。
在老的 Windows， VMWare 提供了 SYNC 驱动；在 Linux 系统上，VMware 提供了 vmsync 内核模块来实现文件系统一致性快照。
在非 Windows 客户机上要实现应用一致性快照的话，需要编写具体应用对应的脚本，在调用后对应用进行冻结或者解冻。

那 VSS 服务，SYNC driver， vmsync 内核模块以及自定义脚本由谁来调用呢？VMware 提供了 VMware Tools，它是一个独立的程序，有不同的操作系统版本，它需要被安装在客户机内。以 VSS 为例，VMware tools 承担 VSS Requester 的角色，在做这种快照之前和之后，它调用 VSS 服务，VSS 服务又调用已经注册的 VSS Writer 来执行相应的操作。下图是个简单示例：

后面两种类型的快照被称为 quiseced snapshot，包括 filesytem-quiseced snapshot 和 applicaiton-quiseced snapshot。其完整的流程大概为：

1.用户发出 quiesced snapshot 创建请求给 vCenter，vCenter 给虚机所在的 ESXi 的 hostd 服务发出指令

2.ESXi 上的 Hostd 将请求传给客户机内的 VMware tools

3.VMware tools 以 VSS Requester 的身份通知 VSS，VSS 再通知已经注册的文件系统以及各应用的 VSS writer 执行各自的数据下刷和冻结操作（应用的暂时冻结不能超过60秒）

4.一旦完成，VMware tools 将就结果告诉 hostd

5.Hostd 再执行快照操作

6.操作结束，按照前面的顺序再对文件系统和应用进行解冻

再说一下 VMware tools。在 Windows 系统上，它的安装包里面包括了很多的驱动，这些驱动能增强虚机的用户体验，比如鼠标更加平滑，分辨率更高，声音效果更好等等；除了这些驱动以外，还有VSS support，它是 VMware tools 和 Windows VSS 之间交互的桥梁。要创建 quiseced snapshots，这项必须被安装。

注意安装 VMware tools 的时候，现在 VWC 里面选择 Guest->Install/Upgrade VMware Tools，然后登录虚机，找到前面步骤所挂接的磁盘，再双击安装程序开始安装过程。

在 vCenter 客户端中，用户可以选择是否创建 quiesced snapshot：

不同的情况下，有如下几种可能结果：

没选择，或者选择了但是客户机内没有安装 VMware tools：创建 crash-consistent snapshot
选择了，客户机安装了 VMware tools，有 MS VSS 但没有应用 vss writers，或者安装了 vmware vmsync driver：创建 filesystem-consistent snapshot
选择了，客户机安装了 VMware tools，有 MS VSS，也有应用 vss writers，或者编写了应用一致性操作脚本：创建 application-consistent snapshot

1.6 虚拟磁盘传输模式（Tranport modes)

这个传输模式是指虚机或者虚机快照的虚拟磁盘中的数据被传送到备份程序的传输方式。VMware 在不同的环境中支持使用不同的传输模式，好的传输模式能大大增强传输传输效率。

1.6.1 SAN 模式

这种模式要求 VMware 备份程序所在的物理服务器能够通过 FC/iSCSI/SAS SAN 网络访问到虚拟磁盘。对备份来说，这是效率最高的传输模式。这种传输模式下，VADP API 从vCenter 或者 ESXi 上获取 VMFS LUN 的信息，然后再基于这些信息从 VMDK 所在的 FC/iSCSI/SAS LUN 中直接读取数据。下图是一个示例：

要使用这种模式：

备份程序需要运行在物理服务器之内，该服务器必须能够通过SAN网络访问到VMFS LUN。
SAN 模式对备份来说是最佳选择，但是对恢复来说却不是。

1.6.2 LAN(NBD) 模式

这种模式下，ESX/ESXi 主机从其存储中读取数据，再通过 LAN 网络发到备份程序所在的主机。这种模式支持任何类型的存储。备份程序可以运行在一个虚机之内。需要的时候，可以使用 SSL 加密（NBDSSL）。

1.6.3 HotAdd 模式

当备份存储运行在虚机之内时，可以利用 ESXi 的 SCSI HotAdd 特性来将虚拟磁盘直接挂在到该虚机上成为其一个本地磁盘。这种模式只能用于 SCSI 模式的虚拟磁盘，而不适用于 IDE 类型的。

如果虚机的快照有两个虚拟磁盘，当备份程序在其所在的虚机（proxy）上使用 hotadd 模式连接到第一个磁盘后，你可以在 proxy 上看到该磁盘以及它的两个分区：

Disk /dev/sdc: 12.9 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders, total 25165824 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x836df02a

  Device Boot   Start     End   Blocks  Id System
/dev/sdc1  *    2048   206847   102400  7 HPFS/NTFS/exFAT
/dev/sdc2     206848  25163775  12478464  7 HPFS/NTFS/exFAT

然后 proxy 就可以象读取自己的磁盘一样从该磁盘读取文件了。简单来说，hotadd 和你手工把一个快照的某个vmdk 挂接到另一个运行着的虚机的原理和要求是一样的。你也可以通过手工的方式来确定hotadd是否能成功。hotadd 和 nbd(ssl)都走的是以太网，但是区别在于，nbd 走的是管理网络，而这种网络的带宽往往有限；而 hotadd 走的是数据/存储网络，而这种网络往往被单独出来，而且带宽往往比较大。

关于各种传输模式的概念，使用，要求和最佳实践等，请阅读 MVware 的相关文档。

1.6.4 传输模式的选择

备份程序都是调用 VDAP 的 Connect/ConnectEx 接口来建立和 vmdk 的连接的。如果不指定传输模式的话，在这个过程中，VADP API 会按照顺序，依次尝试 san，hotadd 和 nbd 三种模式，直到有一种成功或者全部失败。当有成功时，客户端程序可以调用 GetTransportMode() API 返回该连接所使用的传输模式。当然，客户端程序也可以指定特定的传输模式。在操作结束后，客户端程序需要调用 Disconnect API 来断开已经建立的连接。

2. 传统VMware环境的备份软件的基本架构

3. 简要 VMware 虚机镜像备份和恢复流程

3.1 备份流程

简要过程：

1.备份程序使用 vSphere API 建立和虚机的连接，并备份虚机的配置信息

2.使用 vSphere API 创建快照，往往会创建 Quiseced 类型的快照，来保证应用或者文件系统一致性

3.使用 VDDK API 建立和快照的第一个磁盘的连接，连接的传输模式将会是 san/hotadd/nbdssl/nbd 中的一种。

4. 对该磁盘，调用 QueryChangedDiskAreas 接口，获取它与上次备份时磁盘之间发生了变化的数据块列表

5.调用 VDDK API，读取发生了变化的数据块的内容并写入存储中的备份

6.依次处理其它磁盘

7.所有磁盘处理完毕后，删除快照，并断开与虚机的连接

特点：

利用快照功能，保存虚机在某个时间点上的状态和快照，很短时间之后虚机就可以照常运行。备份结束，快照会被删除，这样虚机的性能也就不受到影响了。
利用 VADP API，只读取两次备份之间磁盘上发生了变化的数据块。当然了，第一次是必须做全备份。
只将变化的数据块写入后端存储，也就是说后端存储必须负责维护第一次全备份和以后每次delta备份之间的关系。其实相当于将 VMware 的 Snapshot manger 功能挪到了备份软件的后端存储。

3.2 恢复流程

简要过程：

1.备份程序使用 vSphere API 建立和待恢复虚机的连接，并恢复虚机的配置信息

2.使用 vSphere API 创建快照，往往会创建 Quiseced 类型的快照，来保证应用或者文件系统一致性

3.使用 VDDK API 建立和快照的第一个磁盘的连接

4. 对该磁盘，调用 QueryChangedDiskAreas 接口，获取它与上次备份时磁盘之间发生了变化的数据块列表

5.调用 VDDK API，从所存备份中读取变化块的数据，再写入快照磁盘的相应位置。该磁盘的所有变化块写入完成后，关闭与磁盘的连接。

6.依次处理其它磁盘

7.将虚机revert到已恢复快照

8.删除快照，并断开与虚机的连接

特点：

在操作前，需要确保虚机处于关机状态
同样也利用快照，然后再利用 API 获取本次快照和上次备份所对应快照之间发生变化了的数据块，再使用已保存的备份中的数据将发生了变化的快照磁盘中相应的数据块覆盖掉
快照的磁盘 vmdk 文件都被恢复后，执行快照恢复
结束后，删除快照
虽然备份时上传的是 delta 数据块，但是在做恢复时，需要读取全部的数据块。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。

上一篇：OpenStack Mitaka 版本中的 domain 和 admin详解
下一篇：centos修改docker网络配置方法分享