☰
Veeam Backup Replication v10 安装配置与六种恢复方式实战指南
2026/11/2 3:02:14 网站建设 项目流程

简介:这份PDF手册面向需要部署虚拟化备份方案的系统管理员与运维工程师,围绕Veeam Backup & Replication v10的安装与使用展开,帮助读者从零搭建一套可用的备份复制环境。内容从产品介绍切入,先讲清Veeam Backup Server、Backup Proxy、Backup Repository Server三类组件的职责划分,再说明虚拟化平台与Windows Server版本等环境要求,并对比简单、高级、分布式三种部署方式的适用规模。安装部分覆盖软件安装、启动VBR Server、添加vCenter、Proxy与Repository设置等关键环节,任务章节则延伸到一般备份、应用备份、执行备份以及虚机、文件和应用恢复等操作,目录层次完整,便于按模块查阅。资源包共1个PDF文件,约5.09MB,单文件即涵盖架构说明与配置流程,适合边部署边对照。目前已有344人学习,可作为Veeam v10入门与日常运维的参考手册。

1. 拿到这份 Veeam 手册,先别急着翻到安装那页

虚拟化环境里最怕的不是机器宕机,而是宕机之后发现备份链是断的。我见过不止一个机房,vCenter 里虚机跑得好好的,真出事要恢复时才发现备份任务早就红了半个月没人看。Veeam Backup & Replication v10 这份安装和使用手册,解决的就是从「装起来」到「能恢复」这条完整链路上的操作落地问题——它不是产品白皮书,而是一份带截图步骤的实操文档,覆盖软件架构、环境要求、三种部署方式、安装配置、备份任务创建、六种恢复类型以及复制与回滚。

这份手册适合两类人:一是刚接手虚拟化备份工作的运维,需要照着步骤把 VBR server、Proxy、Repository 配起来;二是有一定经验但没系统梳理过恢复流程的工程师,想搞清楚 Instant VM Recovery、文件级恢复、SQL 应用恢复各自的前置条件和操作差异。关键词里的 veeam、veeamback、备份系统,对应的正是这套「备份 + 复制 + 恢复」一体化方案。下面按我拆文档的顺序,把能直接抄作业的部分和容易翻车的地方分开讲。

2. 架构与部署选型:三种模式对应什么规模的环境

2.1 组件角色拆开看,别把三合一当默认答案

手册第 1.1 节把产品组件列得很清楚:Veeam Backup Server、Backup shell、Backup Catalog Service、Backup SQL Database、PowerShell Snap-in、Backup Proxy Services、Backup Repository、Enterprise Manager。其中前三类加 SQL 数据库是安装时必选的,Proxy 和 Repository 是装完之后根据环境再配的。这个设计意味着你装完软件只是有了一个「控制中枢」,真正干活的搬运工(Proxy)和仓库(Repository)可以后面再挂。

简单部署把三个角色压在一台机器上,装完自动分配,适合小型环境或者测试验证。但手册 1.3.1 也直说了缺点:所有数据处理和存储都压在这一台上,中型以上环境单机容量扛不住。高级部署把角色拆到不同机器,处理负载从 Backup Server 移到 Proxy,容错性也上来了——数据存在独立 Repository 上,Backup Server 挂了不影响备份数据本身。分布式部署则是多地点各放一套 Backup Server,用 Enterprise Manager 集中管,适合有异地机房的大规模环境。

我一般的判断标准是:虚机数量在 50 台以内、备份窗口宽裕,简单部署够用;超过这个量级或者对恢复时间有要求,直接上高级部署,把 Proxy 单独拎出来。Proxy 的硬件要求不高(2 核起、2 GB 内存加每并发任务 200 MB),但它是数据搬运的关键路径,放在和源存储网络连通性最好的位置比堆配置更有效。

2.2 环境要求里几个容易看漏的硬约束

手册 1.2 节的环境要求表信息密度很高,但有几条是装之前必须确认的,漏了后面会返工。

虚拟化平台支持 vSphere 和 Hyper-V,ESXi 支持到 6.7 U3,但明确写了 Free ESXi 不支持——这一条卡掉不少小环境。虚拟机层面,基于主机的备份不支持虚拟 NVDIMM 设备、参与 SCSI 总线共享或驻留在 PMem 数据存储中的虚拟磁盘,因为 VMware 不对这类 VM 做快照;物理模式 RDM 磁盘、独立磁盘、通过来宾 iSCSI 启动器连接的磁盘也会自动退出处理。这类虚机要用基于代理的备份来保护,选备份模式时就得先分类。

Veeam Backup Server 的硬件底线是 x86-64、4 核建议、4 GB 内存加每并发作业 500 MB、5 GB 安装空间加 4.5 GB 的 .NET Framework 4.7.2 空间。另外两个目录要单独规划:来宾文件系统目录每 100 台 VM 约 10 GB,Instant VM Recovery 缓存文件夹建议至少 10 GB 且是非持久数据。这两个目录在安装向导第 6 步会让你指定路径,别随手放系统盘。

提示:vPower NFS 文件夹存放即时恢复时的写缓存,空间不足会直接导致 Instant VM Recovery 失败,安装时就按 10 GB 以上留足。

2.3 安装向导六步的配置取舍

手册 2.1 节的安装流程是六步向导,每一步都有需要做决定的地方,不是一路下一步。

第一步选安装包,第二步提供许可证——跳过就以社区版模式运行,后面可以再装正式许可证切换。第三步选组件和安装路径,默认装 Veeam Backup & Replication、Backup Catalog、Console,路径默认在C:\Program Files\。第四步设置服务管理账户,默认用 Server 本地管理员账户,域环境可以用域账户,但要求是该账户在 Server 管理员组内、且拥有安装所选数据库的权限。第五步选数据库,没有现成数据库可以自动装一个新的,正式环境建议连完整版数据库;连已有数据库时要选认证方式,默认 Windows 管理权限登录,也可以切数据库用户权限。第六步就是上面说的 vPower NFS 和 VBRCatalog 目录。

数据库这一步值得多说一句。自动安装的 Express 版在测试环境没问题,但正式环境并发任务一多,Express 的 10 GB 上限和性能会成为瓶颈。手册建议正式环境连完整数据库,我认同这个判断——备份任务的元数据、作业历史、恢复点信息都在这库里,它慢了整个控制台都卡。

3. 从添加 vCenter 到跑通第一个备份任务

3.1 启动控制台与添加 vCenter 的连接细节

装完之后从开始菜单进 Veeam Backup & Replication Console,身份验证窗口点 connect 连上 VBR server。然后到 Backup Infrastructure 视图,右键 Managed Servers 节点选 Add Server,在窗口里选 VMware vSphere 启动新建向导,填 vCenter 的 DNS 名或 IP。

这一步的坑不在操作,在凭据和网络。填的账户要有 vCenter 的只读以上权限,Veeam 需要枚举虚机、调快照接口;网络层面 Backup Server 到 vCenter 的 443 端口、到 ESXi 主机的连接都要通,Proxy 到 ESXi 的数据通道更不能断。手册 2.3 节只写到填地址这步,实际连不上时先查这两层,比在控制台里反复重试有效。

3.2 Proxy 与 Repository 的设置逻辑

添加完 vCenter,接着配 Proxy(手册 2.4 节)和 Repository(2.5 节)。Proxy 的传输模式选择直接影响备份方式:热添加模式对 Linux 虚机也支持(手册列了 Debian、RHEL/CentOS、Ubuntu 等发行版的 64 位版本),但要求虚机上装有相应条件;网络模式通用但走管理网络,大流量时和业务抢带宽。Repository 这边,Windows 和 Linux 都支持,Linux 仓库需要 bash shell、SSH 和 Perl。

Repository 的内存规划手册给了一个容易忽略的公式:4 GB 基础内存,加上每个并行处理的计算机或文件共享 2 GB(32 位 OS)或 4 GB(64 位 OS),具体取决于计算机大小、磁盘数量和备份链长度。备份链越长、还原点越多,元数据占用越高,这个内存在做容量规划时就要算进去,不是装完再看。

3.3 备份任务的参数与执行

创建任务分一般备份和应用备份两条线(手册 3.1.1 和 3.1.2)。一般备份选虚机、定作业名、选 Repository、设调度策略;应用备份在一般备份基础上开启应用感知处理,这要求虚机装 VMware Tools 且系统有 VSS 支持——Windows Server 2008 及以上支持 VSS 集成,Nano Server 除外,因为它缺 VSS 框架。

下面这段 PowerShell 是 Veeam 自带的 Snap-in 提供的,用来在命令行侧确认作业状态,排查「控制台显示成功但实际有告警」的情况时比翻界面快:

# 加载 Veeam PowerShell 模块 Add-PSSnapin VeeamPSSnapin # 列出所有备份作业及其最近一次结果 Get-VBRJob | Select-Object Name, JobType, @{N='LastResult';E={$_.GetLastResult()}}, @{N='LastRun';E={$_.GetLastRun()}} # 查看指定作业最近 5 次会话的详细状态 Get-VBRJob -Name "VM-Backup-Daily" | Get-VBRJobSession | Select-Object -First 5 CreationTime, Result, State

Get-VBRJob拿作业对象,GetLastResult()返回最近一次结果,GetLastRun()返回最近运行时间;Get-VBRJobSession拉会话历史,Result字段能区分 Success、Warning、Failed。Warning 往往意味着部分磁盘被跳过(比如前面说的 RDM 或独立磁盘),这种「看起来成功」的作业最危险,定期用这段脚本扫一遍比等出事强。

执行备份后,手册 3.1.3 节讲的是作业运行时的状态查看。这里补一个实操习惯:首次跑完不要只看作业状态,进备份文件里做一次 File-Level Restore 的浏览测试,确认 catalog 索引正常。VBRCatalog 目录如果空间不足或权限异常,备份能成功但文件级恢复时搜不到内容,这个黑匣子不提前打开,真恢复时就是血泪经验。

4. 六种恢复方式:选错类型比不会恢复更耽误事

4.1 恢复类型的分层与适用场景

手册 3.2.1 节把恢复类型列出来,后面五节分别展开:Instant VM Recovery、完整恢复、虚拟机文件恢复、虚拟磁盘恢复、Windows 文件级恢复、SQL 数据库应用恢复。这六种不是随便选的,按「恢复粒度」和「恢复速度」两个维度分层。

Instant VM Recovery(3.2.2)最快,直接从备份文件把虚机跑起来,写缓存落在 vPower NFS 目录,适合业务中断时先让服务上线再慢慢迁回正式存储。完整恢复(3.2.3)把整个虚机还原到目标位置,适合原虚机彻底损坏的场景。虚拟机文件恢复(3.2.4)和虚拟磁盘恢复(3.2.5)粒度更细,前者从备份里取单个文件,后者只还原某块 VMDK。Windows 文件级恢复(3.2.6)针对来宾系统内的文件,依赖 catalog 索引和 VMware Tools。SQL 数据库应用恢复(3.2.7)是应用感知备份的配套,能恢复到某个事务点。

选错的典型场景:虚机只是某个配置文件被误删,有人直接做完整恢复,几个小时的恢复窗口白白浪费,其实文件级恢复几分钟就搞定。反过来,虚机系统盘损坏却想用文件级恢复拼回去,那是给自己找麻烦。

4.2 Instant VM Recovery 的缓存与网络前提

即时恢复能跑起来的前提是 vPower NFS 服务正常、缓存目录有空间、ESXi 主机能挂载这个 NFS 共享。手册在安装环节就强调缓存目录至少 10 GB,原因就在这里——虚机运行时的写入全部落在这个目录,空间耗尽虚机直接挂起。

操作路径是在控制台选备份文件,右键 Instant VM Recovery,指定目标 ESXi 主机、网络和虚机名。恢复出来的虚机用的是备份数据加写缓存,性能取决于 Repository 的读带宽和 NFS 网络,不适合长期跑高 IO 业务。我的习惯是即时恢复只作为应急手段,业务起来后立刻安排 Storage vMotion 或完整恢复迁回正式存储,别让临时方案变成常态。

4.3 应用恢复与复制的回滚路径

SQL 应用恢复依赖应用感知备份,备份时 VSS 把数据库日志一并处理,恢复时才能选时间点。如果备份时没开应用感知,恢复界面里只有崩溃一致性选项,这时候别硬做应用恢复,先按文件级把 MDF/LDF 取出来再走数据库自己的恢复流程更稳。

复制(Replication)在手册第 4 章,和备份是两条线:备份是为了恢复,复制是为了切换。4.4 节把回滚分三种——故障回滚、永久故障回滚、故障排除回切。故障回滚是副本虚机临时接管,原环境修好后切回去;永久故障回滚是原环境彻底没了,副本转正;故障排除回切是排障期间用副本验证,完事再切回。这三种的差别在于副本虚机的后续处理方式,选之前先想清楚原环境还能不能救,别把临时接管做成永久切换。

5. 避坑与排查:五条从现场带回来的记录

5.1 作业显示成功但恢复点不可用

现象:作业状态 Success,进恢复向导却找不到可恢复的还原点。原因多半是 Backup Catalog 服务异常或 VBRCatalog 目录权限/空间问题,索引没写进去。解决:检查 Veeam Backup Catalog Service 是否运行,看 VBRCatalog 目录剩余空间,必要时在控制台做一次 catalog 重建,重建前确认备份文件本身完整。

5.2 部分虚机磁盘被自动跳过

现象:作业成功但 Warning,日志里提示某些磁盘未处理。原因是对应磁盘属于手册 1.2.2 列出的不支持类型——物理模式 RDM、独立磁盘、来宾 iSCSI 磁盘,或虚机带虚拟 NVDIMM、PMem 数据存储。解决:这类虚机改用基于代理的备份,或者在作业里显式排除这些磁盘并记录在案,别让 Warning 长期挂着没人管。

5.3 即时恢复虚机启动后卡死

现象:Instant VM Recovery 的虚机开机后无响应或频繁挂起。原因是 vPower NFS 缓存目录空间不足,或 ESXi 到 NFS 共享的网络不通。解决:先看缓存目录剩余空间是否低于 10 GB,再看 ESXi 主机能否挂载该 NFS 导出;空间不足时清理旧缓存或扩容,网络问题查 ESXi 的 NFS 客户端配置和防火墙。

5.4 文件级恢复搜不到文件

现象:备份成功,做 Guest File Restore 时浏览或搜索无结果。原因是备份时未安装 VMware Tools(文件级恢复依赖它),或来宾文件系统目录索引未建立。解决:确认虚机装了 VMware Tools 并在备份策略里开启来宾文件系统索引;Linux 虚机的 LVM 和 Windows 的 LDM 动态磁盘手册明确支持文件级还原,但索引建立需要额外时间,大文件系统首次索引可能较慢。

5.5 复制回切后原虚机网络异常

现象:故障排除回切后,原虚机起来但网络不通或 IP 冲突。原因是回切时副本虚机未完全关机释放资源,或网络配置在切换过程中被改。解决:回切前确认副本虚机已关机,检查 vCenter 里是否有残留的网卡绑定或 MAC 冲突;手册 4.4.3 节的回切流程建议按顺序执行,别跳步。

6. 把手册变成可复用的检查清单

这份文档的价值不在读完,在把它拆成几张能反复用的表。我自己的做法是把手册里的硬约束抽成三张清单:安装前环境核对表(虚拟化平台版本、Free ESXi 排除、不支持快照的虚机分类、三个目录的空间规划)、作业配置检查表(Proxy 传输模式、Repository 内存公式、应用感知是否开启、catalog 索引是否启用)、恢复演练表(六种恢复类型各挑一台虚机做一次,记录耗时和前置条件)。

第三张表最容易被跳过,也最该做。备份系统最大的玄学在于「备份成功不等于恢复成功」,手册 3.2 节把六种恢复方式写得很细,但没写「你该多久练一次」。我的习惯是每季度按恢复类型轮着做一次演练,Instant VM Recovery 和文件级恢复必做,SQL 应用恢复挑一个非核心库做时间点恢复验证。演练时用 PowerShell 把结果记下来,和 3.3 节那段作业状态脚本的输出放一起对比,能提前发现 catalog 索引失效、缓存目录不足这类不会让作业变红的问题。

还有一个细节:手册 2.1 节安装时指定的 VBRCatalog 目录,建议单独做备份。这个目录存的是文件级恢复的检索索引,它丢了不影响虚机恢复,但文件级恢复会退化成盲找。我一般把它纳入另一套备份策略,和 Veeam 自身的配置备份一起做,配置备份在控制台里有现成功能,别只依赖数据库的定期备份。

从那以后我每次接手新的虚拟化环境,都强制先跑一遍「备份→文件级恢复→即时恢复→回切」这条最小闭环,再谈扩容和优化。手册给的是步骤,闭环给的是信心。希望帮到你。

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

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询