灾备即服务（Disaster Recovery-as-a-Service，DRaaS）是一种云计算和备份服务形态，利用云资源来使应用和数据避免因灾难造成的意外中断。在云上保留数据的镜像，可为企业提供一个完整的系统备份，使其在系统出现故障时保持业务连续性。企业使用自建的或第三方提供的灾备即服务平台，可按需制定自身的灾难恢复计划（Disaster Recovery Plan，DRP）或业务连续性计划（Business Continuous Plan，BCP）。
VBR由以下三个主要角色组成。
1）备份服务器—整个备份系统的大脑，它是整个系统的配置和操作控制中心，负责调度任务和分配资源，设置和管理备份基础架构的各个组件。
2）备份代理（Backup Proxy）—负责处理原始数据，它根据VBR备份服务器的指令处理任务，传输备份数据。所执行的任务包括从生产系统获取数据、重删和压缩数据，以使备份基础架构能够更好地扩展。
3）备份存储库（Backup Repository）—保存数据的仓库，它用来存储备份，可以是各种存储设备，例如本地磁盘、文件共享、重删设备、云存储等。在VBR的工作过程中，会涉及大量的数据传输，其依赖于Veeam数据搬运工（Data Mover）服务来实现，
VBR在处理VMware vSphere的虚拟机时，采用无代理的镜像级方法备份数据，这个方法在虚拟化系统管理程序层面处理数据，因此不需要在每一个虚拟机的操作系统内安装任何用于数据提取的代理程序。VBR在备份过程中会利用vSphere快照完成备份，在备份开始前，VBR会向vSphere请求一个虚拟机快照，这个vSphere快照包含了这台虚拟机的配置信息、操作系统、应用程序、用户数据以及系统的状态。VBR在备份时，会将这个快照作为数据源来抽取数据。
VMware vSphere虚拟机的备份过程如下：
1）备份作业启动后，VBR会查询数据库中作业的配置信息，读取所有需要备份的虚拟机以及与它们相关的虚拟磁盘的列表，见下图中的步骤①。
2）VBR会为后续的备份过程准备一系列资源，如合适的备份代理和备份存储库，并为它们建立Veeam数据搬运工的数据传输连接，见下图中的步骤②。3）接下来，VBR会向vCenter或者ESXi请求虚拟机快照，在执行快照前，如果需要对应用程序进行一致性处理，VBR还会和客户机操作系统通信来处理应用程序，见下图中的步骤③。
4）备份代理上的数据搬运工从虚拟机快照中读取数据，如果是增量备份，则还会使用CBT（Change Block Tracking）技术获取增量的数据块。VBR在备份代理上对读取到的数据进行一系列处理，这些数据包括填零的数据块、交换文件、被排除的数据文件等，处理完成后，根据重删和压缩条件的设定，对数据完成重删和压缩，并把数据传递到备份存储库中，见下图中的步骤④。
5）数据传输完成后，VBR向vCenter或者ESXi发起快照合并请求，vSphere上的快照被删除，备份作业完成，见下图中的步骤⑤。
- 备份代理在VMware vSphere备份中，备份代理用于从vSphere中提取、压缩、重删、加密并发送数据至备份存储库。对于数据的传输，VBR支持以下三种模式：
·Direct Storage Access
·Virtual Appliance
·Network
这三种数据传输模式各有优劣势，在实际中，通常会选择一种最适合基础架构的模式来使用，在VBR中，任意一台受管理的Windows或者Linux服务器都可以配置为备份代理角色，但是根据数据实际传输路径和架构的不同，数据传输模式可能不同。
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格式为厚置备的磁盘。
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模式来提取和恢复数据。
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文件指定独立的备份管理网络即可实现备份数据网络和日常管理网络的分离。NBD模式在10Gbps以上管理网络中的表现非常突出。在使用NBD进行备份作业时，可以完全避免Direct Storage Access模式的复杂配置和Virtual Appliance模式的额外备份窗口开销，而且在NBD模式下工作比在以上两种模式下工作更加稳定和可靠。因此，为了确保备份作业顺利进行，VBR采用了多种数据提取方式混合使用并智能切换的方式。VBR会自动地智能感知当前的环境配置，根据当前的配置优先选择最优的数据传输方式。NBD模式通常作为Direct Storage Access和Virtual Appliance数据传输模式的备选方案，当这两种数据传输模式失败时，VBR会在备份作业进行中自动切换成备选的NBD模式，以确保在无人干预的情况下完成备份和恢复作业。
数据传输配置建议
（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个分支站点也需要一个备份服务器来支撑。
Microsoft Hyper-V：
VBR在处理Microsoft Hyper-V虚拟机的时候，采用无代理的镜像级方法备份数据，这种方法在虚拟化系统管理程序层面处理数据，因此不需要在每一个虚拟机的操作系统内安装任何用于提取数据的代理程序。VBR在备份过程中会利用Hyper-V快照完成备份，在备份开始前，VBR会向Hyper-V请求一个卷快照，这个Hyper-V快照包含了相关虚拟机的配置信息、操作系统、应用程序、用户数据和系统的状态。VBR在备份时，会将这个快照作为数据源来抽取数据。
Hyper-V虚拟机的备份过程如图：
1）备份作业启动后，VBR会查询数据库中作业的配置信息，读取所有需要备份的虚拟机以及与它们相关的虚拟磁盘的列表，见图中的步骤①。2）VBR会为后续的备份过程准备一系列资源，如相关的备份代理以及备份存储库，并为它们建立Veeam数据搬运工的数据传输连接，见图中的步骤②。3）接下来，VBR会向Hyper-V请求卷快照，在执行快照前，如果需要对应用程序进行一致性处理，VBR还会和客户机操作系统通信来处理应用程序，见图中的步骤③。4）备份代理上的数据搬运工从卷快照中读取数据，如果是增量备份，则还会使用RCT技术获取增量的数据块。VBR在备份代理上对读取到的数据进行一系列处理，这些数据包括填零的数据块、交换文件、被排除的数据文件等，处理完成后，根据重删和压缩条件的设定，对数据完成重删和压缩，并把数据传递到备份存储库中。5）数据传输完成后，VBR向Hyper-V发起快照合并请求，Hyper-V上的卷快照被删除，备份作业完成，见图中的步骤⑤。
在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模式的备份流程如图
1）VBR向Hyper-V请求创建一份相关的卷快照。2）VBR的数据搬运工服务在Hyper-V主机上启动并挂载该卷快照，将虚拟机的数据传输到目的地，这个目的地可能是备份存储库或者在另外一套Hyper-V中。3）在数据传输结束后，删除卷快照。
- Off-Host备份：
这种模式并不常用。在这种备份模式下，备份操作并不在Hyper-V主机上进行，而是转移到了一台单独的物理服务器上，需要注意的是，这里必须是由一台物理服务器担当Off-Host备份代理角色。这台单独的物理服务器上同样运行着Veeam数据搬运工服务，它从原存储卷中通过“可传递的卷快照拷贝”获取虚拟机数据。这样的配置方式可以让Veeam在Hyper-V上通过存储网络实现备份数据的处理，也就是通常所说的LAN-Free备份。这种备份模式的配置还需要用到第三方存储厂商的组件VSS Hardware Provider。一般来说，各大存储厂商的官网软件包中都会有这个组件，以供应用程序使用。Hyper-V Off-Host模式的备份流程如图
1）VBR在虚拟机所在的Hyper-V主机上触发对应的存储卷的快照。2）在Off-Host代理上挂载这份卷快照。3）VBR的数据搬运工服务在Off-Host备份代理主机上处理该挂载的快照，将虚拟机数据传输到目的地，这个目的地可能是备份存储库或者在另外一台Hyper-V中。4）在数据传输结束后，从Off-Host备份代理中卸载这份快照，并从存储系统中删除它。
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会向用户发送失败警告，这时建议手工处理孤立快照，避免生产存储被耗尽。
6 Windows和Linux操作系统
VBR还支持备份任意的Windows和Linux操作系统，运行在物理机或者其他的KVM平台上，VBR可以通过在Windows或者Linux操作系统中安装代理软件分为Windows版本和Linux版本，分别运行于不同的操作系统中。它们负责和备份服务器交互、调度和运行备份作业、处理备份数据并将其传递到备份存储库中。当然，这些备份代理软件也能够脱离VBR单独进行工作。备份代理（Veeam Backup Agent）软件的方式实现数据的备份。
应用程序数据处理
和传统备份方式不一样的是，VBR不单独处理应用程序，在VBR中不需要单独的备份应用程序代理（Agent），但是VBR的功能一样能够支持各种应用程序的备份和恢复，这也是在云环境下处理应用数据一致性的新发展要求。本节将详细讲述应用程序支持的方法，其中包括：·应用程序的代理和无代理备份·应用感知技术详解·SQL Server的备份·Oracle的备份
无代理备份:VBR的针对虚拟化平台的备份，是不需要在任何的操作系统内安装任何的代理程序（agent），因此备份不需要系统的运行状态。然而当应用系统处于运行状态时，这种无代理的备份技术还能够感知到应用程序，识别出应用程序的种类、保存应用程序的配置、同时存储应用程序创建的用户数据和应用数据。相比有代理的备份方式来说，这种方式的效率更高，使用起来更方便。
应用程序感知技术详解:
1. 应用程序备份：VBR的应用程序备份是随着操作系统镜像级备份同时进行的。镜像的应用程序感知处理是Veeam特有的技术，能够以应用程序感知的方式创建镜像级备份存档文件。这里涉及很多步骤：1）它会侦测在虚拟机内运行着什么应用程序。2）使用Microsoft VSS处理应用程序，使其进入静默状态，确保每个应用程序的状态一致。3）为受保护的应用程序赋予特殊的恢复设置，以准备对每个应用程序在下次虚拟机启动时执行VSS感知恢复。4）如果备份成功，则对某些应用程序执行事务日志修剪。以上整个过程完全自动化，不需要任何人工干预。VBR支持全自动感知Active Directory、SQL Server、Exchange Server、Share-Point和Oracle这些应用程序。如果虚拟机内部署了这些应用程序，VBR能够在备份系统镜像的同时，用以上方法处理这些应用程序，确保这些应用程序的一致性，同时还能够提供特别的恢复方法，恢复这些应用程序的对象。
- 静默方法：通常来说会有两种静默方法，一种是用VMware工具静默，另外一种则是通过应用程序感知处理来注入脚本。
在这里可能会用到两个脚本：前脚本（Pre-Freeze Script）和后脚本（Post-thaw Script）。这两个脚本都会在客户机操作系统内执行，因此需要用到操作系统的本地管理员账号。·前脚本：用于冻结数据库事务日志或者创建应用程序的一致性快照。对于那些无法冻结的数据库或者创建一致性快照的应用程序，也可以使用这个脚本停止应用程序，当然这也会带来额外的服务中断时间。·后脚本：用于解冻数据库事务日志或者删除在前脚本中创建的快照。如果在后脚本中停止了服务，那么这个脚本重新启动服务。对于一些常见的应用程序，VBR已经内置了这些应用程序的感知方法，灾备管理员不需要为这些应用程序准备特定的脚本，这些应用程序包括Active Directory、SQL Server、Exchange Server、SharePoint和Oracle。同时VBR提供这些应用程序的对象级恢复能力，可以从备份存档文件中直接恢复这些应用程序的对象。
在VBR的作业向导中，可以在“Guest Processing”步骤中设定应用程序感知的相关内容。下图展示了两部分内容，其中最上面“Enable application-aware processing”复选框就是应用感知部分。在这个复选框的右边有一个“Application”按钮，可以通过这个按钮为不同的应用程序做详细的设定。
为了能够和应用程序交互，必须为应用程序提供一个客户机操作系统本地管理员的账号，可以在“Guest OS credentials”中选择，也可以通过“Add”按钮添加新的账号，对于不同的操作系统Windows和Linux，VBR支持设定不同类型的账号。对于一个有多个虚拟机的备份作业，VBR支持为不同的虚拟机设置独立的管理员账号，以进行应用程序感知，图中的“Credentials”按钮就能提供这个功能。
客户机交互代理：为了能够统一管理这些系统的备份，往往又需要有备份专用网络或者接口，以和这些应用程序通信。在VBR应用程序感知镜像处理方法中，也会碰到这样的挑战，这时候可以通过客户机交互代理（Guest Interaction Proxy）来和这些特定的应用程序进行通信。引入了客户机交互代理之后，在备份架构中，VBR只需要向特定子网（Subnet）开放少量的端口就可以完成数据的备份。备份服务器、客户机交互代理和生产系统需要开放的端口如图：
注意：客户机交互代理只适用于客户机操作系统运行的是Windows虚拟机的情况。而这个代理本身，也必须是一台Windows服务器。除了使用客户机交互代理之外，VMware环境下，VBR还支持在无网络连接的情况下使用VMware VIX API，来和操作系统进行交互。vSphere 6.5之后，VMware弃用了这个API，启用了新的API（名字为vSphere API for guest interaction）。功能和以前的VIX基本一致，所以VBR还是沿用了以前的叫法—VIX。这个API同时支持Windows和Linux操作系统的应用程序感知。对于Microsoft Hyper-V，VBR支持使用PowerShell Direct和客户机交互，这只在Hyper-V 2016以上版本中存在。使用网络的方式和使用API的方式所需要的操作系统的权限略有不同。
SQL Server的备份
由于SQL Server的架构复杂，一些特殊的配置通常是没办法通过无代理方式来实现的，必须使用Veeam Agent来完成备份。
使用VBR进行SQL Server备份时，VBR可以处理整个SQL服务器的镜像来实现整个数据库的备份，同时也支持对于SQL Server事务日志的备份。1. 完整数据库的备份这里没什么特别的配置，只需要启用Guest Processing即可。唯一需要注意的是：对于SQL Always On群集，请确保将所有的Always On节点添加在同一个备份作业中，因为只有这样，VBR才理解这几台服务器的互相关系，保证所有的备份能正常感知，确保在恢复备份时能正常打开和执行恢复命令。2. 事务日志处理和备份除了备份完整的数据库之外，VBR还能处理和备份SQL数据库的事务日志。SQL数据库的日志处理有三种，可以从这三种里面选取其中一种，下图为VBR上SQL应用程序的选项。1）截断日志：防止数据库日志不断增大，相当于在备份后立刻清理数据库的日志。如果备份作业定时进行，此选项相当于定期清理日志。2）不截断日志：适用于简单恢复模式或者DBA已经定义了事务日志截断方式和计划任务，那么可以不用VBR来处理这个事务日志。3）定时备份日志：这里要求SQL Server的恢复模式必须是完整恢复模式或者Bulk-logged恢复模式。VBR首先会备份日志，备份完成后会进行日志的截断操作。这种处理方式可以令日志备份的时间间隔默认为十五分钟，最小为五分钟。备份后的事务日志会和备份存档文件放在同一个文件夹下，并且以VLB作为扩展名结尾。对于日志的保留策略，VBR提供了两种选项，跟随镜像级备份的保留策略或按最近多少天为单位进行保留。
3. 日志传输服务器对于定时备份日志，VBR还提供日志传输服务器的选择。它并不是一台专用的角色服务器，任意一台由VBR管理的Windows服务器都可以充当日志传输服务器。通常情况下，自动选择日志传输服务器能够让VBR最优化地决定使用哪个日志服务器，并且VBR还提供日志传输服务器的故障切换和负载均衡功能。日志备份的注意事项：在传输日志前，VBR会把数据库的事务日志临时文件存放在一个临时文件夹当中，默认的文件夹位于%allusersprofile%下，在绝大多数情况下，这个默认的文件夹都会位于Windows系统分区下。这往往会给磁盘分区造成很大的困扰，当日志数据变化量非常大时，系统分区有可能会被占满。Veeam提供了修改这一位置的方法，即通过调整VBR的注册表键值来完成：
路径：HKLM\SOFTWARE\Veeam\Veeam Backup and Replication
键值：SqlTempLogPath
类型：REG_SZ
默认值：未定义
可以根据实际需求，合理设置这个键值，设置完成后，需要重启VBR服务。在VBR备份涉及SQL Server时，VBR会将整个服务器的内容备份下来。假如这台服务器上有多个数据库或者多个实例，默认情况下，VBR不会单独处理某个数据库。VBR提供了通过注册表来排除SQL数据库的方法。这个排除选项在默认情况下是不出现的，需要修改VBR控制台上安装的Windows操作系统的注册表来实现，在修改前需要关闭VBR控制台。
路径：HKLM\SOFTWARE\Veeam\Veeam Backup and Replication
键值：EnableDBExclusions
类型：DWORD
值：1
重新打开VBR控制台后，可以在左上角的主菜单下找到Databases Exclusions选项，打开后如图：
文件级数据的保护
文件级数据保护需要适应目前文件服务器的主流协议，包括SMB文件共享、NFS文件共享、Windows文件服务器和Linux文件服务器。VBR的文件备份通过无代理的方式从这些对象中将文件备份出来，存放在VBR备份存储库中，当需要恢复的时候，VBR提供多种灵活的恢复方式。
VBR的文件备份流程如图：
1）当备份作业开始时，VBR会分配一个文件代理给对应的文件服务器来处理文件数据。2）文件代理开始枚举文件服务器中的所有文件和文件夹，并且为所有的对象创建对应的CRC文件夹树。3）文件代理将计算出来的文件夹的哈希值传输至缓存存储库。4）缓存存储库存储接收到的哈希文件夹树。每当缓存存储库接收到一个新的哈希文件夹树结构时，它会将其与在上次备份会话中创建的哈希文件夹树进行比较，一旦发现不同，缓存存储库会通知文件代理开始读取这些变化的数据。5）文件代理会从文件服务器中读取这些新的数据。6）文件代理会重新打包并传输这些数据到备份存储库。7）VBR对备份下来的共享文件数据进行归档，存放第二份拷贝。
1. 缓存存储库（Cache Repository）技术是一种非常特别的技术，它用于降低在文件共享上因为备份产生的访问压力，同时提升增量备份的速度。这个缓存存储库中存放了文件夹级别的哈希值。如果文件夹的哈希值发生了变化，缓存存储库能够快速准确地定位到哈希值改变的文件夹，从而从中快速获取到变化的文件。对于每一个添加到VBR中的共享文件，都会有一个唯一的缓存存储库与之一一对应。注意：因为缓存存储库并不用于常规备份数据的存放，因此缓存存储库必须是简单备份存储库，不能是横向扩展的备份存储库或者是重删设备。缓存存储库的位置离原始共享文件越近越好，用于缓存存储库的磁盘的速度也是越快越好，因为增量数据的查询速度完全取决于存放于缓存存储库中的文件夹哈希值的比对结果。
2. 文件代理（File Proxy）用于捕捉变化的文件，文件代理会从缓存存储库中获知哪些文件夹发生了变化，这时候，文件代理会访问这些变化的文件夹，从中找出变化的文件，并处理这些变化的文件，将它们备份至备份存储库。文件代理对于每个共享文件来说，并不是固定的，它只会在备份作业发生时被分配给备份作业。通过这种方式，备份作业开始时，可以利用多个文件代理进行并行处理，备份作业智能地分配被改变的文件夹至文件代理，由文件代理快速定位并找到改变的文件，将其处理后存储到备份存储库。在处理共享文件时，为了能够更好地处理文件锁问题，保证NAS文件一致性，VBR支持SMB v3版本的VSS快照以及存储级别快照。
备份数据的拷贝
数据保护和灾备的首要目标是：无论是发生硬件或者软件故障，还是发生物理机或者虚拟机故障，确保数据不丢失。而单份备份数据的存放，不管从哪个方面来说，都会是一个风险点，在数据管理中，备份数据的拷贝可以应对这样的风险。Veeam的备份拷贝是实现数据保护3-2-1黄金法则的基础，也是VBR的基本功能之一。它非常简单，实现效果就是：将一个还原点（Restore Point）完完整整地拷贝一份，使其变成一个新的可以使用的还原点。什么是还原点？在VBR中，它是某个虚拟机或者服务器某个时间点的记录，利用还原点，可以从VBR的存储库中将数据恢复回该时间点。对于还原点来说，它可能包含一个文件，比如vbk全量备份存档文件，也有可能包含一组文件，一个vbk和一系列vib，这取决于备份作业或者备份拷贝作业如何创建它们。
备份拷贝作业创建的备份链和普通的备份作业制作的备份链略有不同，备份拷贝创建的备份链通常是永久增量模型，也就是说，第一次传输中，备份拷贝会创建一个.vbk的全量备份存档，在第二次及后续传输中，备份拷贝会基于第一次的.vbk形成一份.vib的增量存档，并且一直创建下去。备份拷贝有两种模式，一种叫作Immediate Copy，另外一种叫作Periodic Copy，两种模式有一些区别，它们支持的内容不一样，如表：
除此之外，这两种拷贝模式在备份存档的创建上也有一些区别，对于Immediate Copy而言，它会根据主备份作业的设定，在主备份作业执行完成后，立刻创建一份备份拷贝存档。Immediate Copy是主备份作业的1∶1的完全还原点镜像。但需要特别注意的是，它不是简单的备份存档的镜像，也不是备份存档vbk和vib的文件拷贝。举个例子来说，如果在主备份作业中设置了每个周六创建合成全量备份（Synthetic Full）的备份作业，那么会在周六创建全量备份存档，而在这个备份存档创建好后，Immediate Copy作业会运行并创建对应的拷贝存档，这个创建出来的存档和主备份作业创建出来的vbk全量备份不一样，前者是vib增量备份。根据Immediate Copy的特点，它适用于所有需要进行应用程序日志复制的备份作业，因此在异地容灾时，对于关键的数据库系统，可以通过Immediate Copy提升数据库系统在灾备站点的RPO级别。
备份拷贝的工作原理
备份拷贝作业开始时，VBR访问存放源数据的备份存储库，从中读取指定的备份存档的数据块，将这个数据拷贝至目标备份存储库中。整个拷贝过程在后端的备份架构中进行，对前端的生产系统完全无任何影响，它不需要创建任何快照，拷贝任何数据。备份拷贝的执行过程如图：
1）备份拷贝作业开始后，VBR分别从源备份存储库和目标备份存储库上启动两个Veeam数据搬运工。这两个数据搬运工的位置可能会因为备份存储库的类型不同有所不同。2）如果这是第一次运行的作业，那么VBR会执行一个完整的全量备份拷贝，VBR根据所选择的还原点，从源备份存储中提取该还原点的完整数据。根据主备份作业的不同备份模式，VBR会用不同的方式从源备份存储库中提取备份数据。为了降低在网络中传输的数据，VBR会在传输前对数据进行压缩和重删。3）VBR会传输所有的拷贝数据到目标备份存储库中，然后将这些数据写入一个完整的备份存档中。4）在下一次备份拷贝开始后，VBR会捕捉新创建的还原点，一旦有新的还原点，VBR会将增量的变化数据传输到目标备份存储库中，创建一份增量的备份存档。
备份拷贝的传输方式
VBR支持点对点的备份数据直接传输，这个非常适合数据中心内或者是高带宽的专线网络内的数据拷贝传输。这种方式的数据传输效率非常高，并且没有额外的组件要求，采用这种方式的配置不需要在备份架构中加入任何组件，可直接创建拷贝任务来使用，非常简便。除此之外，VBR还支持通过广域网加速器进行备份的异地传输。这种传输数据的方式能够借助广域网加速器来应对窄带宽、高延迟、高丢包的恶劣环境，对于长距离的数据传输效果特别显著。它的实现方式，需要在源站点和目标站点各部署一套广域网加速器，用来完成数据的传输。使用广域网加速器时，VBR通过组合多种技术，极大地减少了网络中传输的数据，仅仅传输必要的数据块，从而提升了数据传输的效率。
VBR（Veeam Backup & Replication）的备份作业大致可以分为两大类：一类是从生产系统上将数据取出来的主备份作业（Primary Backup Job）；另一类是备份数据的二次复制作业，即备份拷贝作业（Backup Copy Job）。这两种备份作业在备份模式上略有不同，但将两种作业合理搭配，能够完美地实现3-2-1-0数据保护黄金法则。
1.主备份作业中的备份模式
主备份作业的备份模式有两大类，分别是正向增量（Incremental）备份和反向增量（Reverse Incremental）备份。这两类模式配合不同的全量备份选项可以衍生出多种备份模式:
(1.)正向增量备份和反向增量备份:
VBR在第一次执行正向增量备份时会先创建一个全量备份存档。执行完第一次全量备份作业后，VBR执行后续备份作业时仅会对自上次备份作业执行以来已更改的数据块进行备份，并将这些数据块作为增量备份数据保存在增量备份存档中:
VBR在第一次执行反向增量备份时会先创建一个全量备份存档，在执行后续备份作业中，VBR仅备份自上次备份作业执行后已更改的数据块，并将备份的数据块“注入”前一个时间点产生的完整备份存档中，这样可以始终保证最新的备份存档是一份全量备份存档。在注入的过程中，被注入的那些数据块会被提取出来组合成一份反向增量备份存档，反向增量备份存档与全量备份存档按照备份时间的先后相关联，对于这样的模式，在进行数据恢复时VBR全自动感知还原点，通过反向注入恢复完整的数据:
正向增量备份会创建两种格式的备份数据，一种是全量备份数据，其扩展名是.vbk，另一种是正向增量备份数据，其扩展名是.vib。反向增量备份也会创建两种格式的备份数据，一种是全量备份数据，其与正向增量备份一样，扩展名是.vbk，而另一种是反向增量备份数据，其扩展名是.vrb。虽然它们的文件类型不同，但实际上在VBR中最终呈现的还原点效果是完全一致的。
正向增量备份和反向增量备份的创建过程完全不同。正向增量备份的创建过程是变化数据的直接存放过程，VBR从生产系统取得需要备份的变化数据，对其处理后直接写入.vib文件中。而对于反向增量备份来说，VBR同样会先从生产系统取得需要备份的变化数据，然后VBR会将取得的变化数据和前一天的全量备份数据（.vbk）进行整合，即将变化数据注入全量备份存档中，而在注入的同时，提取出那些将被覆盖的数据块，将它们写入一个.vrb文件中，以创建出一个特殊的存档。对这份存档进行恢复时，通过往.vbk的再次反向注入，变回原来的状态。
反向增量备份中最新的全量备份存档的产生实际上类似于一个合成全量备份的创建过程，这个过程中存在复杂的数据提取、注入和组合操作，因此这种模式相比直接写入文件的正向增量备份要慢一些，而它的好处是，最新的还原点永远是一份完整的全量备份存档，如果需要频繁地使用最新的还原点，实现快速地恢复至最新的还原点，那么反向增量备份是一个很不错的选择。
在正向增量备份中，VBR能够提供定期全量备份选项，这个全量备份可以由合成的方式（Synthetic Full）创建，也可以由主动提取生产完整数据的方式（Active Full）创建。而在反向增量备份中，VBR仅提供了主动提取生产完整数据的方式来创建全量备份。
在VBR备份作业设置的高级选项中，可以为该作业选择备份模式，这由选择Reserve incremental（slower）或者Incremental（recommended）来实现，不同备份模式会产生不同类型的增量备份存档；而复选框“Create synthetic full backups periodically”和“Create active full backups periodically”则为这两种模式提供更多的全量备份存档创建时间选择。在没有勾选这些复选框的时候，系统不会创建第二份全量备份存档，而在勾选了这些复选框后，系统将根据所设定的时间，在指定的时间点创建全量备份。
结合全量备份作业的选项设置，VBR的备份模式及其产生的备份链会衍生出多种不同的模式，分别如下：·永久正向增量备份：不加入任何合成全量备份和主动全量备份；·正向增量备份：加入定期的合成全量备份或主动全量备份；·反向增量备份：不加入任何主动全量备份；·反向增量备份（带主动全量备份）：加入定期的主动全量备份。对于反向全量备份来说，除初始全量备份以外，最新的全量备份存档创建是一个增量数据注入前一份备份存档并形成最新全量备份的过程，和正向增量备份的合成全量备份模式类似，因此对于反向增量备份来说，并没有合成全量备份的必要，也就不存在这种衍生模式。而对于设置了主动全量备份的反向增量备份，它几乎不在实际场景中使用，本书对这种模式不展开具体讨论。
各种模式在实际的运行中对I/O、容量以及设备兼容性会有不同的要求，
对于绝大多数的日常备份来说，通常会选择正向增量备份方式，它是最有效的平衡备份时间和备份容量的一种方式，然而在某些情形下，合理使用增量备份、带全量备份的增量备份以及反向增量备份能够帮助企业更好地利用基础架构的性能达成数据保护的目标。
(2) 主动全量备份
主动全量备份通常穿插在正向增量备份过程中进行，它的执行过程和每个备份作业的第一次全量备份执行过程完全一致，它会从生产系统中读取数据并将其存放至备份存储库，因此它和第一次全量备份一样，会产生大量的I/O、消耗大量的时间并占用大量的备份存储空间。在计划使用主动全量备份时，需要特别注意它会带来的这个负面影响，确保有能满足这个模式的网络带宽、备份窗口以及足够的备份空间。
推荐使用的场景
1）使用DELL EMC DataDomain或HPE StoreOnce等重删设备作为备份存储库，但是重删设备没有使用一些专有的技术（如DELL EMC DDBoost技术、HPE Catalyst技术）而是使用SMB或者NFS协议来存取数据；
2）低端备份存储设备作为备份存储库，存储设备使用软件Raid或没有使用硬件Raid缓存，如低端NAS设备或没有SAS控制器缓存的服务器。
不推荐使用的场景
1）没有足够的备份窗口；
2）对I/O性能非常敏感且负载接近饱和的虚拟机进行备份。
主动全量备份的操作可以由管理员主动发起，因此，每个备份作业的工具栏上都会有一个“Active Full”按钮，在必要的情况下，管理员可以人工发起这个主动全量备份作业。
(3)合成全量备份
合成全量备份分成前半过程和后半过程来完成，前半过程中，合成全量备份和普通的增量备份一样，会从生产系统读取变化的数据块，这时候通常会使用CBT技术来快速提取变化的数据块，在这个过程中读取的数据量非常少，通常仅为总数据量的5%～10%。后半过程中，VBR会在备份存储库中完成全量备份的合并过程，利用历史还原点中的数据和从生产系统中获取到的最新数据，在备份存储库中对数据进行组合，从而创建一份和当前的生产系统状态完全一致的全量备份存档。因此，合成全量备份并不会消耗生产系统的大量的I/O和备份网络资源，而是会消耗备份存储库的I/O，这正好和主动全量备份相反，进而完美弥补了主动全量备份的所有缺陷。
推荐使用的场景
1）使用ReFS和XFS作为文件系统的备份存储库；
2）使用支持设备端完成合成全量备份操作的重删设备，如DELL EMC Data-Domain（使用DDBoost协议）、HPE StoreOnce（使用Catalyst协议）和Exagrid等；
3）备份存储库使用的磁盘的速度比较快，具有使用硬件Raid缓存做加速的磁盘设备。
不推荐使用的场景
1）使用SMB或者NFS协议的DELL EMC DataDomain、HPE StoreOnce等重删设备；
2）低端备份存储设备作为备份存储库，设备使用软件Raid或没有使用硬件Raid缓存，如低端NAS设备或没有SAS控制器缓存的服务器。
合成全量备份的操作是VBR系统自动根据一定条件所进行的操作，因此管理员无法人工发起这个操作，VBR会根据设定的条件，在条件满足时进行自动合成操作。根据ReFS和XFS文件系统的特性，合成全量备份可以使用FastClone和Refcink的API，这时候，合成全量备份操作几乎没有任何额外开销，不需要花很长的时间，不产生额外的I/O，没有占用重复的容量，所带来的收益是任何其他模式不可比拟的。
(4)永久正向增量备份
这是一个特殊的备份模式，虽然管理员并没有勾选合成全量备份的选项，但实际上由于永久正向增量备份节省存储空间的特性，在每次执行备份作业的时候，都会进行备份存档的注入操作，注入操作完成后可以生成一份全量备份存档。管理员要使用这种模式时，需要特别关注在注入备份存档时，备份存储的I/O使用情况。对于总容量不大、每日数据量变化也不大的虚拟机，比较适合使用这种模式。
(5) 不同备份模式间的切换
根据备份存储的更换（例如，将备份存储从高速的存储换为重删设备），或者备份存储容量的限制（例如，正向增量备份会占用大量的备份存储空间），VBR会调整备份模式。VBR可以轻松地在多种备份模式之间切换。它不会转换以前创建的备份存档，而是通过以下方式在现有的备份存档中创建一个新的备份存档：
1）如果从反向增量备份模式切换到永久正向增量备份模式或正向增量备份模式，那么VBR会在反向增量备份存档之后创建一组正向增量备份存档。反向增量备份存档中的全量备份存档用作正向增量备份存档的起点。
2）如果从永久正向增量备份模式或正向增量备份模式切换到反向增量备份模式，那么VBR首先会在增量备份存档之后创建一个主动全量备份存档，以此完整的备份存档为起点开始执行反向增量备份模式。
3）如果从永久正向增量备份模式切换到正向增量备份模式，那么VBR将根据设置的时间点创建主动或合成全量备份存档。
4）如果从正向增量备份模式切换到永久正向增量备份模式，那么VBR将不再创建主动或合成全量备份存档。自最近一次主动或合成全量备份以来创建的还原点数达到保留限制时，将删除过期的备份存档。删除过期的备份存档后，最终只会保留一份全量备份存档。此后，随着创建每个还原点，最早的增量备份存档将与全量备份存档合并。
2.备份拷贝作业中的备份模式
备份拷贝作业分为两种，一种是简单模式，另一种是GFS（Grandfather-Father-Son）模式。
简单模式的备份拷贝作业和主备份作业中的永久正向增量备份过程完全一致，因此它所创建的还原点也是由全量备份存档.vbk和增量备份存档.vib组成的，在执行每次备份作业时，都会进行注入备份存档的过程。GFS模式可以认为是GFS全量备份存档模式和简单模式的组合，日常备份存档和简单模式完全一样，而GFS备份存档一般用来长期保留和存放数据，这些存档会以全量备份的形式存放在备份存储库中。
在GFS备份存档中，通常会把每周的备份存档称为“子备份”，把每月的备份存档称为“父备份”，把每年的备份存档称为“祖备份”。另外VBR还引入了一种额外的备份存档，即每季度的备份存档。所有的这些存档都用于归档。在GFS模式下创建全量备份存档时，默认的创建方式为合成全量备份，这个过程是在目标备份存储库设备上进行的，那么对于异地传输备份存档来说会非常有效，因为完全不占用异地传输的网络带宽。而这种默认方式所面临的限制和普通的合成全量备份面临的限制完全一样，因为它就是常规的合成全量备份的过程，推荐的使用场景和限制条件可参考合成全量备份部分。当然，因为这个过程有利有弊，VBR为备份拷贝作业也提供了主动全量备份的选项。在备份拷贝作业中选中“Read the entire restore point from source backup instead of synthesizing it from increments”复选框后，VBR会使用主动全量备份来替换备份拷贝作业中的合成全量备份操作。
3.各种备份模式下的备份链
所谓备份链，是一组相互关联的备份存档，它们组合在一起形成了一系列的还原点。在VBR中，备份链根据备份模式的不同，可以是vbk文件和vib文件的组合，也可以是vbk文件和vrb文件的组合。备份集由一个或者多个备份链组成，每个备份链都是一个整体，备份链中的文件缺一不可，缺少任何一个vib、vrb或者vbk文件，整个备份链的数据都会被破坏。因此判断是否是一个备份链，最直接的方法是确认全量备份存档可以影响哪些增量备份存档，全量备份存档以及受其影响的增量备份存档属于一个备份链。
VBR备份作业中的还原点会依照备份模式并根据备份作业的执行发生动态的变化，永远没有一个固定模式，因此在设计备份作业时不用太在意备份还原点的数量，VBR始终能保证满足最少还原点数量的要求，这个和传统意义上死板的备份策略有很大的不同。在VBR中，正向增量备份和反向增量备份的备份链完全不同。备份链的创建由以下几个关键因素决定：备份模式、备份保留策略、全量备份的执行时间点。在VBR v10版本中，保留策略可以设置为时间模式或者数量模式。而此时配合上计划作业中按小时、按天、按月等多种执行方式，那么还原点和由还原点组成的备份链所产生的变化会非常多。使用不同的备份模式创建的备份集略有差异:
可以看出，只有正向增量备份存在着多个备份链的情况。也就是说，只有在正向增量备份模式下，在进行数据合成和删除的时候，是在新的备份链中进行的；而在其他的备份模式下，所有的数据合成和删除操作都将在同一个备份链上进行。后者的潜在风险是备份链上的数据会被二次修改。
4.从备份链中提取单个还原点
虽然VBR的备份存档格式的可移动性非常强，但是VBR的备份存档vbk、vib和vrb的组合方式也具有非常强的关联性，对于有关联的文件，缺失了任何个体，都可能会对恢复造成影响。如果要移动单个还原点，可以使用VBR中备份存档的导出（Export）功能。在每个备份存档的工具栏中，都可以找到这一功能，使用导出功能，无论这个还原点的文件是如何组成的（vbk/vib/vrb），导出操作结束后，最终都能得到一个合成的vbk文件。这个.vbk文件是该还原点的完整数据，它完全不依赖其他任何备份存档文件。因此，只要根据需要复制和剪切这个vbk文件，就能实现备份存档的移动，同时这个独立的还原点也能用于单个还原点的独立磁带归档。
BR可以同时导出处在不同备份存储库中的多个备份作业的还原点，被导出的还原点和原备份存档存放于同一个备份存储库中，在VBR的备份存档中会出现在“Backups（Imported）”节点下，管理员可以根据需要保留或者移除这个存档在VBR中的记录，也可以在Export向导中设置在一定时间后自动删除这个导出存档。
5.数据保留策略
对备份下来的数据如果不做任何删除，那么数据将会永久存放于VBR的备份存储库中，这样对备份存储库的占用会越来越大。在VBR的计划任务中，可以设置数据的保留策略，根据不同的设置规则会自动清理数据，并释放存储空间。数据保留策略跟随备份作业的运行而进行，在每次备份作业执行到最后，数据保留策略会检查当前存档是否满足删除条件，如果满足，则会删除超过保留期限的备份存档。数据保留策略定义了要在备份存储库中保留多少个还原点或将备份数据保留多少天。这两种方式为不同的使用场景提供了简单的计算方式，灾备管理员可以根据实际数据保留场景灵活选择。
对于定期执行的备份作业，使用还原点或者天数作为备份数据保留策略都可以满足数据保留需求。对于在定期执行备份作业之外还会手工执行一些计划外的备份作业，这时推荐使用按天数来保留数据。例如，每天按计划自动执行一次备份作业，数据保留14个还原点，即希望保留14天的备份数据。如果每天还会手工执行一些备份作业，一天内可能会有多个还原点，那么虽然设置了保留策略为14个还原点，但不能满足保留14天备份数据的要求。此时建议按天数来设置备份数据保留策略，这样就可以解决按照还原点设置备份作业时不定期执行备份作业所带来的备份数据保留时间缩短的问题。
对于按天数来设置备份保留策略来说，默认最小还原点数为3，VBR不计算在保留策略运行当天创建的还原点。例如，如果在星期六创建一个备份作业，并将备份数据保留时间设置为3天，然后每天创建完整备份。在星期日，VBR将保留在4天（星期四、星期五、星期六和星期日）内创建的还原点，在星期三创建的还原点将不计算在内。在星期三，VBR将删除星期六创建的备份文件，并保留在4天（星期日、星期一、星期二和星期三）内创建的还原点。保留期限可能会比设置的保留天数更长，具体取决于指定的备份模式。由于备份链中的数据存在关联性，因此不同备份模式的保留策略在实际使用中的表现完全不同，以下将详细讨论各种备份模式的数据保留策略。
(1)正向增量备份的数据保留策略
正向增量备份的备份集至少由两个备份链组成，这是这一备份模式的特点。如图所示，对于最新的备份链B来说，在没有执行新的全量备份之前，最新的还原点写入都会依赖于备份链B中的全量备份和其他增量备份还原点，此时，这样的备份链被称为未封闭的备份链；对于备份链A来说，任何一个新写入的还原点都不会依赖备份链A中的还原点，此时，这样的备份链被称为封闭的备份链。
封闭的备份链可以作为整体被安全地删除，而未封闭的备份链一旦被破坏，那么将会影响下一次的增量备份，备份作业会重新执行全量备份来保证数据的完整性。我们之前提到通过SOBR向对象存储库中转移数据，这时候在Move模式下，VBR只会转移封闭的备份链中的存档数据。
使用正向增量备份模式时，当现有还原点数量大于保留策略中定义的最小还原点数量时，VBR并不会立即自动从备份存储库中删除备份存档。只有当VBR确认在删除超过保留策略的封闭的备份链后仍有符合保留策略要求数量的还原点可以被用来进行数据恢复时，才会删除封闭的备份链。
下面举例来说明该数据保留策略的工作过程。在VBR中，备份作业配置：
执行效果：
在备份作业的第一个备份周期，创建备份链A，在第一个周六创建全量备份，之后六天进行增量备份；在第二个备份周期，创建备份链B，在第二个周六创建合成全量备份，同时系统检测到当前的还原点数量大于7个，但是因为删除备份链A中任何一个还原点都会破坏整个备份链A，导致备份链A中的7个还原点全部失效，因此无法进行还原点的清理操作，系统会继续保留完整的封闭的备份链A，在之后的六天继续执行增量备份。在第二个周五，系统完成增量备份后，检测到在删除备份链A后，剩余的还原点数量为7个，满足最少保留7个还原点的要求，此时系统触发保留策略，删除过期的备份链A，释放备份存储空间，
(2)永久正向增量备份的数据保留策略
永久正向增量备份只有一个备份链，所以数据保留策略设置的还原点数量和实际备份产生的还原点数量是一致的。如果永久正向增量备份链中的还原点数量超过了保留策略设置的还原点数量，那么VBR会处理最早的增量备份存档和全量备份存档，清理过期数据。下面举例来说明该数据保留策略的工作过程。在VBR中，备份作业配置如表:
执行效果如图所示，
在备份作业中创建一个周期为5天的备份链，其中最早的一份备份在周六创建，为全量备份，之后4份为增量备份。在第六天（即周四），系统执行新的增量备份，执行完成后，检测到还原点数量超过5个，系统开始执行注入操作。这个注入操作会将周日的vib备份存档的数据块注入周六的全量备份中，替换相关数据块形成一份新的周日的全量备份存档。在注入完成后，周六的全量备份存档自动消失，该vbk文件自动变为周日的全量备份。完成注入过程后，磁盘上存在两份周日的备份存档，一份为vbk文件，另一份是vib文件，接下去系统会进入删除过程，将已经被注入vbk文件中的vib备份存档从备份链中删除，之后每个还原点创建好后都会重复这个过程。
(3)反向增量备份的数据保留策略
与永久正向增量备份的还原点相似，反向增量备份也只有一个备份链，因此数据保留策略设置的还原点数量和实际备份产生的还原点数量是一致的。如果反向增量备份链中的还原点数量超过了保留策略设置的还原点数量，VBR会立刻删除最早的vrb文件，清理过期数据。下面举例来说明该数据保留策略的工作过程。在VBR中，备份作业配置如表
执行效果
在备份作业中创建一个周期为5天的反向增量备份链，其中最新的一份备份在周六创建，为全量备份，其他更早的备份存档为反向增量备份存档。随着每天新的备份存档产生，最早的那份备份存档并不被其他的备份存档所依赖，因此当整个备份链中的备份存档数量超过5个，系统会自动删除最早的vrb文件，释放存储空间。
(4)删除无效数据策略
除了在主备份作业中设置备份存档的保留时间，某些情况下，在VBR完成配置并运行备份作业后，可能需要对基础架构或备份策略进行更改。例如，将某些虚拟机或物理主机从已经运行了一段时间的备份作业中排除，后续执行的备份作业不会对这些已经从备份作业中排除的虚拟机或物理主机进行备份，这些已经排除在备份作业之外的虚拟机或物理主机之前产生的备份存档终将过期或无效，但这些过期或无效的备份存档没有达到保留策略的要求，不会进行自动删除。如果不能删除这些过期或无效的备份存档数据，那么主备份作业的数据保留策略将会受影响，从而导致过期、无效数据不能被删除，使大量不需要留存的备份存档仍存于备份存储库中，浪费备份存储库空间，进而可能影响主备份作业的执行。
VBR在对备份存档进行二次操作时非常小心和谨慎，虽然造成的负面影响不可避免，但是在某些场景下必须要进行备份存档的二次操作。因此在备份作业的高级设置（Advanced Settings）中，针对某些场景，需要设置存储级数据维护和文件级数据维护来确保被处理后的备份数据的完整性和一致性。如图下图所示，这里的存储级数据维护分为两部分：
存储级别损毁保护（Storage-level corruption guard）：这个选项用来保证所有备份数据的一致性，它会校验备份存档中的数据块，找出坏块并进行自我修复。一般建议所有不做定期主动全量备份的作业都开启这个选项，它对合成全量备份数据的健康度非常有帮助；而对于在存储级别已经包含了数据修复功能的那些备份存储设备，比如EMC DataDomain、HPE StoreOnce等重删设备，建议关闭这个选项。需要注意的是，这个存储级数据维护选项会额外增加备份作业的执行时间，管理员可以指定在某个特定的时间来执行以上这些操作。在设置这个选项前，务必根据实际备份存储库的性能、备份数据容量做好相关的测试采样，之后再决定最终的执行时间，这样做能对整体的备份作业长期运行有一个比较好的预期。
全量备份存档维护（Full backup file maintenance）包含两个选项：“Remove deleted items data after”和“Defragment and compact full backup file”。
▪ 勾选“Remove deleted items data after”这个选项，并指定已删除虚拟机的备份数据的保留天数。如果某个虚拟机不再可用（例如，该虚拟机已被删除或从备份作业中排除），那么VBR在指定的时间内将其数据保留在备份存储库中。过期后，VBR将从备份数据库中删除已删除虚拟机的数据。通过该策略可以防止已经不需要保护的虚拟机数据长时间留在备份存储库中。
▪ 勾选“Defragment and compact full backup file”选项后，可进行全量备份存档（vbk文件）的碎片整理和数据重构。启用“Remove deleted items data after”这个选项后，对于包含多个虚拟机的备份存档，已删除虚拟机的备份存档仍将保留在备份存储库中。仅当达到还原点保留限制或启用了“Defragment and compact full backup file”后才会真正删除已标记要删除的虚拟机的备份数据块。这个选项是除了正向增量备份之外的其他备份模式必选的，它无论是对vbk文件的容量节省和后期恢复数据的速度来说，都有极大帮助。同样对于重删设备来说，无须开启这个选项，因为重删设备有自己的数据维护和管理方法，能确保数据存放的合理性。
在经常会发生变更的备份作业中，建议勾选“Remove deleted items data after”选项，并指定所删除项目的数据必须保留在备份存储库中的时间。在删除无效数据时，必须谨慎对所删除的数据使用保留策略，强烈建议将保留策略设置为3天或更长时间，以防止不必要的数据丢失。在设置“Remove deleted items data after”选项来删除无效的备份数据的同时，还需要配置VBR的常规保留策略来保证备份链中具有足够的还原点数。
6.长期数据保留策略
长期数据保留策略使用GFS备份模式，即可以将备份存档存储数周、数月甚至数年。对此，VBR不会创建任何特殊的新备份存档，而是使用在备份作业运行时创建的备份存档，并使用特定的GFS标志来标记这些备份存档。
为了将备份存档标记为长期保留，VBR可以为这些文件分配以下类型的GFS标志：每周（W）、每月（M）或每年（Y）。VBR分配的GFS标志的类型取决于在备份作业配置中设置的GFS保留策略。GFS标志只能分配给在GFS保留策略指定的时间段内创建的全量备份存档。一旦VBR将GFS标志分配给完整的备份存档，便无法再删除或修改该备份存档，VBR的短期保留策略不会覆盖GFS设置的保留策略。当指定的保留期限结束时，VBR将取消全量备份存档的GFS标志。如果备份存档未被分配任何其他GFS标志，则可以根据短期保留策略对其进行修改和删除，
