本文共 4044 字，大约阅读时间需要 13 分钟。
quiescent=True VMware 官方建议备份应用程序选择与 vCenter 服务器建立通信，而非 ESXi 主机。最主要的原因在于 vCenter 服务器为使用 vSphere WS API 的开发者提供了目标对象定位的透明性。由 vCenter 服务器负责跟踪目标虚拟机在不同 ESXi 主机之间的迁移，并且会隐式的将 SDK 操作重定向到当前运行目标虚拟机的 ESXi 主机。
并且 VMware 官方建议开发者应该最小化连接或会话的数量，以降低 vSphere 的资源负载。对备份应用程序来说，最好只创建一个会话，并在所有需要和 vSphere 进行交互的模块中共享该会话。这就意味着如果你希望备份应用程序支持多线程，那么你应该引入访问控制块来对连接的访问进行互斥。
创建临时快照时，需要充分考虑虚拟机备份的级别，根据不同的级别来创建不同类型的临时快照。EXAMPLE：
如果是后者的话，则需要将 CreateSnapshot_Task 的「quiesce」和「memory」参数均设置为 TRUE，前置会使 FileSystem 处于静置状态，后者则允许在快照中包含开启电源状态下的虚拟机内存状态，以此获得一个「静置快照」。否则，创建出的快照会存在过渡期的系统状态，还原这种状态下的快照数据很可能会破坏业务系统的运行时状态；
NOTE：「quiesce」和「memory」标识有效的保证了备份虚拟机的文件系统一致性和应用一致性。
还有一点需要注意的是，在执行完备份之后，临时快照就无用了，切记将其删除。快照会影响到虚拟机的性能，以及占用存储空间。
CBT 是实现增量备份的底层支撑，如果你需要进行更加有利于节省存储空间增量备份的话，通常需要在第一个快照创建之前开启 CBT。但实际上 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 机制实际上反而降低了性能。如果备份应用按照下列原则进行读写操作，能够达到最佳的效率：
厚置备磁盘在 Datastore 中会直接占用其分配的所有数据空间，而精简置备磁盘只会消耗其实际使用了的数据空间，所以备份精简置备磁盘的速度会更快。
需要注意的是，厚置备磁盘又细分为「即时清零厚置备磁盘」和「延迟清零厚置备磁盘」。对于前者的全量备份而言，是否开启 CBT 的影响并不大，因为始终都会备份其所分配的容量。但对于后者的全量备份而言就有区别了，如果在全量备份一个「延迟清零厚置备磁盘」前没有开启 CBT 的话，VixDiskLib 会读取虚拟磁盘所有的扇区，并将实际没有使用到的空扇区(本来会被延迟清零的扇区)中的脏数据全部重置为 0，然后再进行备份。也就是说如果「延迟清零厚置备磁盘」在进行全量备份之前没有开启 CBT 的话，其备份数据量上是与「即时清零厚置备磁盘」一样的，而且还损耗了置零的时间，使用这样的备份数据恢复出来的虚拟磁盘类型也是「即时清零厚置备磁盘」。所以建议在对「延迟清零厚置备磁盘」进行全量备份前开启 CBT 功能，实际上如果是增量备份的场景，无论是什么类型的虚拟磁盘，都应该建议开启 CBT。
还有一点需要注意的是，精简置备虚拟磁盘的数据空间是动态的，所以其很可能不是一片连续的数据空间，其在数据存储中实际的数据空间是在第一次写入数据时才被创建的(created on first write)。所以与使用 NBD/NBDSSL/HotAdd 的厚置备磁盘相比，精简置备磁盘在首次写入时需要额外的数据块分配性能开销，不过一旦精简置备磁盘的数据空间被创建之后，其性能就与厚置备类型相差无几了。重要的是，在虚拟机对精简置备磁盘进行随机 I/O 或写操作的同时进行备份的话，即便开启的 CBT，所备份出来的数据量也很可能会大于预期的数据量。对于这种情况，进行虚拟磁盘碎片整理可能会有助于减小备份的数据量。
在保护之前不存在 Snapshot (changeId == '*')，开启 CBT 并执行增量保护所保护的数据量是「实际已使用」的数据空间。
changeId != '*')，开启 CBT 并执行全量保护所保护的数据量是「已分配」的数据空间。 在保护之前不存在 Snapshot (changeId == '*')，开启 CBT 并执行增量保护所保护的数据量是「实际已使用」的数据空间。
changeId != '*')，开启 CBT 并执行全量保护所保护的数据量是「已分配」的数据空间。 在保护之前不存在 Snapshot (changeId == '*')，开启 CBT 并执行增量保护所保护的数据量是「已分配」的数据空间。
changeId != '*')，开启 CBT 并执行全量保护所保护的数据量是「已分配」的数据空间。 一般来说，RDM 类型的虚拟磁盘是无法进行备份的，因为物理兼容的 RDM 磁盘设备无法进行快照。备份应用应该忽略这些无法进行快照的独立磁盘，如果创建快照，就会抛出错误。
转载地址：http://kccja.baihongyu.com/