joexk

VMware虚拟机备份和恢复

VMware 虚机备份和恢复

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

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

虚拟机的虚拟磁盘由ESXi宿主机上的三个文件组成,下面是虚拟机centos(虚拟机名称)第一个磁盘对应的三个文件：

centos.vmdk （配置文件，大小 633 字节）
该文件保存的是磁盘的元数据，包括下面两个文件的信息
centos-flat.vmdk （二进制文件，大小 12884901888 字节）
该文件是 Extent description 文件，二进制数据保存在这个文件中。下面会介绍使用API获取该文件中数据的方法。
centos-ctk.vmdk （二进制文件，大小 78694 字节）
该文件是 CTK 文件，CBT（数据块修改跟踪）启动时自动生成该文件。

1.2 快照（Snapshot）

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

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

1.2.1 创建快照

在虚拟机上创建一个快照，除了快照定义文件以外，磁盘中新增了三个文件：

centos-000001-ctk.vmdk –> ctk 文件
centos-000001-delta.vmdk –> delta 文件
centos-000001.vmdk –> 非二进制文件

如果再创建第二个快照，文件变化如下：

注：RW = 读写 RO = 只读

从数据的角度看：

图中绿色部分是从虚拟机角度看数据；中间的红框是delta vmdk中的数据；最下面的红框是base 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 vmdk 文件被保留下来，这是就需要下面将介绍的手工合并操作。
删除快照可能会带来大量的数据写操作，这期间，虚机的性能会受到影响。
删除快照有时候要花费很长的时间，特别是对于长时间存在的大容量磁盘的快照。 VMware 专门出了一个接口来让用户估计所需要的时间：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）

上面谈到了快照删除后 vmdk 数据合并可能会失败。这种失败会带来很多问题，包括不必要的磁盘空间占用，以及虚机性能下降。

因此，当出现这种情况时，vCenter 会向用户提示需要做合并了。该操作会检查虚机当前所有的 vmdk 分层，将冗余的 delta 文件先合并再删除。

1.2.4 恢复到快照（restore）

恢复到快照就是将虚拟机的base vmdk指向目标快照的vmdk，其结果是自目标快照创建后的一切改动都没有了。

1.3 VMware API

VMware 提供非常丰富的API，如下图所示：

其中，我们可以将与备份相关的API分为两类：

一类是控制平面的API，它们主要用做管理 vSphere 虚拟化环境；

另一类是数据平面API，它们用于操作虚机的虚拟磁盘。

1.3.1 VMware API 和 SDK

VMware 通过 Web Service 向客户端提供访问接口，这些接口可用于管理虚拟机和其他虚拟设备，
包括数据存储（datastore）、网络（network）等设备；
它还提供了包括Java、.NET、Python、Perl、REST以及Ruby等几种语言。

对于其他语言，则需要通过 SOAP 协议访问其 web service，
gSoap 是一种比较常见的用于C/C++语言编写 web service 客户端程序的套件。
详细情况请阅读 [https://www.vmware.com/support/pubs/sdk_pubs.html]

1.3.1 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 文件中任意数据，以及读取元数据
连接到远端 vSphere 存储，使用高级传输方式，包括 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 版本引入的为了实现增量备份的一个功能。

相对于全量备份时将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)”，
每项的格式为（offset，length），表示一个发生变化的数据块。

1.5 Quiseced Snapshot 和 VMware Tools

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

1、崩溃一致性快照（crash-consistent snapshot）

当虚拟机上的应用还在运行，IO 还在进行时，此时进行快照会得到这种快照。
它相当于电脑突然断电了磁盘时的状态。

2、文件系统一致性快照（file-system-consistent snapshot）

在做快照之前，虚拟机的文件系统被暂时冻结，内存中的脏数据都被刷到磁盘；
在做快照之后，文件系统被解除冻结。此时的快照是文件系统一致的。

3、应用一致性快照（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。

其完整的流程大概为：

用户发出 quiesced snapshot 创建请求给 vCenter，vCenter 给虚机所在的 ESXi 的 hostd 服务发出指令；
ESXi 上的 Hostd 将请求传给客户机内的 VMware tools；
VMware tools 以 VSS Requester 的身份通知 VSS，VSS 再通知已经注册的文件系统以及各应用的 VSS writer 执行各自的数据下刷和冻结操作（应用的暂时冻结不能超过60秒）；
一旦完成，VMware tools 将就结果告诉 hostd；
Hostd 再执行快照操作；
操作结束，按照前面的顺序再对文件系统和应用进行解冻。

对于 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
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 走的是数据/存储网络，而这种网络往往被单独出来，而且带宽往往比较大。

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

1.6.4 传输模式的选择

备份程序都是调用 VDAP 的 Connect/ConnectEx 接口来和 vmdk 建立连接的。

如果不指定传输模式的话，VADP API 会按照顺序，依次尝试 san，hotadd 和 nbd 三种模式，直到有一种成功或者全部失败。

当有成功时，客户端程序可以调用 GetTransportMode() API 返回该连接所使用的传输模式。

当然，客户端程序也可以指定特定的传输模式。在操作结束后，客户端程序需要调用 Disconnect API 来断开已经建立的连接。

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

3. VMware 虚拟机备份恢复流程

3.1 备份流程

简要过程：

备份程序使用vSphere API 建立和虚拟机的连接，并备份虚机的配置信息；
使用 vSphere API 创建快照，一般会创建 Quiseced 类型的快照，来保证应用或者文件系统一致性；
使用 VDDK API 建立和快照的第一个磁盘的连接，连接的传输模式是 SAN/HotAdd/NBDSSL/NBD 中的一种；
对该磁盘调用 QueryChangedDiskAreas 接口，获取它与上次备份时磁盘之间发生了变化的数据块列表；
调用 VDDK API ，读取发生了变化的数据块的内容并写入存储中进行备份；
依次处理其它磁盘；
所有磁盘处理完毕后，删除快照，并断开与虚拟机的连接。

特点：

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

3.2 恢复流程