前文列表

备份思路

在目标虚拟机上创建临时快照
从目标虚拟机上获取备份数据，并保存备份数据
删除临时快照

备份算法

连接到备份目标虚拟机所在的 VC/ESXi
使用 vSphere WS API 开启备份目标虚拟机的 CBT (视情况而定)
使用 vSphere WS API 的 CreateSnapshot_Task 创建备份目标虚拟机的临时快照，如果备份要求「应用一致性」那么需要设置参数 quiescent=True
获取备份目标虚拟机的虚拟磁盘数据以及虚拟机配置信息
使用 VDDK 打开并读取备份目标虚拟机的虚拟磁盘和快照文件数据
将虚拟磁盘、快照文件、配置信息等数据一起复制到备份存储
使用 vSphere WS API 删除临时快照

备份细节

连接到 vCenter 还是 ESXi？

VMware 官方建议备份应用程序选择与 vCenter 服务器建立通信，而非 ESXi 主机。最主要的原因在于 vCenter 服务器为使用 vSphere WS API 的开发者提供了目标对象定位的透明性。由 vCenter 服务器负责跟踪目标虚拟机在不同 ESXi 主机之间的迁移，并且会隐式的将 SDK 操作重定向到当前运行目标虚拟机的 ESXi 主机。

并且 VMware 官方建议开发者应该最小化连接或会话的数量，以降低 vSphere 的资源负载。对备份应用程序来说，最好只创建一个会话，并在所有需要和 vSphere 进行交互的模块中共享该会话。这就意味着如果你希望备份应用程序支持多线程，那么你应该引入访问控制块来对连接的访问进行互斥。

如何选择快照类型？

创建临时快照时，需要充分考虑虚拟机备份的级别，根据不同的级别来创建不同类型的临时快照。EXAMPLE：

只关注磁盘数据完整性的备份级别 ==> 创建崩溃一致性快照
需要关注业务系统一致性的备份级别 ==> 创建 Quiseced 快照

如果是后者的话，则需要将 CreateSnapshot_Task 的「quiesce」和「memory」参数均设置为 TRUE，前置会使 FileSystem 处于静置状态，后者则允许在快照中包含开启电源状态下的虚拟机内存状态，以此获得一个「静置快照」。否则，创建出的快照会存在过渡期的系统状态，还原这种状态下的快照数据很可能会破坏业务系统的运行时状态；

NOTE：「quiesce」和「memory」标识有效的保证了备份虚拟机的文件系统一致性和应用一致性。

还有一点需要注意的是，在执行完备份之后，临时快照就无用了，切记将其删除。快照会影响到虚拟机的性能，以及占用存储空间。

是否开启 CBT？

CBT 是实现增量备份的底层支撑，如果你需要进行更加有利于节省存储空间增量备份的话，通常需要在第一个快照创建之前开启 CBT。但实际上 CBT 也存在着一些使用的限制，具体请浏览《VMware 虚拟化编程(10) — VMware 数据块修改跟踪技术 CBT》。

是否开启 CBT 的关键除了其自身使用上的限制之外，还要考虑备份目标虚拟机的重要性。如果备份目标虚拟机内运行的是核心业务系统，而且存储资源又比较充裕，那么我会建议关闭 CBT，选择使用完全备份。
1. CBT 会占用可测量的性能资源；
2. CBT 的稳定性存在着隐患；

如何获取备份数据？

获取虚拟机的备份数据需要集齐以下关键要素：

Snapshot MoRef：快照实际上就是虚拟磁盘的备份版本，通过 Snapshot MoRef 我们可以获取虚拟磁盘的名称和路径等信息。例如：从 Snapshot Managed Object 的 ConfigInfo 开始，能够查找到快照中所有虚拟磁盘的 BackingInfo，我们能够从这些 BackingInfo 中找到虚拟机所有虚拟磁盘相应的 changeId。所以尤其在多虚拟磁盘的场景中，如何有效的对不同的虚拟磁盘进行标识，是一个非常重要的前提条件。
VixDiskLib 库函数：在对虚拟磁盘进行了有效的标识之后，我们需要使用 VixDiskLib 所提供的「接口函数集」来获取实际的虚拟磁盘数据。之所以将其称之为「接口函数」，是因为 VixDiskLib 向开发者透明了虚拟磁盘操作的细节。例如，调用 VixDiskLib_Open 和 VixDiskLib_Read 函数时，VixDiskLib 允许以扇区为单位(in Sector)来访问虚拟磁盘数据，所以传输的数据总量是扇区大小的整数倍。可以看出，VixDiskLib 库函数的调用就犹如接口函数调用一般的简单直接。
Metadata：虚拟磁盘的元数据，是描述了虚拟磁盘配置信息的一系列键值对，包含了磁盘卷标、LUN、分区布局、链接个数、文件属性、RDM、锁等关键信息，在还原一个虚拟磁盘的时候起到了至关重要的作用。元数据信息可以通过 VixDiskLib_ReadMetadataKeys 和 VixDiskLib_ReadMetadata 来获得。
VixMntapi：VixMntapi 库可以获取虚拟磁盘中的 GuestOS 相关信息(如：操作系统类型等)。更重要的是 VixMntapi 支持将卷直接挂载到设备节点上，这样就能够执行面向文件的备份与还原了。

如何提高备份数据的传输率？

掌握以下使用要点，就能够有效的提高备份数据的传输率：

在备份应用程序中选择使用增强型连接函数 VixDiskLib_InitEx 和 VixDiskLib_ConnectEx，增量型连接函数支持使用高级数据传输模式 SAN 和 SCSI HotAdd
如果备份场景主需要读取虚拟磁盘数据，而无需修改磁盘数据的话。调用 VixDiskLib_ConnectEx 时候可以通过传入 readOnly=TRUE 来启用高性能只读访问。
如果在 Linux 上使用 SAN 存储的场景中，可以选择「direct」直接读写模式 O_DIRECT，「direct」模式会阻止其他进程访问最新的虚拟磁盘数据，这意味着磁盘数据的读写都不会存在任何的缓存，这样能够避免提交写缓存前由于进程终止所造成的信息丢失。而且备份一个虚拟磁盘通常都是连续的读取不同扇区中的数据，开启 Cache 机制实际上反而降低了性能。如果备份应用按照下列原则进行读写操作，能够达到最佳的效率：
- 在 SAN 中执行读写操作的数据偏移都应该是 Page Size 的整数倍。
- 传输的长度应该是 Page Size 的整数倍。
- 数据传输的缓冲区应该是页边界对齐的。

备份厚置备磁盘和精简置备磁盘有什么区别？

厚置备磁盘在 Datastore 中会直接占用其分配的所有数据空间，而精简置备磁盘只会消耗其实际使用了的数据空间，所以备份精简置备磁盘的速度会更快。

需要注意的是，厚置备磁盘又细分为「即时清零厚置备磁盘」和「延迟清零厚置备磁盘」。对于前者的全量备份而言，是否开启 CBT 的影响并不大，因为始终都会备份其所分配的容量。但对于后者的全量备份而言就有区别了，如果在全量备份一个「延迟清零厚置备磁盘」前没有开启 CBT 的话，VixDiskLib 会读取虚拟磁盘所有的扇区，并将实际没有使用到的空扇区(本来会被延迟清零的扇区)中的脏数据全部重置为 0，然后再进行备份。也就是说如果「延迟清零厚置备磁盘」在进行全量备份之前没有开启 CBT 的话，其备份数据量上是与「即时清零厚置备磁盘」一样的，而且还损耗了置零的时间，使用这样的备份数据恢复出来的虚拟磁盘类型也是「即时清零厚置备磁盘」。所以建议在对「延迟清零厚置备磁盘」进行全量备份前开启 CBT 功能，实际上如果是增量备份的场景，无论是什么类型的虚拟磁盘，都应该建议开启 CBT。

还有一点需要注意的是，精简置备虚拟磁盘的数据空间是动态的，所以其很可能不是一片连续的数据空间，其在数据存储中实际的数据空间是在第一次写入数据时才被创建的(created on first write)。所以与使用 NBD/NBDSSL/HotAdd 的厚置备磁盘相比，精简置备磁盘在首次写入时需要额外的数据块分配性能开销，不过一旦精简置备磁盘的数据空间被创建之后，其性能就与厚置备类型相差无几了。重要的是，在虚拟机对精简置备磁盘进行随机 I/O 或写操作的同时进行备份的话，即便开启的 CBT，所备份出来的数据量也很可能会大于预期的数据量。对于这种情况，进行虚拟磁盘碎片整理可能会有助于减小备份的数据量。

Thin 精简置备虚拟磁盘

在保护之前不存在 Snapshot (changeId == '*')，开启 CBT 并执行增量保护所保护的数据量是「实际已使用」的数据空间。
在保护之前已经存在 Snapshot (changeId != '*')，开启 CBT 并执行全量保护所保护的数据量是「已分配」的数据空间。

Thick-Lazy 延迟置零的厚置备虚拟磁盘

Thick-Eager 立即置零的厚置备虚拟磁盘

在保护之前不存在 Snapshot (changeId == '*')，开启 CBT 并执行增量保护所保护的数据量是「已分配」的数据空间。
在保护之前已经存在 Snapshot (changeId != '*')，开启 CBT 并执行全量保护所保护的数据量是「已分配」的数据空间。

有什么磁盘类型是无法进行备份的？

一般来说，RDM 类型的虚拟磁盘是无法进行备份的，因为物理兼容的 RDM 磁盘设备无法进行快照。备份应用应该忽略这些无法进行快照的独立磁盘，如果创建快照，就会抛出错误。

VMware 虚拟化编程(13) — VMware 虚拟机的备份方案设计

目录