前文列表

VMware 虚拟机的快照

在备份和恢复应用程序中，不管是全量备份，还是增量备份，都依赖于 vSphere 中的快照。要备份虚拟机，首先需要创建一个虚拟机的快照。快照创建成功之后，就需要找到与快照相关的虚拟磁盘。虚拟磁盘的快照文件以虚拟磁盘的基本名称命名，并且在名称后面追加了唯一的序列字符串，以保证 VMDK 文件的唯一性。如：vdisk-000032.vmdk，其中 vdisk 是虚拟磁盘的基本名称。在物理文件系统的快照磁盘文件类型如下：

vm_name-000001.vmdk (配置文件)：虚拟机快照的元数据文件，记录了该次快照相关文件的信息，其中 000001 表示第一次快照。

vm_name-000001-delta.vmdk (二进制文件)：称为快照数据文件或者重做日志文件(redo-log)也被称为子磁盘文件，该文件用于保存快照时间点后虚拟机所产生的更改数据(即快照数据)。应用了 in-file delta technology 技术，初始大小为 16MB，会随着虚拟机数据落盘操作的增多，而按照 16MB 的大小进行增长(降低 SCSI reservation 冲突)，并且该文件的大小永远不会超过 Base Disk File 的大小。

vm_name-000001-ctk.vmdk (二进制文件)：改变追踪文件，保存了自从上次快照以来的虚拟磁盘文件所发生变化的数据块偏移量信息。需要开启 CBT 功能才会生成该文件。

NOTE：在 vSphere API 的定义中，使用 Datastore 唯一标识作为前缀，结合虚拟磁盘相对于 Datastore 根目录的路径，以此来标识一块虚拟磁盘，如：[storageN] VmName/vdisk-NNNNNN.vmdk

要取得虚拟磁盘机器快照的名称和相关配置信息(capacityInKB、changeID 等)，可以使用 PropertyCollector 来获取 VirtualMachine Managed Object 的 config.hardware.device 属性。在其中找到 VirtualDisk 项的 BackingInfo 属性，那就是虚拟磁盘的配置信息，有以下类型：

VirtualDiskFlatVer1BackingInfo

VirutalDiskFlagVer2BackingInfo

VirtualDiskRawDiskMappingVer1BackingInfo

VirtualDiskSparseVer1BackingInfo

VirtualDiskSparseVer2BackingInfo

NOTE：VirtualDiskRawDiskMappingVer1BackingInfo 类型的虚拟磁盘是无法创建快照的，所以也无法备份这一类型的虚拟磁盘。

快照的执行过程

STEP 1：

STEP 2：

STEP 3：

可以看出 VMware 虚拟机快照的特性有：

VMware 虚拟机使用的是链式快照。

VMware 虚拟机快照的 Parent VMDK File 的访问权限为 OR 只读。

快照时间点之后新落盘的数据只会被写入到 Child VMDK File 快照数据文件中。

快照链上的任意快照文件的损坏都会导致虚拟机无法正常运行。

删除快照

从创建快照的特性中可以理解，如果希望在删除一个快照的同时保证虚拟机能够正常运行的话，那么就需要将该快照数据文件中的数据合并到 Parent VMDK File 中，以此来保证虚拟机磁盘数据的完整性。

删除虚拟机快照一般会是以下两种情况：

待删除的虚拟机快照在快照链中：delta vmdk 中的数据会向父快照的 delta vmdk 或基础虚拟磁盘文件 base vmdk 合并，然后 delta vmdk 被删除。

待删除的虚拟机快照不在快照链中(VMware 支持独立快照)：不需要合并，直接删除快照数据文件。

删除 VMware 虚拟机快照的特点：

删除快照过程包括两个异步的操作：1. 从 Snapshot Manager 中将快照删除；2. vmdk 数据合并。如果 1 成功而 2 失败，就会残留 delta vmdk 文件，这样的话就需要手动进行快照文件的合并。

删除快照可能会带来大量的数据写操作，有时候可能需要删除很长的时间，并且期间虚拟机的性能会受到负面影响。

自从 vSphere 4 Update 2 开始，优化了选择删除所有虚拟机快照的过程，不再是顺序向下一层层的合并，而是各层分别直接合并到 Base vmdk 中。

快照类型

崩溃一致快照 (Crash-Consistent Snapshot)：是 VMware 虚拟机的默认快照类型，相当于电脑突然断电时磁盘的状态，闪存中的数据会丢失掉。

文件系统一致快照 (File-System-Consistent Snapshot)：快照时间点之前，虚拟机的文件系统会被冻结，内存中的脏数据刷盘，快照完成之后，文件系统再解冻。这样的快照能够保证文件系统的一致性，即内存中的数据不会丢失。

应用一致性 (Application-Consistent Snapshot)：快照时间点前，虚拟机上运行的应用程序被冻结，内存中应用程序相关的所有脏数据刷盘，快照完成之后，应用程序再被解冻，这样的快照能够保证指定应用程序的数据是完整的，但不会保证文件系统也是完全一致的。

其中文件系统一致快照和应用一致性也统称为 Quiseced Snapshot。

Quiseced Snapshot

使用 Quiseced Snapshot 需要特殊的环境配置，主要的实现方式有两种：

使用 GuestOS 内置的应用服务或 VMware 提供的一致性驱动：
- 版本较新的 Windows GuestOS 提供了 VSS(Volume Shadow Copy Service) 服务，VSS 的 Requester-Writer 能够对应用程序和文件系统进行冻结和解冻操作。
- 对于版本较老的 Windows GuestOS，VMware 也提供了 SYNC driver 数据一致性驱动来支持应用程序和文件系统一致性快照；
- 而 Linux Guest，VMware 提供了仅支持持文件系统一致性的 vmsync kernel module。

使用脚本程序：如果是非 Windows GuestOS，那么就需要编写针对指定应用程序的脚本来对其进行冻结和解冻的操作。

NOTE：上述列举的 VSS、SYNC driver、vmsync kernel module 和脚本，均要依赖 VMware Tools 来调用，所以即便客户机操作系统支持上述功能，仍需安装 VMware Tools 才能完美支持 Quiseced Snapshot。例如针对 VSS，VMware tools 就提供了 VSS support 功能，它是 VMware tools 和 Windows VSS 之间交互的桥梁。

Quiseced Snapshot 的创建过程：

1. 用户发出 Quiesced Snapshot 创建请求给 vCenter，vCenter 再给虚拟机所在的 ESXi 的 Hostd Service 发出快照创建请求。

2. ESXi 上的 Hostd Service 将快照创建请求传递给虚拟机 GuestOS 内的 VMware tools。

3. VMware tools 以 VSS Requester 的身份通知 VSS，VSS 再通知已经被注册的文件系统和各应用的 VSS writer 执行冻结操作。

4. 一旦完成冻结和内存数据落盘，VMware tools 就将完成结果通知 Hostd Service。

5. Hostd Service 执行快照操作。

6. 快照完成后，按照前面的顺序再对文件系统和各应用进行解冻。