vSphere 5.5 Data Recovery虚拟机备份实践与还原演练

1. 先把这套备份方案的真实身份掰清楚

vSphere 5.5 时代的虚拟机备份，绕不开Data Recovery这个名字。很多人的第一反应是：装个备份软件，指定虚拟机，定个时间，跑完收工。真正上手之后才发现，它不是一个"装完就能用"的工具，而是一套以虚拟设备形态交付的、带全局去重的映像级备份系统——部署方式、容量规划、快照交互、还原路径，每一环都有它自己的脾气。这篇内容就是围绕使用 Data Recovery 备份虚拟机这件事，把我在几套 vSphere 5.5 环境里落地这套方案的全过程拆开讲：从名字的由来、容量怎么算、设备怎么部署、作业怎么建，到还原怎么演练、备份窗口为什么总跑不完、失败日志该怎么看。适合正在维护 vSphere 5.5 环境、手上有几十到上百台虚拟机、又不想为备份单独采购一套重型商业软件的朋友参考，也适合刚接触虚拟化备份、想搞明白"映像级备份到底比在虚拟机里装代理强在哪"的新手。

1.1 从 VDR 到 VDP：一个名字背后的产品沿革

先把命名这件事说清楚，否则后面查文档会一直对不上号。vSphere 早期版本里，这个组件叫vSphere Data Recovery，简称 VDR，是随 vSphere 一起提供的一个虚拟设备，负责对虚拟机做映像级备份和还原。到了 vSphere 5.x 之后，这个产品线被重新整合，交付形态变成了vSphere Data Protection，简称 VDP，底层接入了成熟的源端去重引擎，管理入口也从原来的客户端搬到了 Web Client 的插件里。

问题就在于，大量早期文档、内部交接手册、老同事的口头习惯都还停留在 "Data Recovery" 这个叫法上。你在 5.5 环境里翻菜单，找到的是 VDP；你在旧手册里看到的是 Data Recovery；两者指的其实是同一条产品线的不同阶段。这不是两个可以并存的组件，同一个 vCenter 上装两套只会互相打架。

提示：如果你接手的环境里，前辈留下的文档写着"用 Data Recovery 备份"，而你在 Web Client 里只看到 VDP 的图标，不用怀疑自己找错了地方，这就是同一个东西换了名字。确认版本的办法是看设备虚拟机的名称和 Web Client 里插件的版本号，而不是看文档标题。

理解这一点之后，很多看似矛盾的描述就对上了：老资料里说"备份存储上限 1TB"，新资料里说"最大 8TB"，说的是不同版本、不同授权级别的能力边界，不是文档写错了。

1.2 它和在虚拟机里装备份代理，到底差在哪

这是选型时最该想明白的一件事。传统做法是在每台虚拟机里装一个备份代理，由备份服务器远程调度，代理读取文件系统，把数据搬到备份介质上。这套逻辑在物理机时代很成熟，搬到虚拟化环境里就露出了三个硬伤。

第一是资源开销的重复计算。代理跑在虚拟机内部，占的是这台虚拟机的 CPU 和内存，备份一跑，业务虚拟机的性能就被拖下来了；而且每台虚拟机都要装、都要升级、都要单独配策略，虚拟机数量一上去，运维成本是线性增长的。

第二是无法处理"整机"这个概念。代理只能看到文件系统里的文件，看不到虚拟磁盘、看不到虚拟机配置、看不到快照链。要恢复一台彻底崩掉的虚拟机，得先重建虚拟机、再装系统、再装代理、再往回倒数据，中间任何一步出错都得从头来。

第三是备份窗口被业务绑死。代理备份要靠业务系统自己配合，数据库要停、应用要静默，窗口一旦被业务挤占，备份就只能往后拖。

映像级备份走的是另一条路：直接通过 ESXi 的存储接口读取虚拟磁盘文件，配合Changed Block Tracking（CBT）只搬运变化的数据块。整个过程不进入虚拟机内部，不需要装任何代理，虚拟机配置、磁盘、快照状态一次性打包。代价是对底层平台的依赖更强——CBT 没打开、虚拟机版本太低、磁盘类型不支持，备份就会失败或者退化成全量。

我一般会这样跟人解释：代理备份像是挨家挨户敲门进去抄账本，映像级备份是直接在外面把整栋楼的图纸和仓库一起复制一份。前者精细但慢且扰民，后者粗放但快且不打扰。

1.3 适用边界：哪些虚拟机它管不了

任何备份方案都有覆盖不到的死角，提前知道比事后踩坑强。整理成一张表，部署前先对照排查一遍。

场景	是否支持	说明与处理建议
普通虚拟磁盘虚拟机	支持	主流场景，CBT 打开即可走增量
物理兼容模式的 RDM 磁盘	不支持	需要改回虚拟模式，或单独用其他手段保护
虚拟机快照模式下的独立磁盘	不支持	独立磁盘不参与快照，映像级备份拿不到一致状态
启用了 Fault Tolerance 的虚拟机	不支持	需先关闭 FT 再备份，或者接受这台机器不在保护范围内
虚拟机硬件版本过低	受限	CBT 需要较高的硬件版本，老虚拟机要先升级再纳入保护
备份设备自身	不应纳入	自己备自己会形成循环，直接在策略里排除
跨 vCenter 集中管理	不支持	一个备份设备只服务一个 vCenter，多中心要分别部署

这张表里最容易被忽略的是 RDM 和 FT 两条。前者常见于跑数据库的老虚拟机，当初为了性能直通了裸设备，结果备份方案一上就发现保护不了；后者常见于对可用性要求极高的核心业务，恰恰是最需要备份的那批机器。部署前一定要把这两类虚拟机筛出来，单独定方案，别等备份报表上出现一片红色才发现。

2. 规划阶段：容量、网络、许可，三件事定生死

部署这套东西，最怕的是拿着默认参数一路下一步，装完了发现容量不够、网络不通、或者虚拟机数量超了授权上限。规划阶段花两小时，能省掉后面两周的返工。

2.1 容量估算：完整算式和一次实算

去重备份的容量估算，和传统全量+增量的算法完全不是一回事，因为它存的不是"第几份备份"，而是"去重后的唯一数据块"。所以不能简单拿"备份数据量 × 保留份数"去套。

我用的算式是这样的：

首备占用 = 需保护数据实际使用量 ÷ 去重率 增量占用 = 需保护数据实际使用量 × 周变化率 ÷ 去重率 × 保留周期数 总占用 = 首备占用 + 增量占用 + 安全余量（建议 30%）

去重率是这里面最不确定的变量。它取决于数据本身的重复程度：同一套模板批量克隆出来的虚拟机、操作系统文件、重复的日志和归档，去重效果会非常好；而已经压缩加密过的数据、视频素材、随机性强的数据库文件，去重率可能接近 1:1。经验上，混合业务环境按2:1 到 3:1估比较稳妥，全是同构模板机的环境可以按 5:1 到 8:1，拿不准就按 2:1 保守估。

举个实算的例子。某环境需要保护 60 台虚拟机，配置容量加起来 20TB，实际使用量 8TB，业务侧反馈每周数据变化率大约 5%，保留策略是"周备保留 4 份 + 月备保留 6 份"。

• 首备占用：8TB ÷ 3 ≈ 2.7TB
• 每周增量：8TB × 5% ÷ 3 ≈ 133GB
• 增量累计：133GB × (4 + 6) ≈ 1.3TB
• 小计：约 4TB
• 加 30% 安全余量：约 5.2TB

对照可选配置档位，只能选8TB那一档，4TB 会很快写满。如果预算卡死只能上 4TB，那就得动保留策略——把月备砍到 3 份，或者把非核心业务排除出保护范围。

注意：这个算式里最容易被低估的是"变化率"。业务方说的 5% 往往是日常业务数据的变化，实际跑起来，操作系统补丁、日志滚动、临时文件、数据库重整都会把变化率推高。第一周跑完，务必拿实际的增量数据量回头校验一次估算，偏差超过 50% 就要重新规划容量或调整策略。

还有一点：去重是全局的，但清理是延迟的。删掉一份备份，占用的空间不会立刻释放，要等垃圾回收跑完。所以容量规划不能踩着上限走，留 20% 到 30% 的余量，是给垃圾回收留的操作空间。

2.2 网络与存储的选型考量

备份流量走哪张网卡，直接决定业务会不会被拖慢。默认情况下，备份设备的流量和虚拟机业务流量挤在同一套虚拟交换机上，一次全备跑起来，几台主机的上行链路瞬间打满，业务侧的延迟肉眼可见地上升。

稳妥的做法是给备份单独规划一套网络：在每台 ESXi 主机上增加一个 VMkernel 接口，专门承载备份流量，备份设备也接到这个端口组上。这样备份数据走独立链路，业务网不受影响。如果主机上行带宽有限，独立网络还能配合流量整形做限速，虽然配置麻烦一点，但比事后被业务方投诉强。

存储这一侧要考虑的是备份数据放在哪。备份设备本身是一个虚拟机，它的数据盘可以放在三种位置：主机本地存储、共享数据存储、或者外部 CIFS 共享。三者的取舍很明确——放本地存储性能最好但没法做设备级的高可用，主机一挂备份数据跟着没了；放共享存储在主机故障时可以把设备迁走继续用，代价是要吃掉共享存储的容量和 IO；放 CIFS 共享适合容量需求大、对备份速度不敏感的场景，但网络抖动会直接反映成备份失败。

我自己的习惯是：备份设备放共享存储，数据盘也放共享存储，容量规划按前面算出来的结果走，同时把这个数据存储的 IO 压力纳入监控，别让备份把生产存储的 IOPS 吃光。

2.3 许可与规模上限对照

这一条特别容易被忽略，部署完了跑着跑着突然发现加不进新的虚拟机，一查才知道超了上限。规模上限主要看两件事：受保护虚拟机的数量和可用的存储容量档位。

项目	基础版本	增强版本	落地建议
单设备保护虚拟机上限	约 100 台	约 400 台	超过 80 台就该考虑分设备部署
备份存储容量档位	0.5 / 1 / 2 TB	最高到 8 TB	按前面算式选，别踩上限
单虚拟机可保护磁盘规模	有上限	更高	超大磁盘虚拟机单独评估
设备级联与多设备管理	不支持	支持	虚拟机数量多时按业务域拆分

超过 80 台就该分设备的理由不只是授权，还有备份窗口。一台设备并发处理能力有限，虚拟机数量越多，单个窗口内跑完的概率越低，最后只能拉长窗口，结果和业务高峰撞车。按业务域拆成两三台设备，每台各自管一片，窗口压力会小很多。

3. 部署与初始化：从导入设备到第一次备份跑通

这一段是纯实操，我把每一步的关键参数和背后的原因都写清楚，照着做基本不会跑偏。

3.1 部署向导里最容易填错的几个参数

备份设备以虚拟设备的形式交付，导入过程本身不复杂，但有几个参数一旦填错，后面要么连不上，要么时间对不上导致认证失败。

第一是主机名和 IP。这里填的是设备自己的标识，一旦确定就尽量别改，改了要重新注册插件，之前的备份作业配置可能失效。建议用带业务含义的命名，比如按"备份-机房-序号"的规则，别用默认名字，多个环境并存时根本分不清谁是谁。

第二是 NTP 时间源。这是最容易被跳过、也最容易出事的一项。备份设备、vCenter、ESXi 主机三者的时间必须同步，偏差超过几分钟，设备注册和作业调度就会出问题，日志里报的错还特别含糊。部署时就把 NTP 配上，别等出问题再回头查。

第三是 root 密码。设置之后要立刻存进密码管理工具。这个密码后面做设备级维护、看底层日志、跑应急还原都要用，忘了只能重装。

第四是存储容量档位。部署时选的档位决定了数据盘的大小，后面想扩容非常麻烦，基本等于重来。所以这个参数一定要在规划阶段就定死，别用默认值蒙混过关。

第五是 vCenter 的注册信息。设备需要向 vCenter 注册才能被 Web Client 识别，注册用的账号需要有足够权限。这里建议用一个专用的服务账号，别用管理员个人账号，人一离职权限一改，备份就断了。

提示：部署完成后，设备的第一次启动会比较慢，因为要初始化数据盘和内部服务。这个阶段别急着登录 Web Client 找插件，等设备控制台显示出服务就绪的提示再动手，否则会看到插件加载失败，白折腾一轮。

3.2 注册插件与首次登录的门槛

设备起来之后，管理入口在 Web Client 里。第一次打开会经过一个初始配置向导，要确认几件事：许可、存储位置、以及是否立即创建备份作业。

这里有个常见的卡点：插件加载不出来。原因通常有三种——设备还没完全初始化完、浏览器缓存了旧版本插件、或者设备与 vCenter 之间的证书信任没建立。排查顺序建议是：先在设备控制台确认服务状态，再换一个干净的浏览器会话试，最后检查设备与 vCenter 的时间是否一致。绝大多数情况是时间偏差导致的信任失败，而不是真的坏了。

首次登录后，建议先把邮件告警配好。备份这东西最怕"默默失败"——没人看的备份报表等于没有报表。把告警发到一个团队共用的邮件组，作业失败、容量超阈值、设备异常都往里发，这样至少有人会在第二天早上看到。

3.3 配置备份存储与保留策略

存储配置这一步，向导会让你选择数据存放的位置。前面规划阶段已经定了放共享存储，这里就是把对应的数据存储指过去。指完之后，系统会做一次容量校验，显示的可用容量会略小于数据存储的实际容量，这是正常的，要给元数据和垃圾回收留空间。

保留策略的配置是这一步的核心。常见的配置项包括：保留多少份周备份、保留多少份月备份、单份备份的最长保留天数。配置逻辑不是"越多越安全"，而是"够用且能跑完"。

我一般的做法是：核心业务保留 4 份周备加 6 份月备，覆盖一个季度；非核心业务保留 2 份周备加 3 份月备；测试和临时环境直接排除，或者只保留 1 份。这样算下来，总容量需求能压下去一大截，备份窗口也宽松很多。

3.4 建第一个作业，把链路跑通

作业配置的界面不复杂：选虚拟机、选备份窗口、选保留策略、选是否开启校验。但第一次建作业，我建议先只加两三台非核心虚拟机，把整条链路跑通再说。

跑通的标准不是"作业显示成功"，而是这几件事都验证过：

1. 备份确实产生了可用的还原点，能看到时间戳和大小
2. 备份过程中虚拟机没有明显卡顿，快照产生和删除都在合理时间内完成
3. 备份完成后，虚拟机上没有残留快照
4. 日志里没有警告级别的条目

第一轮跑完，把实际耗时和估算的增量数据量记下来，回头修正容量规划。这一步做了，后面加机器就是复制粘贴的事；不做，等加到五十台的时候再发现问题，改起来就是大工程。

4. 还原演练：备份不做还原验证等于没备份

这是我在这件事上最坚持的一点。备份成功率是系统自己报的，还原成功率才是真的。见过太多环境，备份报表一片绿，真出事的时候发现还原不回去，原因五花八门：虚拟机硬件版本变了、目标主机存储不够、网络配置冲突、备份文件本身损坏。

4.1 整机还原：完整流程与关键决策点

整机还原的流程大致是这样：在还原界面选中还原点，选择还原到原位置还是新位置，确认目标主机和存储，启动还原。

关键决策点有三个。

第一，还原到原位置还是新位置。原位置还原会覆盖现有虚拟机，适合确认虚拟机已经彻底报废的场景；新位置还原会新建一台虚拟机，适合先验证备份可用性、或者需要并行比对的场景。做演练一律用新位置，别拿生产虚拟机赌。

第二，目标主机的资源够不够。还原过程本质上是把备份的磁盘文件写回数据存储，需要的空间等于虚拟机配置的磁盘容量，不是实际使用量。一台配置了 1TB 磁盘、实际只用了 200GB 的虚拟机，还原时也要 1TB 的空间。这个细节不搞清楚，还原到一半空间不足失败，白等几小时。

第三，还原后的网络配置。新位置还原出来的虚拟机，网卡可能是断开状态，或者 MAC 地址冲突。还原完成后要手动检查网络配置，别急着开机接业务。

还原时间的粗略估算：主要瓶颈在存储写入速度，共享存储环境下，1TB 的虚拟机还原大概在几十分钟到一两小时量级，具体取决于存储负载。规划恢复时间目标的时候，这个数字要算进去。

4.2 文件级还原：不必为了一个文件回滚整机

这是这套方案里我觉得最实用的功能。业务方说"昨天下午的某个文档被误删了"，你不可能为了一个文件把整台虚拟机回滚到昨天，那样丢掉的是今天所有的业务数据。

文件级还原的思路是：把备份里的虚拟磁盘挂载出来，通过客户端工具浏览里面的文件系统，找到需要的文件，单独取出来。整个过程中原虚拟机保持运行，不受影响。

操作上要注意两点。一是挂载需要临时空间和时间，磁盘越大挂载越慢，别在业务高峰期做。二是文件系统兼容性，挂载出来的是磁盘镜像，客户端要能识别里面的文件系统类型，太老或者太特殊的文件系统可能读不出来，这种情况只能退回整机还原再手工拷文件。

注意：文件级还原取出来的文件，权限和属主信息可能丢失，特别是跨系统取文件的时候。取回后要手动核对权限，别直接扔回生产目录覆盖。

4.3 演练必须验证的三件事

演练不是点一下还原然后看着进度条走完就完事。至少验证这三件事，才算真的验证过。

一是还原出来的虚拟机能不能正常启动。有些备份在文件层面是完整的，但引导记录、分区表出了问题，还原出来开不了机。这一条只能靠实际开机验证，没有捷径。

二是业务数据的一致性。挑几个关键时间点的数据核对，比如数据库的某个表、文件的修改时间、日志的最后一条记录。映像级备份如果不配合应用静默，拿到的可能是崩溃一致状态，数据库需要做恢复检查。

三是还原耗时是否在可接受范围内。把实际耗时记下来，和业务方约定的恢复时间目标对一遍。对不上，就要考虑调整策略——比如把核心业务的备份频率提高，或者对超大虚拟机做磁盘拆分。

演练频率建议至少每季度一次，每次挑不同的虚拟机，覆盖不同的操作系统和业务类型。只演练同一台机器，等于只验证了一条路径。

5. 调度与运维：让备份窗口真正跑得动

备份跑不完，是这套方案落地后最常见的抱怨。原因往往不在备份本身，而在调度策略和虚拟机的状态管理上。

5.1 快照叠加：备份窗口被拖长的头号元凶

映像级备份在开始时会为虚拟机创建一个临时快照，备份完成后删除。如果这台虚拟机本身已经存在快照，那么备份产生的快照会叠加在原有快照链上，形成一条更长的链。链越长，读写性能越差，备份耗时越长，删除快照时的合并操作也越慢。

更糟的情况是：原有快照存在了很久，磁盘上积累了大量变化数据，备份读盘的时候要穿透整条链，速度可能降到正常水平的几分之一。

处理办法很直接：备份前清理存量快照。可以在备份作业里配置"快照数量超过阈值时告警"，也可以定期跑一次巡检，把超过设定天数的快照列出来人工确认。有些环境图省事，长期挂着快照当"备份"用，这是最危险的做法——快照不是备份，它和原磁盘在同一个存储上，存储一坏全没。

还有一个细节：备份窗口要避开快照合并的高峰。如果多台虚拟机的备份作业在同一时刻结束，会同时触发快照删除和磁盘合并，存储 IO 瞬间打满，业务侧立刻有感知。把作业的启动时间错开十几分钟，压力会平缓很多。

5.2 去重窗口与垃圾回收的节奏

去重存储不是写进去就完事，它有自己的维护周期。系统会定期做垃圾回收，把已经失效的数据块清理掉，释放空间。这个过程很吃 IO，如果在业务高峰期跑，会明显拖慢备份和还原。

配置上要注意两点：把垃圾回收安排在业务低谷，通常是凌晨到清晨之间；不要让它和备份窗口重叠，两者抢 IO 的结果是两边都慢。如果环境里备份作业本身就排在凌晨，那就把回收往后挪，或者接受回收周期拉长。

容量监控也要跟上。当使用率超过 80%，回收的效率会明显下降，因为可回收的空间碎片化严重。使用率到 75% 就该考虑扩容或者调整保留策略了，别等到 95% 才开始慌。

5.3 监控指标与告警阈值

备份系统的监控不能只看"成功/失败"，有几个指标要盯住。

监控项	建议阈值	超阈值后的动作
备份作业成功率	连续 2 次失败即告警	查日志、查虚拟机状态、查存储容量
单作业耗时	超过历史均值 50%	排查快照链、存储 IO、网络带宽
存储使用率	75% 预警 / 85% 紧急	调整保留策略或扩容
垃圾回收状态	超过预期周期未完成	检查 IO 压力，考虑调整时间窗
设备自身资源占用	CPU 持续高于 80%	检查并发作业数，考虑拆分设备

这套指标配下来，大部分问题能在影响业务之前被发现。我个人最看重的是"单作业耗时"这一项，它是所有问题的先行指标——快照链变长、存储变慢、网络拥塞，都会先在耗时上体现出来。

6. 常见问题速查与踩坑记录

这一段是纯经验沉淀，把实际遇到过的问题按现象归类，附上排查思路。表格可以当速查卡用，后面的展开说明是给需要深挖的场景。

6.1 备份失败类问题

现象	可能原因	排查与处理
作业报"无法创建快照"	虚拟机已有过多快照、存储空间不足	清理存量快照，检查数据存储剩余空间
作业报"变更块跟踪不可用"	CBT 未启用、虚拟机硬件版本过低	关机后检查 CBT 配置，必要时升级硬件版本
备份到一半中断	网络抖动、备份设备资源耗尽	查设备控制台日志，看并发数和内存占用
特定虚拟机反复失败	磁盘类型不支持、存在独立磁盘	检查磁盘模式，必要时改配置或排除该磁盘
全部作业同时失败	设备与 vCenter 失联、时间不同步	检查设备网络、NTP 状态、服务账号权限

关于 CBT 这一条要多说两句。CBT 是增量的基础，它记录虚拟磁盘哪些块发生了变化。这个功能在虚拟机层面有开关，某些情况下会被重置——比如虚拟机做过存储迁移、快照被异常删除、或者主机异常重启。CBT 一旦失效，下一次备份会退化成全量，表现为作业耗时突然翻几倍。所以看到某台机器的备份时间突然变长，先查 CBT 状态，别急着怀疑存储。

6.2 还原与挂载类问题

还原失败的原因，八成集中在资源和配置上，而不是备份文件本身。

现象	可能原因	排查与处理
还原时报空间不足	目标存储容量小于磁盘配置容量	换更大存储，或先精简磁盘配置
还原出来开不了机	引导信息损坏、硬件版本不兼容	检查备份时间点，尝试其他还原点
文件级挂载失败	文件系统不被识别、挂载超时	换客户端版本，避开业务高峰重试
还原后网络不通	网卡未连接、MAC 冲突、端口组变更	手动检查网卡状态和端口组配置
还原速度极慢	存储 IO 饱和、垃圾回收同时运行	错开时间，检查存储侧负载

"还原时报空间不足"这条特别值得展开。很多人以为还原只需要实际使用量的空间，实际上系统要按磁盘的配置容量去分配。想规避这个坑，平时就要控制虚拟机的磁盘超额配置——给一台只需要 200GB 的虚拟机配 2TB 磁盘，看着方便，真到还原的时候就是灾难。精简配置省的是平时的空间，还原的时候一分都省不了。

6.3 空间与性能类问题

现象	可能原因	排查与处理
存储使用率只涨不降	垃圾回收未跑或效率低	检查回收计划，确认没有长期失败
去重率远低于预期	数据类型不适合去重（已压缩、加密）	调整预期，考虑排除这类数据
备份设备 CPU 长期高位	并发作业数过多	减少并发，或按业务域拆分设备
备份期间业务明显变慢	备份流量与业务共用链路	规划独立备份网络，配置限速
设备磁盘 IO 等待高	数据盘所在存储负载过高	迁移数据盘，或错开备份窗口

去重率低这件事，值得单独说一句。有些环境一开始对去重期望很高，觉得"备份数据能压到几分之一"，结果跑下来发现只有 1.5:1，容量一下就紧张了。原因通常是受保护的数据本身重复度低——已经压缩过的归档、加密的业务数据、多媒体素材，这类数据去重引擎基本无能为力。规划阶段就要把这类数据识别出来，要么单独规划容量，要么干脆不纳入保护范围。

7. 我个人在这套方案上的一些体会

折腾过几套环境之后，最大的感受是：这套方案的价值不在于功能有多花哨，而在于它把"虚拟机备份"这件事的复杂度压到了一个可维护的水平。不用在每台机器上装代理，不用为不同的操作系统准备不同的客户端，一个设备管一片虚拟机，策略配一次就完事。这种"统一入口"的体验，在虚拟机数量上去之后优势特别明显。

但它也确实有脾气。最需要花心思的不是部署，而是容量规划、快照治理和还原演练这三件事。容量算错了，跑几个月就得推倒重来；快照不治理，备份窗口会越拖越长直到跑不完；还原不演练，备份做得再漂亮也是纸面功夫。

还有一个我踩过的坑分享出来：早期为了图省事，把备份作业的启动时间全设成整点，结果几十台机器同时起跑，存储 IO 瞬间打满，作业互相拖累，全都超时失败。后来改成按业务分组、错开十几分钟启动，同样的窗口能跑完的机器数量翻了一倍。调度上的小技巧，往往比换硬件更有效。

最后提一句容易忽略的：这套东西是给 vSphere 5.5 这个时代的环境准备的，它的能力边界、界面形态、操作习惯都带着那个时期的印记。如果你的环境还在用，那它是够用且稳的；如果正在考虑平台演进，那备份方案的迁移要提前规划——备份数据的格式、还原路径的兼容性，往往是平台升级里最容易被留到最后、也最容易出问题的一环。