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 TrackingCBT只搬运变化的数据块。整个过程不进入虚拟机内部不需要装任何代理虚拟机配置、磁盘、快照状态一次性打包。代价是对底层平台的依赖更强——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 建第一个作业把链路跑通作业配置的界面不复杂选虚拟机、选备份窗口、选保留策略、选是否开启校验。但第一次建作业我建议先只加两三台非核心虚拟机把整条链路跑通再说。跑通的标准不是作业显示成功而是这几件事都验证过备份确实产生了可用的还原点能看到时间戳和大小备份过程中虚拟机没有明显卡顿快照产生和删除都在合理时间内完成备份完成后虚拟机上没有残留快照日志里没有警告级别的条目第一轮跑完把实际耗时和估算的增量数据量记下来回头修正容量规划。这一步做了后面加机器就是复制粘贴的事不做等加到五十台的时候再发现问题改起来就是大工程。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 这个时代的环境准备的它的能力边界、界面形态、操作习惯都带着那个时期的印记。如果你的环境还在用那它是够用且稳的如果正在考虑平台演进那备份方案的迁移要提前规划——备份数据的格式、还原路径的兼容性往往是平台升级里最容易被留到最后、也最容易出问题的一环。