vSphere 5.5 Data Recovery 虚拟机备份与恢复实战

虚拟化运维干到一定年头，最怕的并不是集群起不来，而是某天早上有人拍着你肩膀问：昨天下午那台跑核心业务的虚拟机，能不能回退到误删文件之前的状态？我在维护老版本 vSphere 环境时就撞上过这种场面，当时手上唯一能立刻用起来的工具，就是 vSphere 自带的那套 Data Recovery。它的定位很朴素——用一台虚拟设备，把别的虚拟机按计划备份下来，需要的时候整机还原或者只捞几个文件出来。这篇文章面向的是还在维护 vSphere 5.5 及更早环境的人，尤其是预算有限、没有采购第三方备份产品、又确实需要一份能落地的备份方案的朋友。下面我把自己从导入设备、挂载备份存储、建作业、跑恢复，到踩过的那些坑，完整摊开讲一遍，参数怎么算、步骤为什么这么排，都交代清楚。

1. 先把名字理清楚：vSphere 5.5 里的 Data Recovery 到底指什么

1.1 三个容易混淆的东西

刚接触这一块的人很容易被几个名词绕晕，我自己当年就查了半天文档才对上号。VMware Data Recovery（圈内常简称 VDR）是随 vSphere 4.x 时代一起推出来的备份虚拟设备，本质是一个打包好的、基于 Linux 的虚拟机，导入之后通过它去调度其他虚拟机的快照和磁盘数据。到了 vSphere 5.1 之后，官方主推的换成了另一个基于去重引擎的备份组件，功能更现代，界面也不一样。所以严格意义上讲，在 vSphere 5.5 这个版本里，Data Recovery 已经属于上一代产品，官方文档的重心早就转移了。

这个背景必须先在脑子里摆正，否则后面会遇到一堆"文档对不上"的困惑。我在实际环境里见到的情形是：有些老机房从 4.x 一路升级上来，Data Recovery 设备一直挂在集群里没动，作业也一直在跑，就这么用着；还有些环境是因为备份软件的授权没覆盖到某些边缘虚拟机，于是拿 Data Recovery 顶上去做个兜底。这两种场景下，它都还有存在价值。

一句话概括它的能力边界：能按计划对虚拟机做全量加增量的镜像级备份，能整机恢复，也能挂载备份把单个文件抠出来，但它不是企业级备份系统，没有磁带归档、没有异地复制、没有复杂的保留策略分层。搞清楚这一点，你就不会对它抱有不切实际的期待。

1.2 为什么老环境里它还在服役

我梳理下来，愿意继续用它的人基本是三个理由。第一是零额外成本，它属于 vSphere 授权体系内可用的组件，不需要再签一份备份软件的合同，对预算卡得很死的项目来说这是硬优势。第二是部署门槛低，一个 OVF 导入、配个 IP、连上 vCenter，半小时内就能跑出第一份备份，不需要装 Agent，也不需要在每台虚拟机上折腾。第三是恢复路径短，整机恢复直接在 vSphere 客户端里点几下，不用去翻磁带、不用去找介质服务器。

反过来说，它的短板也很明显：备份数据只能落在虚拟磁盘或者网络共享上，没有离线介质；去重和压缩能力远不如后来的产品；并发能力有限，虚拟机一多，备份窗口就绷得很紧。所以我的判断标准很简单——虚拟机规模在几十台以内、RPO 允许一天一次、没有异地容灾要求的环境，它够用；超过这个量级，还是老老实实上专业备份产品。

1.3 上手之前必须接受的几个硬限制

在动手之前，有几条限制你得先认，不然做到一半会很别扭。

注意：具体版本的上限数字，一定要以你手上那个版本的发布说明为准，别照抄网上任何一篇教程的数字。我见过因为照着旧帖子配参数，结果作业跑到一半设备直接卡死的案例，原因就是超了并发上限。

2. 机制拆解：它到底靠什么把虚拟机数据搬走

2.1 一台虚拟设备加一个备份存储位置

Data Recovery 的架构其实非常直白，就两块东西：一台负责调度的虚拟设备，和一个用来堆数据的备份存储位置。虚拟设备本身不存业务数据，它更像一个工头，负责按时间表去通知 vCenter 给某台虚拟机打快照、读数据、传回来、写进存储位置、然后把快照删掉。这个分工带来的好处是设备本身的磁盘可以很小，扩容压力全在备份存储那一侧。

备份存储位置有两种形态，我强烈建议用虚拟磁盘那种。做法是在设备上挂一块新的大容量 VMDK，格式化成它自己的存储格式。这样做的好处是数据走的是 ESXi 主机内部的存储链路，不经过网络，速度和稳定性都更好。另一种 CIFS 共享适合数据量不大、又想让备份落在独立存储上的场景，但要提前评估网络带宽和共享端的并发写入能力。

这里有个容易被忽略的细节：备份存储位置一旦创建，后续想扩容就很麻烦，不像加一块盘那么简单。所以我在部署阶段就会把容量一次算足，宁可多留三成余量，也不想半年后为了加空间重建整个备份仓库。

2.2 全量、增量与 CBT 的配合逻辑

第一次备份必然是全量，这个没得商量——设备需要一份完整的基线。之后的备份走增量，靠的是虚拟机磁盘的变更块追踪能力。原理不复杂：ESXi 会在虚拟磁盘旁边维护一份位图，记录哪些块自上次快照以来被改写过，备份时只读那些被标记的块，剩下的直接跳过。用生活化的比喻，全量备份是把整本书复印一遍，增量备份是只复印你改过的那几页。

但这个机制有个前提条件，必须在动手前处理掉：变更块追踪不是默认开启的，需要在虚拟机的配置参数里把对应开关打开。更关键的是，这个参数改完之后不会立刻生效，需要让虚拟机经历一次"重新配置"的动作，通常是关机再开机，或者做一次快照再删除快照。我见过不止一次"备份跑得挺顺但每次都是全量"的情况，一查就是这一步漏了，增量根本没跑起来，白白吃掉几倍的存储和窗口时间。

提示：批量开启这个参数可以在关机维护窗口里一次性做完，改完参数后再统一开机。别在业务高峰期一台台改，改一台重启一台，风险太分散。

除了变更块追踪，还有一个静默选项值得说。开启静默之后，备份前会通过虚拟机里的工具去通知操作系统把内存里的数据刷到磁盘上，Windows 侧走的是卷影复制机制，Linux 侧则需要自己准备一个刷盘脚本。对普通文件服务器，开不开差别不大；对数据库、邮件这类有事务日志的应用，不开静默就有可能出现备份里的数据处于"写到一半"的状态，恢复起来要额外做一致性检查。这个坑我在早期项目里踩过一次，恢复出来的数据库起不来，最后靠日志回放才勉强救回，从那以后涉及数据库的虚拟机我一律开静默。

2.3 保留策略背后的空间账怎么算

这是最容易被拍脑袋决定、又最容易翻车的部分。大部分人的做法是"保留 7 份，先跑起来再说"，结果一个月后存储告警。我建议在创建作业之前，拿张纸把账算清楚。

计算公式可以这样拆：单台虚拟机的有效数据量（不是置备大小，是实际占用），乘以去重压缩后的折算系数，得到一份全量的实际占用；每日增量按有效数据量乘以日变更率估算；再用全量加上增量乘以保留天数，最后加上一成半的校验与临时空间余量。

举个具体的例子。假设某台虚拟机置备 200GB，实际使用 100GB，日变更率按 5% 估，去重压缩折算系数按 0.5 算（这个系数跟数据重复度关系极大，文本类数据能压很多，已经是压缩格式的媒体文件几乎压不动）。

• 全量折算：100GB × 0.5 = 50GB
• 每日增量：100GB × 5% = 5GB，折算后 2.5GB
• 保留 7 天：50GB + 2.5GB × 6 = 65GB
• 加 15% 余量：约 75GB

那么十台同等规模的虚拟机，备份存储位置至少要准备 750GB 以上，我实际会按 1TB 去规划。这个数字和"十台乘以 200GB 置备等于 2TB"的直觉差距很大，原因就在于增量加去重的组合效应。但反过来说，如果你的数据全是视频素材这类压不动的内容，折算系数要往 0.9 甚至 1.0 去靠，余量也要留得更足。

还有一点，保留份数和恢复能力不是线性关系。保留 7 份意味着你只能回到最近 7 天的状态，如果某个文件是 10 天前被误删的，那就没救了。所以作业设计时我会至少配两个作业：一个每日增量、保留 7 份，用来应付近期误操作；另一个每周全量、保留 4 份，用来覆盖一个月的回看窗口。两个作业指向同一个备份存储位置，靠设备自己去重，实际占用不会翻倍。

3. 部署实操：从导入设备到第一个作业跑起来

3.1 部署前的环境体检清单

我习惯在动手前过一遍清单，能省掉后面一半的返工。这几项如果有一项不满足，后面就会卡住。

• vCenter 的版本和凭据是否可用。设备需要以一个具备足够权限的账号接入 vCenter，至少要能对虚拟机做快照、读虚拟磁盘、改配置。别用个人账号，建一个专用的服务账号，密码写进密码管理工具。
• 集群里是否有足够的资源余量。备份过程中每台被备虚拟机都会短暂产生一个快照，快照的增量盘会落在虚拟机所在的存储上，如果那台数据存储本来就快满了，快照一涨就可能把存储撑爆，虚拟机会直接挂起。
• 数据存储的剩余空间是否够用。规则很简单：单台虚拟机在备份期间占用的临时空间，大致等于备份窗口内它产生的变更量。对一个变更很猛的业务库，这个量可能到几十 GB。我的习惯是至少留出单台虚拟机实际占用 20% 的空间。
• 网络规划。设备需要管理地址，如果是 CIFS 模式还要考虑数据网络。用虚拟磁盘模式的话，数据不经过网络，这一点可以省心。
• 备份窗口。算一下每台虚拟机的传输速率，估个总时间。以单台 100GB 有效数据、传输速率 40MB/s 估，大约是 40 分钟左右；十台串行就是七个小时，显然超窗口，那就得靠调整并发数来压时间。

我踩过最惨的一次是没检查数据存储余量，备份跑了两个小时，把一台虚拟机的快照撑到 80GB，所在存储告警，管理员半夜被叫起来扩容。从那以后这条成了我的第一检查项。

3.2 导入虚拟设备并完成初始化

部署动作本身很简单，从客户端里选部署 OVF 模板，指向设备文件，选目标集群和数据存储，走完向导就行。但有几个地方需要手动干预。

资源规格方面，向导默认给的配置偏保守，跑几台虚拟机没问题，虚拟机一多就会成为瓶颈。我的习惯是给到 4 个虚拟 CPU、4GB 到 8GB 内存，具体看备份的虚拟机数量。系统盘给 60GB 以上，因为设备的日志和临时文件会随时间增长，盘太小会莫名其妙地出问题。

导入完成后不要急着开机，先检查两件事：一是虚拟网卡是否连到了正确的端口组，二是虚拟机的磁盘控制器类型是否与目标环境匹配。我遇到过一次导入后开机找不到系统盘的情况，就是控制器类型在导入时被改了。

开机之后通过控制台进去做初始化，主要是配 IP、网关、DNS、时区，然后设置一个管理密码。这一步没什么技巧，但密码一定要记下来，设备的管理界面和命令行都靠它，丢了只能重装。初始化完成后用浏览器访问设备的管理地址，能看到登录页就说明基本就绪了。

3.3 挂载备份存储与接入 vCenter

这一步是整个部署里最关键的一环，顺序不能错。先在设备上配置备份存储位置，再接入 vCenter。原因在于，如果先接 vCenter 但没配存储，作业创建时会因为找不到可用目标而报错，虽然能改，但来回折腾。

配虚拟磁盘形式的备份存储位置，做法是先在 vSphere 客户端里给设备虚拟机加一块新磁盘，类型选厚置备、容量按前面算好的数字给，然后回到设备管理界面执行添加操作，选择那块新盘，设备会自己做格式化和初始化。整个过程可能要十几分钟，取决于磁盘大小，别以为卡死了就强制刷新。

接入 vCenter 时，填地址和专用账号，然后等设备去发现。发现成功的标志是能在设备里看到虚拟机的清单。如果发现失败，八成是以下三个原因之一：地址解析不通、账号权限不足、或者 vCenter 的证书是非信任的。第三种情况在老环境里特别常见，因为很多环境用的是自签名证书。这时候需要先把 vCenter 的根证书导入到设备里，设备的管理界面上一般有相关选项。

注意：权限这件事不要图省事给管理员全权，按最小权限建个角色就行，能快照、能读盘、能改虚拟机配置，这三样够了。多给的权限，早晚会出问题。

3.4 建第一个作业：排程与时点设计

作业的配置界面不复杂，要填的就这么几项，但每一项背后都有讲究。

作业名要起得有业务含义，别用默认的编号。半年后你回头看一堆作业，根本分不清哪个是核心业务、哪个是测试环境。我一般按"业务域-环境-频率"的格式命名。

选择虚拟机时不要一次全选。我建议第一批只挑三到五台，跑一周看看表现，尤其是看每台虚拟机在备份窗口内的快照增长情况，掌握了实际数据量之后再扩大范围。一次性把几十台挂上去，出了问题很难定位是哪台带的。

排程的时点设计有一条铁律：错开业务高峰，也错开其他备份作业。我见过把所有作业都排在凌晨两点的配置，结果是所有虚拟机同时开始打快照，存储 IO 瞬间拉满，业务监控直接告警。合理的做法是分批次错开，比如核心业务排一点、一般业务排两点、测试环境排四点，每批之间留出足够的间隔。

保留份数按前面的空间账来定。开启完整性校验要勾上，代价是每次备份完成后会多花一些时间去比对数据块，收益是能及早发现备份集损坏。我一般把校验安排在周末，因为工作日跑校验会拖慢整个作业链。

并发数是个需要反复调的参数。默认值偏保守，调高能压缩窗口，但调太高会让设备成为瓶颈，反而更慢。我的经验是从默认值加一倍开始试，观察设备 CPU 使用率和备份传输速率，如果 CPU 打到 80% 以上但传输速率没提升，就说明到瓶颈了，往下调一档。

3.5 备份跑完之后必须做的三件事

很多人觉得作业显示成功就结束了，我不这么看。至少有三种情况，界面显示成功但实际不可用。

第一件是检查虚拟机上有没有残留快照。备份过程中创建的快照，正常情况下会自己删掉，但如果删除时正好碰上存储抖动或者虚拟机繁忙，就可能留下一个。残留快照的危害在于，它是增量盘，虚机会越跑越慢，存储占用会越来越大，而且时间越长越难合并。核查方法是直接看虚拟机的快照管理界面，应该显示没有快照。

第二件是看备份存储位置的容量趋势，而不是只看当前值。连续记一周的每日容量，能画出增长曲线。如果曲线斜率明显超出预估，说明去重效果没达到预期，或者某台虚拟机的变更率远超估算，得重新算账。

第三件是随机抽一份备份做文件级验证。不用整机恢复，就随便挑一个文件恢复出来，打开看看内容对不对。这个动作花不了五分钟，但能证明备份集是真的可用，而不是一堆看起来成功的字节。我现在的习惯是每周五做一次这样的抽查。

4. 恢复才是重点：几种恢复方式的选择与演练

4.1 整机恢复、单文件恢复与挂载恢复怎么选

备份做得再漂亮，恢复不回来等于零。Data Recovery 提供几种恢复路径，适用场景差别很大，选错了要么慢，要么丢数据。

整机恢复适合虚拟机彻底报废的情况，比如系统盘损坏、或者操作系统被勒索类恶意程序加密。做法是选一个备份点，指定恢复到哪个主机或集群、用什么名字、要不要保留原虚拟机。这里有个关键决策：是覆盖原虚拟机，还是恢复成一台新的。我强烈建议恢复成新的虚拟机，先挂到隔离网络里验证，确认没问题再切换业务。覆盖恢复一旦中途出错，原虚拟机也毁了，等于两个都没了。

单文件恢复适合误删、误改的场景，也是日常用得最多的一种。它的实现方式是把备份里的虚拟磁盘挂载成一个临时的数据存储，让管理员通过客户端浏览文件系统，把需要的文件拷出来。这个过程对虚拟机本身零影响，也不会影响备份集。

还有一种介于两者之间的用法，是把备份的磁盘直接挂到一台隔离的虚拟机上做验证，比如拿一个月的全量备份启动一台测试机，验证升级前的状态。这个用法在做变更前特别有价值，相当于给自己留了一条随时回头的路。

4.2 一次完整的恢复演练该怎么做

演练不是走过场，要按真实故障的场景来设计。我一般按这个流程走一遍。

先确定演练目标，比如"核心业务虚拟机的系统盘在一个月内任意时间点可恢复"。然后挑一个随机的历史备份点，不要挑最新的，最新的往往还没经历过完整校验。接着在隔离环境里执行恢复，记录每个环节的耗时——这个数据比恢复成功本身更重要，因为它直接决定你的实际恢复时间目标能不能达标。

恢复完成后不是开机就完事，要验证三件事：系统能正常启动并进入登录界面、关键服务能起来、数据完整性没问题（比如数据库能启动、能查到一个历史时间点的记录）。这三项都过了，才算演练成功。

演练结束后补一份记录，写清楚这次用的备份点、耗时、遇到的问题、以及后续要改的配置。这份记录在下一次真出故障的时候，价值非常高——你不需要临场思考，照着做就行。

提示：演练别只在虚拟机层面做，也要演练一下"找不到备份点怎么办""管理界面登录不了怎么办"这类场景。真出故障的时候，往往不是数据本身的问题，而是你根本进不去管理界面。

5. 踩坑记录与排查速查表

5.1 那些年碰到的典型故障

第一类故障是作业一直跑全量，永远不进增量。前面提过，根因基本都是变更块追踪没生效。排查方法是看作业的传输数据量，如果每次都接近虚拟机实际占用，那就没跑了。解决路径是确认参数已经写到虚拟机配置里，然后做一次关机开机或者快照加删除的动作让它生效，再跑一次作业观察。

第二类故障是作业失败但报错信息很含糊，只说"无法创建快照"或者"传输中断"。这类问题九成出在存储或权限上。我一般的排查顺序是：先确认虚拟机所在数据存储的剩余空间，再看这个虚拟机的快照操作是否被其他备份软件锁定（两台备份工具抢同一台虚拟机是经典冲突），最后检查那个服务账号的权限有没有被改过。

第三类故障是备份存储位置容量还在，但作业报空间不足。这种情况通常是设备自身系统盘的临时空间满了，不是备份存储位置的问题。设备在做校验或者合并旧备份的时候，会在本地临时目录里生成中间文件，系统盘给得太小就会卡在这。解决办法是清理设备上的临时文件，长期看要把系统盘扩容。

第四类故障是恢复过程很慢，慢到无法接受。整机恢复的速度受限于目标存储的写入能力，如果恢复目标是一个本身就很忙的数据存储，速度会被压得很低。我的做法是恢复时尽量选一个空闲的数据存储，先恢复出来，验证通过后再做存储迁移。多花一步，但整体时间反而更短。

5.2 问题速查表

5.3 几条不写在文档里的经验

第一条，别在同一台虚拟机上同时挂两套备份工具。这个坑非常隐蔽，因为两边都显示成功，但快照会互相打架，最终产生一堆残留快照，某天突然发现虚拟机性能暴跌。上线新备份工具之前，先把旧的作业停掉。

第二条，备份存储位置尽量单独放一块物理存储，别和业务虚拟机共用。理由是备份是高吞吐的写操作，和业务抢 IO 会导致两边都难受。如果实在只有一套存储，至少把备份作业安排在业务低谷期，并且给备份的虚拟磁盘设置 IO 限制。

第三条，设备的快照别乱做。有些人习惯给所有虚拟机做快照当"保险"，包括这台备份设备本身。问题是备份设备的磁盘 IO 本来就重，一做快照性能直接掉一半，作业跟着出问题。设备需要升级或者改配置之前，先停作业、再做变更。

第四条，把设备的配置文件导出一份留着。设备重装是常事，重装之后如果有一份配置备份，能省掉大量重建作业的时间。导出的频率不用高，每次改完作业配置导一次就够。

第五条，日历上给自己设一个提醒，每季度重新算一次容量账。虚拟机的数据量不是静态的，业务增长、新系统上线都会推高占用，一年前算的数字到现在往往已经不够看。等存储告警了再动手，就得在压力下做决策。

最后分享一个我个人一直在用的做法：把所有备份作业的排程画成一张时间轴贴在运维文档里，纵轴是时间、横轴是虚拟机分组，谁和谁重叠一眼就能看出来。这张图在我调整排程、增加新作业的时候救过好几次场，比翻配置界面直观得多。老环境维护最怕的不是技术难，而是信息散落在各处没人整理，一张图、一份记录，往往比多买一套工具管用。