Veeam VBR v10 从安装到排障：虚拟化备份与恢复实战指南

简介：Veeam Backup & Replication v10 安装和使用手册是一份面向虚拟化运维人员与备份管理员的中文操作指南，系统讲解这套基于代理的备份复制方案如何部署，并保护 VMware vSphere、Hyper-V 虚拟机及物理机上的关键数据。资源为 PDF 电子书，全手册共 1 个文件，压缩包大小 5.09 MB，便于直接阅读或打印参考。

手册内容从产品架构入手，覆盖 Backup Server、Proxy、Repository 等核心组件，同时给出简单、高级与分布式三类部署方式的适用场景；正文也包含虚拟化环境及 VBR 各组件的安装要求。后续以图文步骤演示软件安装、启动 VBR Server、接入 vCenter、配置 Proxy 与 Repository，并深入讲解创建一般/应用备份任务、执行备份以及虚拟机/文件/应用恢复等操作，目录结构清晰，适合按章节快速定位。

目前已有 342 人学习下载，对正在选型或初次部署 Veeam v10 的用户来说，是一份可直接落地的安装配置与日常运维参考。

1. VBR v10 是什么：一份手册背后要解决的三件事

你眼前的是一份安装使用手册，可真正要解决的是三件事：怎么把备份软件装顺不翻车，怎么配出第一套能真正兜底的备份作业，以及真到要恢复那天，数据是不是还在一张可以信的快照里。Veeam Backup & Replication v10（下文简称 VBR v10）是虚拟化环境里最常见的企业级备份方案之一，核心能力是整机快照级备份、副本、归档和即时恢复。它适合几十台到几百台虚拟机、想放弃手工脚本、用统一平台管理备份窗口与恢复点的人。这篇笔记按我实际部署的顺序展开：先规划再安装，再配置作业，最后把踩过的坑一次讲清。

2. 部署前的规划：先定数据库和仓库，再选服务器

VBR v10 的安装包并不大，真正决定后面顺不顺的，是安装前定下三件事：备份服务器用哪台、数据库交给谁、备份仓库放哪里。这三件事不是「系统要求」里的死数字，而是部署现场最容易翻车的决策点。我见过不少环境，装完当天一切正常，运行一个月后系统盘满了、备份排队几小时、合成全备拖了一整夜，回头排查全是当初偷懒用了默认值。

2.1 服务器与存储选型：先定数据库再定机器

备份服务器是整套系统的大脑，跑着调度、数据库和与虚拟化平台通信的服务。我一般按备份规模选配置：几十台虚拟机以内，4 核 8GB 内存起步就能跑；虚拟机超过五十台，建议直接 8 核 16GB。系统盘至少留 60GB，数据目录单独放一块盘。这里最容易犯的错是把 SQL Server 的数据文件装在 C 盘，备份元数据持续增长，几个月后 C 盘报警，控制台打开都卡。

数据库是第一个必须提前决定的事。VBR v10 安装包自带 SQL Server Express，小规模环境开箱即用，不需要额外准备数据库。但 Express 版本的定位是轻量级，对数据库文件大小有限制，而且只能装在备份服务器本机。虚拟机数量多、作业并发高、需要把配置库独立维护的时候，我一般会先准备好一台独立 SQL Server 实例，安装时直接把连接指过去。判断标准很简单：预计虚拟机总数超过五十台，或备份作业并发超过四个，别犹豫，上独立 SQL。

备份仓库决定的是吞吐和空间，选型最核心的问题是「你打算让备份数据怎么流动」。常见做法是选一台 Windows 或 Linux 服务器，挂本地盘或磁盘阵列，作为主仓库；SMB 共享适合小规模环境，NAS 上开个共享就能用；去重存储设备适合长期保留但随机写性能一般；对象存储适合做归档层，恢复时延迟明显高于本地盘。下面这张表是我选型时对照看的：

仓库文件系统也值得提前规划。如果仓库盘是 Windows Server 2016 或 2019 的 ReFS，VBR 会自动启用快速克隆，合成全备只需要复制元数据，几秒钟就能完成，日常维护窗口可以大幅缩短。Linux 仓库或 SMB 仓库没有这个能力，合成全备要完整读一遍增量数据，仓库越大耗时越长。所以本地大仓库，我优先选 Windows + ReFS。

2.2 网络与备份窗口：备份模式和链路参数怎么取舍

备份模式要先想好，因为它直接决定每天跑多少数据、恢复点之间怎么衔接。VBR 常见的做法有三种：每日增量加每周全备，逻辑简单但每周全备对生产网络冲击大；反向增量每天把增量合并进全备，恢复点始终只有一个全备加最新增量，但合并操作消耗存储 IO；永久增量加周期合成全备是我自己最常用的组合，每天只传增量，全备在本地仓库通过 ReFS 快速克隆合成，不读生产数据。代价是全备链对增量完整性有依赖，所以我会额外安排每月一次活动全备，打断过长的链。

网络链路上的参数，重点是块大小和流量控制。块大小影响传输效率和仓库读写的粒度：局域网内仓库用 1MB 默认值没问题；跨站点备份或从远端仓库恢复，我会在仓库设置里把块大小调到 4MB，减少小包数量，吞吐会明显改善。跨办公室或跨数据中心的链路，建议开启 WAN 加速器，两端各部署一个加速器组件，做源端去重和压缩。还一个容易被忽略的是限速：备份窗口和业务高峰重叠时，给备份流量设一个最大带宽上限，避免把业务链路打满。

网络规划还要考虑恢复点目标和备份窗口的匹配。RPO 要求分钟级的业务，v10 的持续数据保护功能可以直接复制虚拟机 IO 到副本存储，不依赖定时快照；RPO 可以到小时级的，传统定时作业就够。备份窗口小于四小时的，我一般会评估并发数量：一台备份服务器同时跑的作业数不是越多越好，仓库盘的随机写能力往往先到瓶颈，用存储性能计数器看一眼就能找到天花板。

3. 安装 VBR v10：介质、前置条件与许可激活的三步走

规划做完，进入实际操作。安装本身并不复杂，但有几个前置检查不做，后面会以很隐蔽的方式翻车。这一章按我装机的顺序写，每条都是现场会遇到的真实问题。

3.1 安装前准备：系统、账号、端口和组件清单

第一步，准备系统。VBR v10 要求 64 位 Windows Server，我习惯用 Server 2016 或 2019，主机名固定，别用默认乱序名，后面配置虚拟化平台连接、添加代理都会用到机器名。电源计划别选节能，数据库服务和备份服务都需要保持稳定性能。网络用固定 IP，尽量避免 DHCP，因为控制台连接和许可激活都依赖地址可达。

第二步，账号。安装时用本地管理员账号，安装完成后日常维护建一个专用服务账号，按最小权限分配。域环境里我给 VBR 服务账号单独的组，避免直接用域管理员跑所有服务，否则密码轮换时影响面太大。给虚拟化平台的连接凭据也单独建一个只读账号，VBR 只需要读取虚拟机清单和创建快照，不需要给管理员权限。

第三步，组件检查。.NET Framework 4.7.2 及以上是必须的，还有对应的 Visual C++ 运行库。离线环境提前备好依赖包，在线环境安装程序会自动补。如果你所在的公司网络安全策略严格，安装程序联网检查依赖时可能超时，必要时把补丁源指定到内部更新服务器。

第四步，端口。控制台连接备份服务器默认走 9392 端口，安装向导会显示端口清单，包括代理、复制、副本等组件各自的端口。现场经验是：不要图省事直接放行整个网段，先把备份服务器、代理服务器、仓库服务器的端口白名单配好，服务起不来再逐个放行。防火墙策略审批慢的公司，这一步最容易拖慢上线进度。

3.2 安装步骤：五步流程里哪两步别一路点默认

安装介质运行后，进入向导，顺序是这样的：选择安装组件，选数据库，配服务账号，确认端口和目录，等待安装。每一步都有值得手动改的地方。

组件选择界面，备份服务器是核心服务必须装；备份控制台我建议装，命令行管理虽然存在，但日常操作图形界面效率高；如果后续要备份物理服务器，备份代理组件一并装上；跨站点复制和 WAN 链路优化需要 WAN 加速器组件。不用的组件不装，减少攻击面和资源占用。

数据库选择是第二个关键点。默认选项是安装内置 SQL Server Express，小规模可以直接用。如果第一步规划了独立 SQL，这里要填服务器实例名和凭据。我遇到过选「现有 SQL Server」后连接失败的情况，多半是账号权限不够，VBR 需要能创建数据库的权限，不是普通只读账号能搞定的。给 VBR 用的 SQL 账号单独建，别把业务系统的 DBA 账号借来用。

服务账号默认是本地系统账户，小规模可以接受。如果仓库是 SMB 共享，服务账号必须对共享路径有读写权限，否则后续添加仓库会报访问失败。这一步要在域策略里提前放行，现场临时去调共享权限，一般会卡很久。目录选择方面，数据目录改到大分区，数据库目录同样指过去，不要在 C 盘上赌它不会满。

3.3 激活与许可：试用转正、导入和到期前要做的动作

安装完成后控制台会提示激活。评估许可可以先用一段时间，功能基本完整，适合测试环境验证。正式环境拿到许可文件后，从控制台的「许可」入口导入即可，导入后立刻生效，不需要重启服务。许可类型按购买的版本区分，买的时候注意是否包含物理机代理备份、副本作业和对象存储归档这些功能模块，版本不对应的话，功能菜单会灰色不可用。

许可到期前 30 天，控制台会开始弹出提醒。到期后新作业无法创建，已有作业也会受影响，恢复功能通常不受限，但我不建议赌这个，生产环境提前一个月走续期流程。还有一个细节：VBR 的小版本更新包（类似 10a、10b 这种累积更新）会修复已知问题，安装是覆盖式的，配置不会被重置，但会短暂重启备份服务，必须在维护窗口操作。装之前看一眼补丁说明，确认没有你要用的功能变更。

4. 配置第一套备份作业：仓库、代理与保留策略的推荐值

安装完成只是开始，真正的配置工作是把备份基础设施组装起来。第一次配置不追求花哨，按下面的顺序把地基打牢：先加仓库，再连虚拟化平台，最后建备份作业。配置过程中用的都是经验参数，直接照抄可以跑顺，之后再按自己的环境微调。

4.1 添加备份仓库与代理服务器：先建房子再搬家

打开控制台，在存储基础设施里添加备份仓库。选择仓库类型，Windows 服务器本地盘或 Linux 服务器本地盘是主力选项。填服务器名和路径时，路径指向一个独立数据盘，不要放在系统盘。仓库添加后，设置并发写入进程数和块大小：本地盘仓库并发写入进程数默认即可，块大小选 1MB；远端或性能较弱的磁盘阵列，块大小上调到 4MB，减少 IO 碎片。

仓库高级设置里还有压缩和去重两个参数。压缩我推荐「最优」，也就是性能和压缩比的平衡点；选「最大」会让备份和恢复都变慢，收益却不大。去重方面，仓库盘本身是普通文件系统时，不用开 VBR 的本地去重，重复数据交给虚拟化平台底层或 ReFS 处理更合适；开了反而消耗 CPU，拖慢作业。

代理服务器是 VBR 读取虚拟磁盘数据的组件。小规模环境，备份服务器本身就能充当代理，不用额外配置。虚拟机数量多或跨网段时，我习惯单独再加一台代理服务器，让它在靠近生产存储的位置读取数据，避免备份流量绕远路。添加代理后在作业里指定，VBR 会自动负载分发。

4.2 创建虚拟机备份作业：来源、调度和高级参数一次设对

配置完基础设施，开始建第一个作业。备份作业向导里选择虚拟化平台，填入之前准备的只读账号，然后选择要备份的虚拟机。选虚拟机时有三个维度可选：单个虚拟机、文件夹、容器或标签。选容器和标签的好处是之后新增虚拟机只要打上对应标签就会自动纳入备份范围，不用每次手动加。

存储设置里，仓库选刚才建好的，恢复点默认保留 14 个，这个数字可以按业务保留要求调整。调度上，我习惯每天增量，每 7 天做一次合成全备。注意「合成全备」和「活动全备」的区别：合成全备在 ReFS 仓库上很快，在普通仓库上要整读增量数据；活动全备则要直接从生产虚拟机读全量。你可以在同一个作业里同时配置两种全备策略，比如平时用合成，每个月做一次活动全备，把长增量链打断。

高级设置里有几个参数值得手动确认。应用感知处理必须打开，这样数据库和域控这类应用才能达到崩溃一致性以上的一致性级别。虚拟化平台的集成组件要提前装好，vSphere 环境装对应工具，Hyper-V 环境装集成服务，否则应用感知会静默失败。还需要勾选「应用感知处理失败时继续进行备份」，让作业在极端情况下降级为宕机一致性备份，而不是直接失败。

网络和重试参数按下面这张表设置，覆盖大部分场景：

4.3 副本作业与归档策略：把「有备份」变成「有退路」

备份作业建好后，我建议再加两类作业：备份复制和归档。备份复制是把已有备份从主仓库再复制一份到第二个仓库或异地站点，实现最基本的 3-2-1 原则。它和备份作业的区别在于数据来源不是生产虚拟化平台，而是主仓库里的备份文件，所以不会增加生产环境的负载。复制调度一般每天在备份完成后跑，保留策略按灾难恢复要求设置。

归档则把更老的恢复点转移到对象存储或磁带。对象存储适合容量大、访问频率低的场景，恢复时要把数据拉回来，速度比本地盘慢，所以只放不常用的历史点。磁带归档适合长周期合规保留，成本低，但恢复流程要提前演练。配置归档时注意设置保留策略和存储分层阈值，避免冷数据频繁来回读写产生额外费用。

5. VBR v10 排障笔记：五个常见坑的现象、原因与处理

这一章是我和同事在多个环境里踩出来的合集。每个坑都按「现象 — 原因 — 解决」讲，遇到类似症状直接对着查，能省不少排查时间。

5.1 备份作业一直排队，就是轮不到它

现象：作业列表里出现排队状态，后面的作业等好几个小时甚至跨天；仓库同一时间只能跑一个作业，其他作业全部挂着。

原因：并发任务数到了上限；代理服务器的处理线程被占满；仓库所在磁盘 IO 被打满。最常见的是第三种，特别是所有人把作业都排在同一个仓库，高峰时段磁盘随机写成了瓶颈。

解决：先在备份服务器上看仓库的实时吞吐和磁盘队列长度，队列长期很高就是磁盘到了极限，这时候把仓库并发写入进程数降下来，或者把部分作业调度错开。再看代理服务器数量，虚拟机多的时候加一台专用代理，效果立竿见影；不要盲目调大并发，磁盘跟不上只会让作业排队更长。

5.2 虚拟机快照残留，备份作业报删除快照失败

现象：备份失败，错误提示是快照删除失败；打开虚拟化平台管理界面，看到虚拟机上挂着大量快照，磁盘占用明显变大。

原因：应用感知处理卡在了客户机里的 VSS 协调环节；或者网络中断导致作业失败，快照清理步骤没有执行完。

解决：先在虚拟化平台上手动删除残留快照，恢复磁盘状态。然后打开作业高级设置，启用「应用感知处理失败时降级为宕机一致性」，这样即使 VSS 挂起，作业也会继续跑，不让快照一直挂着。最后检查备份服务器和虚拟化平台之间的网络，避免代理跨慢链路去连存储。

5.3 系统盘满了，备份仓库却还有空间

现象：C 盘空间告警，控制台打开变慢，数据库相关服务起不来，作业大面积失败。

原因：SQL Server 的数据库文件和日志默认装在 C 盘，备份作业的元数据持续写入，系统盘越涨越满。仓库盘是满的还容易发现，系统盘满往往等到服务崩溃才发现。

解决：尽早把数据库迁移到独立数据盘，方法是在 SQL Server 里分离数据库，把数据文件移到新路径，再重新附加。注意不要对数据库文件所在目录做磁盘压缩，会导致日志写入性能骤降。同时在控制台配置磁盘空间告警，低于 20% 就发通知。

5.4 合成全备慢得离谱，备份文件还比预期大

现象：合成全备在 Linux 仓库或 SMB 仓库上跑了整整一夜；仓库里备份文件大小明显比同规模环境大。

原因：ReFS 快速克隆只在 Windows ReFS 文件系统上生效，其它仓库没有这个能力，合成全备就要完整读一遍增量链再合并，耗时和 IO 开销都很大。备份文件大，通常是压缩级别设置不对，或者重复数据没有被有效识别。

解决：主仓库优先用 Windows ReFS 卷；没有条件的话，把合成全备频率调低，改成每周活动全备加每日增量。压缩级别设置为「最优」而不是「最大」，因为最大压缩消耗大量 CPU，收益却微乎其微，还会拉长恢复时间。

5.5 恢复验证时发现备份镜像不可用

现象：运行恢复验证任务，虚拟机起不来，操作系统直接蓝屏；或者即时恢复能启动，但数据库应用一致性检查不通过。

原因：备份时没有做应用感知处理，数据库文件在备份瞬间处于不一致状态；也可能是恢复点正好落在数据库日志刷盘之前，日志没有完整记录。

解决：核心业务作业必须开启应用感知处理，并且确认虚拟化平台集成组件已安装。用定期验证任务来验证恢复点，发现不可用的恢复点标出来，重新跑一轮备份。不要只看备份作业绿色对号，真正能恢复才是唯一标准。

6. 让备份真正可用的最后一步：验证与恢复演练的习惯

6.1 用验证任务把备份检查变成例行公事

VBR 自带验证功能，可以把备份文件在隔离网络里启动成虚拟机，然后检查操作系统是否正常响应。我的做法是建一个专门的验证代理作业，把核心业务虚拟机的恢复点加进去，每周自动跑一轮。验证通过才认为恢复点健康，验证失败就触发告警并检查该恢复点。这一步和工作流里的「测试环境」一样，不能省。

6.2 每月一次完整恢复演练，测量真实恢复时间

备份只保证了有恢复点，恢复时间要靠演练测出来。我每个月做一次从备份文件完整恢复到新虚拟机的演练，记录从发起恢复到系统可用的总时长，然后对照业务能接受的停机时间，反向调整备份窗口和并发设置。三年下来，每次灾难切换都能做到心中有数，不会在真正出事时手忙脚乱。

我还养成了一个习惯：把每一次计划外恢复的经过和原因记在团队文档里，包括恢复点缺失、仓库故障、速度瓶颈这些细节。下次遇到类似问题时，直接翻文档对照，比重新排查快得多。这个习惯在一次验证差几天没跑、关键时刻发现某恢复点缺日志的意外里救过我一次，从那以后我再也不敢省掉验证环节。希望帮到你。

本文还有配套的精品资源，点击获取