简介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/Linux 服务器本地盘绝大多数生产环境吞吐高系统盘和仓库盘混用磁盘满拖垮全机SMB/CIFS 共享中小规模NAS 文件服务器协议兼容性和并发瓶颈注意 VBR 对 SMB 版本要求去重存储设备大容量长期保留随机写入差注意调大块大小对象存储归档、异地容灾恢复拉取数据慢不适合做主力仓库仓库文件系统也值得提前规划。如果仓库盘是 Windows Server 2016 或 2019 的 ReFSVBR 会自动启用快速克隆合成全备只需要复制元数据几秒钟就能完成日常维护窗口可以大幅缩短。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 环境装集成服务否则应用感知会静默失败。还需要勾选「应用感知处理失败时继续进行备份」让作业在极端情况下降级为宕机一致性备份而不是直接失败。网络和重试参数按下面这张表设置覆盖大部分场景参数位置推荐值说明块大小本地仓库 1MB跨站点 4MB影响传输效率与 IO 粒度压缩最优平衡备份速度与空间重试次数3 次间隔 10 分钟应对网络抖动和快照超时I/O 控制开启阈值 75%生产存储高负载时自动降速备份窗口错开业务高峰防止链路打满影响业务应用感知失败策略降级继续备份宁可要崩溃一致不要没备份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 每月一次完整恢复演练测量真实恢复时间备份只保证了有恢复点恢复时间要靠演练测出来。我每个月做一次从备份文件完整恢复到新虚拟机的演练记录从发起恢复到系统可用的总时长然后对照业务能接受的停机时间反向调整备份窗口和并发设置。三年下来每次灾难切换都能做到心中有数不会在真正出事时手忙脚乱。我还养成了一个习惯把每一次计划外恢复的经过和原因记在团队文档里包括恢复点缺失、仓库故障、速度瓶颈这些细节。下次遇到类似问题时直接翻文档对照比重新排查快得多。这个习惯在一次验证差几天没跑、关键时刻发现某恢复点缺日志的意外里救过我一次从那以后我再也不敢省掉验证环节。希望帮到你。本文还有配套的精品资源点击获取