2.1　系统镜像级数据备份

对于运行于公有云、虚拟化或者物理机平台上的操作系统，根据它们的运行形态和特性，镜像级数据保护方法也会略有不同，这些平台主要有VMware vSphere、Microsoft Hyper-V、Nutanix AHV、AWS EC2、Azure VM、KVM和物理服务器。

以Veeam的VBR为代表的新一代云数据保护软件能够为这些平台创建备份副本，将数据从生产系统中提取出来，存放在其所管理的备份存储库中或者异地灾备平台上。这些提取出来的数据虽然以压缩、重删及加密的形式存放在备份存储库中，但是借助VBR软件却能以原生的形式提供给用户使用。在详细说明VBR针对各个平台的数据提取和备份机制之前，我们先来看看它的组成。

VBR由以下三个主要角色组成。

1）备份服务器—整个备份系统的大脑，它是整个系统的配置和操作控制中心，负责调度任务和分配资源，设置和管理备份基础架构的各个组件。

2）备份代理（Backup Proxy）—负责处理原始数据，它根据VBR备份服务器的指令处理任务，传输备份数据。所执行的任务包括从生产系统获取数据、重删和压缩数据，以使备份基础架构能够更好地扩展。

3）备份存储库（Backup Repository）—保存数据的仓库，它用来存储备份，可以是各种存储设备，例如本地磁盘、文件共享、重删设备、云存储等。

在VBR的工作过程中，会涉及大量的数据传输，其依赖于Veeam数据搬运工（Data Mover）服务来实现，本章中将会频繁出现这一服务，关于这一服务的详细工作原理，将会在4.2.1节中详述。

接下来将针对业界主流的虚拟化和云平台，如VMware vSphere、Microsoft Hyper-V、Nutanix AHV、AWS EC2、Azure VM等，来展开说明VBR的数据提取和备份机制。

2.1.1　VMware vSphere

VBR在处理VMware vSphere的虚拟机时，采用无代理的镜像级方法备份数据，这个方法在虚拟化系统管理程序层面处理数据，因此不需要在每一个虚拟机的操作系统内安装任何用于数据提取的代理程序。VBR在备份过程中会利用vSphere快照完成备份，在备份开始前，VBR会向vSphere请求一个虚拟机快照，这个vSphere快照包含了这台虚拟机的配置信息、操作系统、应用程序、用户数据以及系统的状态。VBR在备份时，会将这个快照作为数据源来抽取数据。

VMware vSphere虚拟机的备份过程如下：

1）备份作业启动后，VBR会查询数据库中作业的配置信息，读取所有需要备份的虚拟机以及与它们相关的虚拟磁盘的列表，见图2-1中的步骤①。

2）VBR会为后续的备份过程准备一系列资源，如合适的备份代理和备份存储库，并为它们建立Veeam数据搬运工的数据传输连接，见图2-1中的步骤②。

3）接下来，VBR会向vCenter或者ESXi请求虚拟机快照，在执行快照前，如果需要对应用程序进行一致性处理，VBR还会和客户机操作系统通信来处理应用程序，见图2-1中的步骤③。

4）备份代理上的数据搬运工从虚拟机快照中读取数据，如果是增量备份，则还会使用CBT（Change Block Tracking）技术获取增量的数据块。VBR在备份代理上对读取到的数据进行一系列处理，这些数据包括填零的数据块、交换文件、被排除的数据文件等，处理完成后，根据重删和压缩条件的设定，对数据完成重删和压缩，并把数据传递到备份存储库中，见图2-1中的步骤④。

5）数据传输完成后，VBR向vCenter或者ESXi发起快照合并请求，vSphere上的快照被删除，备份作业完成，见图2-1中的步骤⑤。

图　2-1

1. 备份代理

在VMware vSphere备份中，备份代理用于从vSphere中提取、压缩、重删、加密并发送数据至备份存储库。对于数据的传输，VBR支持以下三种模式：

·Direct Storage Access

·Virtual Appliance

·Network

这三种数据传输模式各有优劣势，在实际中，通常会选择一种最适合基础架构的模式来使用，如表2-1所示。

表2-1　VBR支持的三种传输模式

在VBR中，任意一台受管理的Windows或者Linux服务器都可以配置为备份代理角色，但是根据数据实际传输路径和架构的不同，数据传输模式可能不同。

2. Direct Storage Access模式

这种传输模式下，VBR会直接通过存储网络从存储卷中提取数据，也就是通常所说的LAN-Free备份。由于VMware vSphere存储有两种使用方式—VMFS和NFS，因此对应的直接存储访问也有两种方式—Direct SAN Access和Direct NFS Access。这两种方式本身对于代理部署并没有太多要求，然而在存储网络中，光纤存储和FCoE等设备无法通过虚拟化的硬件直接被虚拟机访问（硬件直通（Passthrough）在备份场景中受限制）。这时候，为了能够从这些存储网络中提取数据，备份代理必须配置为物理服务器，并且配置合适的硬件，比如HBA卡，能够访问的存储网络才能够使用这种方式。

对于iSCSI和NFS来说，完全依赖于标准以太网环境即可让备份代理访问到相关存储，因此通常情况下物理机和虚拟机皆可使用。

配置Direct SAN Access时，需要为代理配置存储必要的读写权限，这一般会通过光纤网络的ZONE划分或者配置iSCSI来完成。在配置完成后，会在备份代理的Windows磁盘管理器中看到一组状态为健康、分区格式未知的离线磁盘卷。

配置Direct NFS Access时，需要在NFS存储上为代理配置合适的白名单，允许备份代理直接访问这些存储的NFS路径。

Direct Storage Access模式不仅对于备份有效，而且对于数据恢复来说，如果配置了写入权限，VBR可以通过Direct Storage Access来完成数据的恢复，但是这个数据恢复仅限于VMDK格式为厚置备的磁盘。

3. Virtual Appliance模式

这是一种纯虚拟化的部署模式，备份代理必须配置为虚拟机才能使用这种模式。对于纯虚拟化环境来说，这是一种非常受欢迎的模式，并且由于VBR的特殊优化，这种模式的数据提取效率完全不输于Direct Storage Access模式的。这种模式会采用VMware HotAdd技术，在线将源虚拟机的虚拟磁盘挂载到代理虚拟机上，通过虚拟磁盘控制器，从vSphere虚拟磁盘堆栈中提取数据，在备份完成后，VBR会通知vSphere将源虚拟机的VMDK磁盘从代理上卸载。

这种模式下，通常对于每一块VMDK磁盘来说都会额外增加1～2分钟的磁盘附加和卸载时间。那么，如果一个备份作业包含100个以上的需要通过这种模式来操作的VMDK，将会额外需要2～3小时的时间，因此并行处理和多个备份代理分担VMDK挂盘操作对于Virtual Appliance模式来说非常重要。实际使用中需要合理配置足够多的虚拟机来承担代理任务，同时预留足够的备份窗口。

Virtual Appliance模式对于无法使用Direct Storage Access模式的本地数据存储、VVOL（Virtual Volumes）和vSAN来说是一种非常合适的数据传输模式，不仅性能优异而且配置简单，通常来说是这些存储配置的首选模式。

对于NFS数据存储来说，由于NFS本身的限制，在跨主机HotAdd卸载磁盘时，会产生不必要的虚拟机停滞，一般来说，在这种情况下，不推荐使用Virtual Appliance模式来提取和恢复数据。

4. Network模式

Network模式通常又被称为NBD模式，它是一种万金油式的数据提取方式，配置最简单，只要网络能够通信，VBR就能使用这种模式从vSphere中把数据提取出来，完全不需要额外的配置，唯一的条件是：备份服务器和代理能访问ESXi主机的443和902 TCP端口。但是，这种模式会消耗虚拟化平台管理网络的带宽资源，虚拟机的所有数据会通过VMware vSphere的管理网络传输到备份代理上进行处理。

为了避免影响日常的vCenter管理，通过DNS解析的切换，NBD模式下，VBR能够利用独立的管理网络进行数据提取。在每台ESXi主机上设置独立的、10Gbps以上的备份专用物理网卡，再为独立的网卡配置独立的vSphere管理网络，这些网络和正常的vCenter管理ESXi主机时所使用的网络完全分离，这样的配置类似于vSphere中独立的vMotion网络或者独立的存储访问网络。

将ESXi主机通过DNS域名的方式添加至vCenter中，VMware API在NBD模式下将主机对象返还给备份代理时会以域名的方式呈现，这时候只需让备份代理的Hosts文件指定独立的备份管理网络即可实现备份数据网络和日常管理网络的分离。

172.0.4.10    vcenter    vcenter.example.com
# 172.0.4.21    esx1    esx1.example.com # 屏蔽常规管理接口地址
# 172.0.4.22    esx2    esx2.example.com # 屏蔽常规管理接口地址
10.10.1.21    esx1    esx1.example.com   # 10Gbps专用的备份网络管理地址
10.10.1.22    esx2    esx2.example.com   # 10Gbps专用的备份网络管理地址

NBD模式在10Gbps以上管理网络中的表现非常突出。在使用NBD进行备份作业时，可以完全避免Direct Storage Access模式的复杂配置和Virtual Appliance模式的额外备份窗口开销，而且在NBD模式下工作比在以上两种模式下工作更加稳定和可靠。因此，为了确保备份作业顺利进行，VBR采用了多种数据提取方式混合使用并智能切换的方式。VBR会自动地智能感知当前的环境配置，根据当前的配置优先选择最优的数据传输方式。NBD模式通常作为Direct Storage Access和Virtual Appliance数据传输模式的备选方案，当这两种数据传输模式失败时，VBR会在备份作业进行中自动切换成备选的NBD模式，以确保在无人干预的情况下完成备份和恢复作业。

5. 数据传输配置建议

（1）微型环境

通常来说，具有3台以内物理服务器的环境被定义为微型环境。这样的环境架构很简单，群集数量有限，通常可能只有1个群集，在这样的环境中使用Virtual Appliance模式是最理想的，NBD可以作为备选。

（2）中小型环境

网络和存储架构不复杂，但是ESXi主机和群集数量相比微型环境略多的情况被定义为中小型环境。这种环境下，Direct Storage Access作为性能极为突出的备份数据传输模式，可以提供非常好的备份性能。在恢复时，如果虚拟化环境配置了精简置备模式，那么可以配置若干个备用的Virtual Appliance作为辅助，以提升恢复的灵活性。

在vSAN环境中，推荐HotAdd模式作为首选的数据传输方式。

NBD模式可以保留在这样的环境中，并且只需要对NBD模式做一些监控，确保不要有会影响日常管理的大量备份吞吐量即可。

（3）大型环境

在这种环境中配置Direct Storage Access和Virtual Appliance模式往往都不容易，因此相对容易配置成功的是NBD模式。统一配置独立备份网络，通过高速的10Gbps以上的以太网进行数据传输，可以简化很多架构上的设计。

当然，如果条件允许，也完全可以配置Direct Storage Access和Virtual Appliance模式。

（4）超大型环境

可以参考上面的大型环境，但是需要平衡各方面的负载，这时候在备份网络上传输的吞吐量负载会变得非常重，因此合理地配置各个角色服务器的数量变得非常关键。在这里，可以采用多个VBR服务器的分布式部署模式，同时可以利用企业管理器（Enterprise Manager）的统一管理能力。一般来说，将5000台左右的虚拟机作为一个备份域进行管理是比较合适的，而进行多站点管理时，每200个分支站点也需要一个备份服务器来支撑。

2.1.2　Microsoft Hyper-V

VBR在处理Microsoft Hyper-V虚拟机的时候，采用无代理的镜像级方法备份数据，这种方法在虚拟化系统管理程序层面处理数据，因此不需要在每一个虚拟机的操作系统内安装任何用于提取数据的代理程序。VBR在备份过程中会利用Hyper-V快照完成备份，在备份开始前，VBR会向Hyper-V请求一个卷快照，这个Hyper-V快照包含了相关虚拟机的配置信息、操作系统、应用程序、用户数据和系统的状态。VBR在备份时，会将这个快照作为数据源来抽取数据。

Hyper-V虚拟机的备份过程如图2-2所示。

1）备份作业启动后，VBR会查询数据库中作业的配置信息，读取所有需要备份的虚拟机以及与它们相关的虚拟磁盘的列表，见图2-2中的步骤①。

2）VBR会为后续的备份过程准备一系列资源，如相关的备份代理以及备份存储库，并为它们建立Veeam数据搬运工的数据传输连接，见图2-2中的步骤②。

3）接下来，VBR会向Hyper-V请求卷快照，在执行快照前，如果需要对应用程序进行一致性处理，VBR还会和客户机操作系统通信来处理应用程序，见图2-2中的步骤③。

4）备份代理上的数据搬运工从卷快照中读取数据，如果是增量备份，则还会使用RCT技术获取增量的数据块。VBR在备份代理上对读取到的数据进行一系列处理，这些数据包括填零的数据块、交换文件、被排除的数据文件等，处理完成后，根据重删和压缩条件的设定，对数据完成重删和压缩，并把数据传递到备份存储库中，见图2-2中的步骤④。

5）数据传输完成后，VBR向Hyper-V发起快照合并请求，Hyper-V上的卷快照被删除，备份作业完成，见图2-2中的步骤⑤。

图　2-2

在Microsoft Hyper-V环境中，虚拟机会在本地存储或者CSV（Cluster Shared Volume）上运行，备份这些虚拟机的时候，VBR会借助VSS（Volume Shadow copy Service）框架和Microsoft Hyper-V的专有组件来提取数据，VBR在这里充当VSS请求者的角色。在与VSS框架交互中，VBR先获得有关基础架构的信息，识别虚拟机文件所在的卷，然后触发VSS协调器以创建卷快照。

在备份过程中，在对卷创建快照时，需要确保该卷上的虚拟机处于静默状态，这时候可以保证数据库的一致性，文件系统中的文件都已经处于关闭状态。VBR会通过以下3种方式来处理这样的备份准备过程。

（1）在线备份

Microsoft Hyper-V提供的创建应用一致性备份的方式，完全无任何停机时间。

（2）离线备份

另外一种备选的一致性备份方式，这时候Hyper-V会通过使操作系统休眠的方式冻结虚拟机的I/O，这种方式会有短暂的停机时间。

（3）崩溃一致性备份

Veeam专有的创建崩溃一致性备份的方式，这种方式不产生停机时间，不用冻结I/O。

对于以上三种方式，VBR会优先选择在线备份以尝试使虚拟机处于静默状态，如果在线备份方式失败，VBR就会切换到另外两种方式以确保备份成功。默认情况下，VBR会从在线备份转成崩溃一致性备份，如果这时候还是希望创建一致性快照，可以调整设置来让VBR通过使虚拟机休眠的方式做离线备份。

1. On-Host备份

这是Hyper-V上默认的备份模式，也是最推荐的备份模式。这种模式完全不需要额外的配置，使用起来非常简单、稳定和高效。当备份开始时，运行着这台虚拟机的Hyper-V主机会处理所有虚拟机的数据，而拥有CSV卷的主机则被分配了Veeam备份代理的角色。

Hyper-V On-Host模式的备份流程如图2-3所示。

1）VBR向Hyper-V请求创建一份相关的卷快照。

2）VBR的数据搬运工服务在Hyper-V主机上启动并挂载该卷快照，将虚拟机的数据传输到目的地，这个目的地可能是备份存储库或者在另外一套Hyper-V中。

3）在数据传输结束后，删除卷快照。

图　2-3

2. Off-Host备份

这种模式并不常用。在这种备份模式下，备份操作并不在Hyper-V主机上进行，而是转移到了一台单独的物理服务器上，需要注意的是，这里必须是由一台物理服务器担当Off-Host备份代理角色。这台单独的物理服务器上同样运行着Veeam数据搬运工服务，它从原存储卷中通过“可传递的卷快照拷贝”获取虚拟机数据。这样的配置方式可以让Veeam在Hyper-V上通过存储网络实现备份数据的处理，也就是通常所说的LAN-Free备份。

这种备份模式的配置还需要用到第三方存储厂商的组件VSS Hardware Provider。一般来说，各大存储厂商的官网软件包中都会有这个组件，以供应用程序使用。

Hyper-V Off-Host模式的备份流程如图2-4所示。

1）VBR在虚拟机所在的Hyper-V主机上触发对应的存储卷的快照。

2）在Off-Host代理上挂载这份卷快照。

3）VBR的数据搬运工服务在Off-Host备份代理主机上处理该挂载的快照，将虚拟机数据传输到目的地，这个目的地可能是备份存储库或者在另外一台Hyper-V中。

4）在数据传输结束后，从Off-Host备份代理中卸载这份快照，并从存储系统中删除它。

图　2-4

对Hyper-V来说，以上这两种备份模式略有差异，如表2-2所示。

表2-2　On-Host备份模式和Off-Host备份模式对比

2.1.3　Nutanix AHV

VBR在处理Nutanix AHV的虚拟机时，采用无代理的镜像级方法备份数据，这种方法在虚拟化系统管理程序层面处理数据，因此不需要在每一个虚拟机的操作系统内安装任何用于提取数据的代理程序。VBR在备份过程中会利用Nutanix AHV快照完成备份，在备份开始前，VBR会向Nutanix AHV请求一个卷快照，这个Nutanix AHV快照包含了相关虚拟机的配置信息、操作系统、应用程序、用户数据和系统的状态。VBR在备份时，会将这个快照作为数据源来抽取数据。

Nutanix AHV的虚拟机的备份过程如图2-5所示。

1）备份作业启动时，AHV备份代理控制台会下发备份作业配置。

2）AHV备份代理会将备份作业会话重定向至VBR服务器上。

3）AHV备份代理通过Nutanix Restful API和AHV群集进行通信，为备份作业中的虚拟机创建快照。

4）AHV备份代理创建相关的卷组，接着通过iSCSI挂载虚拟机的磁盘，然后从中读取虚拟机的数据。

5）Veeam数据搬运工服务压缩、重删这些数据，然后将这些数据发送到备份存储库，以Veeam专有格式存放。

图　2-5

Nutanix AHV备份代理

这是Nutanix AHV备份的核心组件，它是一个位于Nutanix群集中的基于Linux的虚拟设备。这个设备用于进行Nutanix AHV备份和恢复的所有工作，同时还提供了Web控制台，以用于配置Nutanix AHV的备份作业。这个代理设备是通过Nutanix Restful API和Nutanix群集进行通信的。每个Nutanix AHV的备份代理仅在自己所在的群集内工作，也就是说，每个Nutanix AHV的群集对应一个Nutanix AHV备份代理，即它们之间是一一对应的关系。

部署Nutanix AHV备份代理的方法很简单，只需要在VBR管理控制台上，利用Inventory面板中Backup Proxy节点下的Add按钮，就可以打开Nutanix AHV备份代理的推送安装向导，根据向导填入必要信息即可。需要特别注意的是，这个推送部署需要完整的DNS解析环境支持，因此如果环境中DNS基础架构不是很完善，则需要手工完成所有Hosts文件的添加，这里包括Proxy Appliance的Hosts。

2.1.4　镜像级备份中的快照问题

VBR在备份时严重依赖虚拟化的基础架构，绝大多数的备份操作需要稳定可靠的虚拟化环境，因此在日常的备份过程中，最基础的条件是确保与虚拟化管理平台有稳定的连接。以vSphere为例来说明，建议通过vCenter管理所有的ESXi主机，这时候只需要将vCenter添加至VBR中就能进行单点集中管理了。

由于备份过程涉及虚拟化平台快照操作，因此所有基于虚拟化平台快照的限制都将会是备份过程的限制条件。比较常见的情况是，vSphere上的虚拟机使用了物理RDM模式或者独立模式的VMDK磁盘，vSphere不允许对这些磁盘执行快照操作，基于vSphere快照的无代理备份在这样的配置中也就无法进行了。同样的情况也会存在于Hyper-V平台。

虚拟化平台的快照操作或多或少会对生产环境产生一些影响，特别是在快照移除的那一刻，磁盘的I/O会显著增加，这时候对于一些I/O敏感的应用程序，影响就会尤为严重。另外在快照移除的最后一瞬间，通常伴有虚拟机的“假死”现象，这个假死通常持续1～2秒。有时候由于I/O负载太重，存储性能较差，假死时间会变长，这属于快照合并过程中的正常状态，基础架构管理员需要根据生产系统对“假死”现象的承受能力，合理调整存储的性能。

虚拟化平台快照的原理很简单，但是在实际使用过程中通常会产生各种各样的问题，在重度使用快照的备份环境中，这些问题会特别突出，为了避免快照影响生产环境运行，可以注意以下配置：

·尽可能升级虚拟化平台至最新版本，同时升级虚拟硬件版本和虚拟化平台集成工具，如VMware工具（VMware Tools）和Hyper-V集成工具（Hyper-V Integration Tools）等。

·确保每个数据存储上同时开启的快照数量尽可能少。VBR默认配置了每个数据存储上同时存在的快照数量小于等于4个，虽然可以通过调整注册表增大这个数值，但是由于这个影响会以指数级增长，在实际使用中需要通过严格的测试，确定合理的数值，切勿盲目调大该数值。

·在生产系统不太繁忙的窗口调度备份作业。

·为快照预留足够多的磁盘空间，根据快照的机制，在快照被创建后，所有的变化数据都会被写入一个新的文件中，随着时间的推移这个文件会越来越大，直到它被整合回原始的虚拟磁盘。因此这部分数据通常放在不进行备份的环境中且并没有被计算在存储容量中。根据备份的最佳实践，一般建议普通虚拟机至少预留10%的数据存储容量作为快照临时空间；而数据变化量比较大的诸如SQL Server、Exchange等服务器，则建议预留20%的数据存储容量作为快照临时空间。

出于各种原因，虚拟化平台中有时可能会出现快照堆积现象，如果没有及时发现，这会对生产环境产生严重的影响。实际上，这个情况往往并不容易发现，除了使用正常的监控管理手段之外，Veeam在软件中设计了快照猎手的功能，用于全自动地处理快照堆积问题。

通常，在每个备份和复制作业中会自动执行这个功能，因此对于一般用户而言，这个功能在后台全自动进行。VBR会全自动处理可能碰到的一切快照问题，它的处理过程分为两大步：

1）检测是否有上次备份残留的Veeam辅助快照“VEEAM BACKUP TEMPORARY SNAPSHOT”。如果有，将在本次备份之前删除该快照。这个过程会确保处理干净历史任务中残留的Veeam快照。

2）检测是否存在孤立的快照。如果有，尝试将它整合。这个过程确保除了上一种情况之外的所有情况都会被正确修复。

而对于第二步，VBR又会采用一组复杂的整合算法：

1）普通的快照整合方法。这种方法和虚拟化平台控制台菜单中的“整合”按钮的功能完全相同，如果能用vSphere菜单中的“整合”按钮完成整合，那么事情非常简单，VBR会用这个功能立刻完成整合。

2）强制整合，不带静默。如果上一种方法失败，VBR就会执行第二种方法，这种方法中，VBR会借助快照技术创建一个新的快照，然后调用虚拟化平台的“删除所有快照”命令，一次性删除所有的孤立快照，恢复磁盘状态。

3）强制整合，带静默。如果第二种方法还是失败，Veeam会执行第三种方法，这种方法会创建虚拟化的静默快照，然后再次使用“删除所有快照”命令。

4）如果以上3种方法都失败，VBR会向用户发送失败警告，这时建议手工处理孤立快照，避免生产存储被耗尽。

2.1.5　AWS EC2和Azure VM

对于在AWS EC2和Azure VM的公有云上运行的虚拟机，Veeam也提供了无代理的保护解决方案，与私有云的部署方式不同，对这两个公有云上的虚拟机的保护在云中进行，因此在云上部署备份服务器节点。

1. AWS EC2备份

AWS上的备份和灾备解决方案叫作Veeam Backup for AWS，它能够创建AWS EC2实例的镜像级备份存档，并将数据存放在Amazon S3中，当然也可以创建并维护EC2原生的快照链。当需要恢复数据时，可以通过Veeam Backup for AWS从S3或者快照中恢复整个EC2实例、EC2实例卷以及EC2实例中的客户机文件和文件夹。

在VBR上，由于Veeam Backup for AWS所创建的是Veeam专有格式的备份，因此这些备份可以像其他正常的镜像级备份一样被读取，并且可以使用VBR的备份拷贝作业创建云下的备份数据。利用这个数据可以实现云上、云下以及云间的迁移和使用，如图2-6所示。

图　2-6

Veeam Backup for AWS是一个基于Linux的EC2实例，从AWS Marketplace上能够很方便地搜索并部署这个备份服务器。它的主要功能是：管理所有备份相关的组件、快照、备份集以及备份和恢复策略。灾备管理员的所有操作都是通过访问这个备份服务器来实现的。

Worker实例是备份架构中另外一个重要组件，它是一个非持久运行的EC2实例，非常类似于云下环境中的备份代理，是个数据搬运工，它挂载EBS快照并把数据直接存到S3存储库中。Worker实例同样也具备云上工作负载按需使用和动态扩展的特性，只有在执行备份或恢复任务时，它才会根据实际的负载情况和工作要求出现并扩展，一旦任务结束，Worker实例将会被自动终止并删除。

Amazon S3存储库是备份的目标端，它利用Amazon S3来存储备份数据，Worker实例中的数据搬运工会将处理后的备份数据发送到Amazon S3存储库中。

2. Azure VM备份

Azure上的备份和灾备解决方案叫作Veeam Backup for Azure，它能够创建Azure VM的镜像级备份，并将数据存放在Azure Blob中，当然也可以创建并维护Azure VM的快照链。当需要恢复数据时，可以通过Veeam Backup for Azure从Blob或者快照中恢复整个Azure VM实例、Azure VM实例卷以及Azure VM实例中的客户机文件和文件夹。

在VBR上，由于Veeam Backup for Azure所创建的是Veeam专有格式的备份，因此这些备份可以像其他正常的镜像级备份一样被读取，并且可以使用VBR的备份拷贝作业创建云下的备份数据。利用这个数据可以实现数据的云上、云下以及云间的迁移和使用，如图2-7所示。

图　2-7

Veeam Backup for Azure是一个基于Linux的Azure VM，从Azure Marketplace上能够很方便地找到并部署这个备份服务器。它的主要功能是：管理所有备份相关的组件、快照、备份集以及备份和恢复策略。灾备管理员的所有操作都是通过访问这个服务器来实现的。

Worker虚拟机是备份架构中另外一个重要组件，它是一个非持久运行的Azure虚拟机，非常类似于云下环境中的备份代理，是个数据搬运工，它挂载虚拟机快照并把数据直接存到Blob存储库中。Worker虚拟机同样也具备云上工作负载按需使用和动态扩展的特性，只有在执行备份或恢复任务时，它才会根据实际的负载情况和工作要求出现并扩展，一旦任务结束，Worker虚拟机将会被自动终止并删除。

Azure的Blob存储是用于存放Azure VM备份的备份存储库，Worker虚拟机中的数据搬运工会将处理后的备份数据存放到指定的Blob存储中。

3. 云上、云间、云下的互通

VBR可以利用外部备份存储库（External Repository）的功能，分别将Amazon S3和Azure Blob存储添加至控制台中。通过这种方式，VBR可以管理来自Veeam Backup for AWS和Veeam Backup for Azure的备份。对于这些备份，VBR可以对其进行拷贝，将其拷贝至本地数据中心或者异地灾备站点；VBR还能使用常规的恢复手段，对备份进行各种各样的恢复操作，这和其他所有的Veeam镜像级备份完全一致。

2.1.6　Windows和Linux操作系统

除了以上提到的私有云和公有云上的工作负载之外，VBR还支持备份任意的Windows和Linux操作系统，假如操作系统并没有运行在上述提到的云平台中，而是运行在物理机或者其他的KVM平台上，VBR可以通过在Windows或者Linux操作系统中安装Veeam备份代理（Veeam Backup Agent）软件的方式实现数据的备份。

代理软件分为Windows版本和Linux版本，分别运行于不同的操作系统中。它们负责和备份服务器交互、调度和运行备份作业、处理备份数据并将其传递到备份存储库中。当然，这些备份代理软件也能够脱离VBR单独进行工作。