企业官网建设流程全解析

1. 先把名字对上：vSphere 5.5 环境里那个"Data Recovery"究竟是什么

1.1 一个被叫错了很多年的产品名

如果你手上有一份 5.x 时代的培训资料，翻到备份那一章，大概率会看到"VMware Data Recovery"这个标题；但真到 vSphere 5.5 的环境里去找部署包，你会发现手里拿到的东西叫vSphere Data Protection，简称 VDP，版本号跟着 vCenter 走，也就是 VDP 5.5。这两个名字不是一回事，VDR 是 vSphere 4.x 时代的产物，到 5.0 之后就已经停止功能演进，5.5 环境下官方推荐、资料里真正能跑起来的是 VDP。我第一次接触这块的时候也犯过迷糊，拿着一份 VDR 的操作手册去配 VDP 的界面，找了半天"Backup Appliance"菜单，结果发现人家的向导叫"配置"。

这个认知差不是小事，它直接决定了你后面所有的部署动作。VDR 时代的架构相对简单，一个基于 SUSE 的虚拟设备，挂一个备份存储卷，管理入口在 vSphere Client 的插件里；而VDP 5.5 是基于去重存储引擎构建的虚拟设备，它需要独立注册到 vCenter，有自己的一套配置向导、自己的账户体系、自己的存储初始化流程，配置界面在https://<VDP-IP>:8543/vdp-configure，管理界面则通过 vSphere Web Client 里的 VDP 插件进入。你要是按 VDR 的思路去点，十有八九会在第一步就卡住。

所以这篇东西我打算按"真的要在 5.5 环境里把它跑起来"的思路写，从版本确认、部署前准备、OVF 部署、作业设计、恢复到排错，一条线走完。适合手上还有 vSphere 5.5 环境在跑、需要一套不花钱的整机备份方案的朋友；也适合刚接手老环境、被要求"做个虚拟机备份"但完全不知道从哪下手的人。文章里的操作路径以 vSphere Web Client 为准，因为 VDP 5.5 的插件在老的 C# Client 里基本用不了。

1.2 VDP 5.5 的能力边界，比想象中要窄

很多人对它的期待是"企业级备份平台"，这个期待需要往回收一收。VDP 5.5 单台设备的标准规格下，能保护的虚拟机数量是有上限的，0.5TB 规格大概能覆盖几十台，2TB 规格在理想去重率下可以到一百台左右，超过这个量级就要考虑多台设备或者直接上 VDP Advanced。它也不是万能的，模板、vApp、物理机、独立磁盘（Independent Disk）、物理兼容模式的 RDM 这些对象它都不备份，遇到这类虚拟机你在创建作业时就会看到它被过滤掉或者报错。

它真正擅长的事情是：对已开启 CBT 的虚拟机做映像级增量备份，用去重存储把重复数据压掉，然后提供整机恢复、单文件恢复和瞬时恢复三种出口。这三件事覆盖了中小规模虚拟化环境里 80% 的日常需求，剩下的 20% 比如数据库事务日志级别的备份、异地容灾、磁带归档，它不是干这个的，别硬塞。

看完这张表你大概能判断自己该不该在这上面花时间。我的建议是：如果你的环境是几十台虚拟机、保留周期以周和月为单位、没有强合规要求，VDP 5.5 完全够用，而且部署成本几乎为零；如果有异地容灾需求，那要搭配 vSphere Replication 一起用，VDP 只负责本地恢复点。

2. 部署前必须敲定的几件事，漏一件就等着返工

2.1 DNS 正反向解析和时间同步：这两条踩坑率最高

我先说最容易出问题的两条，因为这两条在部署向导里都是"点下一步"就过去的，但它们在后面的运行期会以各种莫名其妙的形式爆出来。第一条是DNS 的正向和反向解析必须都通。VDP 虚拟设备在注册到 vCenter 的时候，会用自己配置的 FQDN 去反查 IP，也会用 IP 去反查主机名，两边对不上，注册就会失败，界面上只给你一句很含糊的"无法连接到 vCenter"。

我在一个实验环境里遇到过这种情况：hosts 文件里随手写了个vdp.local，A 记录有了，PTR 记录没配，部署完成后配置向导跑到"注册 vCenter"那一步转圈转了十几分钟然后报错，日志里翻半天才看到是解析问题。补救的办法是登录设备的控制台，改/etc/hosts和 DNS 配置，但改完还要重启相关服务，比一开始就配好麻烦得多。所以部署前请务必确认：VDP 的 FQDN 在 DNS 里有 A 记录，同时有对应的 PTR 记录，从 vCenter 所在的机器上ping -a或者nslookup双向都能解析出来。

第二条是NTP 时间同步。VDP 的认证、证书校验、备份作业调度全都依赖时间，设备时间和 vCenter 差得多了，SSO 登录会直接拒绝，备份作业会"到点不触发"。部署时一定要在向导里指定可用的 NTP 服务器地址，而不是让它用默认的。如果你的环境里没有内部 NTP，那就至少保证 VDP 和 vCenter 指向同一个时间源。

提示：部署完成后第一件事不是去配备份作业，而是登录设备看date和 vCenter 的时间差，超过一分钟就要查原因。这个检查花三十秒，能省掉后面几个小时的排查。

2.2 规格与存储选型：0.5TB 还是 2TB，取决于去重率而不是原始容量

VDP 5.5 部署时可选三种存储规格，0.5TB、1TB、2TB，这里的"TB"指的是去重后的可用容量，不是你能保护的原始数据量。这个区别很关键，很多人按"我有 3TB 虚拟机磁盘"去选 2TB 规格，结果发现容量告警来得比预想早。

实际规划时我一般按经验去重率 3:1 到 5:1 来估算，也就是 2TB 的去重存储大约能覆盖 6TB 到 10TB 的原始虚拟机数据，前提是你的虚拟机之间有大量相同操作系统、相同补丁级别的重复块。如果环境里全是各不相同的数据库文件、视频素材、编译产物，去重率可能只有 1.5:1，那就要老老实实按低比例算。

另外两个存储细节值得单独说。一是 VDP 虚拟机的系统盘和数据盘要分开放在不同的数据存储上，如果挤在同一块盘上，备份写入的 IO 会和系统运行抢资源，表现为配置界面卡顿、作业启动慢。二是数据盘建议用厚置备，别用精简置备，因为去重存储的写入模式是持续追加的，精简置备在容量快满的时候会触发反复的块分配，性能断崖式下跌。

2.3 账号、端口与 vCenter 侧的准备工作

账号这块，部署 OVF 的时候会让你设置一个admin账户的密码，这个账户用于登录:8543的配置界面；还有一个root账户用于控制台和 SSH 操作，首次登录会要求改密码。这两个密码记牢，尤其是 root，VDP 出问题的时候基本只能靠它登进去看日志。

端口方面，vCenter 到 VDP 需要通 443、8543、22，VDP 到 ESXi 主机需要通 902（用于热备传输）、443。如果环境里有防火墙策略，这几个端口提前放开，别等部署完了再一个个试。我见过一次排查了两小时的问题，最后发现是 VDP 所在网段到某台 ESXi 的 902 被拦了，导致那台主机上的虚拟机全部备份失败，报错信息还是"快照创建失败"，非常有迷惑性。

vCenter 侧还要确认两件事：一是vCenter 的版本必须是 5.5，VDP 5.5 不能注册到 5.1 的 vCenter 上；二是 vCenter 使用的证书如果是自签的或者被替换过的，VDP 注册时可能会校验失败，这种情况要么把 CA 证书导入 VDP 的信任库，要么临时接受不受信证书。第二件事在老环境里很常见，因为很多环境上线时图省事换了自签证书，后面加设备就各种别扭。

3. 从 OVF 到能用：部署与初始化要过的几道关

3.1 部署 OVF 模板时那几个容易点错的参数

VDP 5.5 的分发包是一个 OVF 模板，通过 vSphere Web Client 的"部署 OVF 模板"向导导入。前面几步都是常规的选源、选名、选集群、选存储，真正容易出错的是后面这几处。

磁盘格式这一步会问你要不要用精简置备，前面说过，数据盘一定要选厚置备（Thick Provision Lazy Zeroed 就够了，Eager Zeroed 会在部署时多花很长时间）。网络映射这一步要把模板里的网卡映射到你环境里对应的端口组，如果 VDP 要跨网段管理虚拟机，建议一开始就放在能通所有 ESXi 管理地址的网段，中途改网络比一开始选对麻烦得多。属性填写这一步会一次性问你要 IP、子网掩码、网关、DNS、NTP、主机名，这些信息填错一个，后面就得进控制台改配置文件，所以填完请再核对一遍，尤其是主机名和 FQDN 的关系。

注意：主机名那一栏要填完整的 FQDN，比如vdp01.corp.local，不要只填短名vdp01。短名会让设备在注册时自己拼域名，拼错了又是一轮解析问题。

部署完成后不要急着开电源，先确认虚拟机的资源分配对不对，内存是不是按规格给足了，然后开机。首次开机要做初始化，这个过程视存储性能而定，快的十几分钟，慢的半小时以上，界面上会显示一串服务启动的日志，别以为卡死了就重启，重启反而会拖更久。

3.2 首次配置向导的逐项走法

初始化完成后，浏览器打开https://<VDP-IP>:8543/vdp-configure，用 admin 登录，会进入一个分步向导。这个向导的顺序不能跳，必须一步步走完。

第一步是设置时区和 NTP，时区选对，NTP 填对，这一步做完设备会自动同步一次时间，稍等几秒看到同步成功的提示再往下。第二步是设置 vCenter 注册信息，填 vCenter 的 FQDN、端口 443、以及一个有管理员权限的账号密码，这里用的账号需要是 SSO 管理员（比如 administrator@vsphere.local），普通账号注册会失败。第三步是配置存储，会让你选择本次分配的存储容量，并提示这个操作不可逆——一旦确定容量，后面想改只能重新部署。

存储初始化是耗时最长的一步，2TB 规格在机械盘阵列上跑二十分钟很正常。这一步千万不要中断，中断后存储卷会处于半初始化状态，再进配置界面会提示存储不可用，只能删掉虚拟机重来。我在实验室里就因为等不及点了刷新，结果整个设备废掉重装了一遍，白丢一个小时。

存储初始化完成后，向导最后会提示配置完成，此时回到 vSphere Web Client，在"vSphere Data Protection"的图标下应该能看到这台设备的注册状态是正常的。如果这里显示未注册或者灰色，先检查时间同步，再检查 DNS 解析，这两条占了注册失败的九成。

3.3 部署完成后必须马上做的三件事

第一件是改 root 密码并记录。首次 SSH 登录会强制改密码，改完立刻记到密码库里，这东西丢了只能重装设备。

第二件是跑一次连通性检查。在配置界面里有一个测试 vCenter 连接的按钮，点一下看到绿色再往下走；再到备份作业界面随便选一台不重要的虚拟机，手动触发一次备份，看能不能顺利完成。这一步的目的是在正式配置作业之前把网络、权限、快照能力这些基础问题全部暴露出来，比等到晚上作业跑失败再去查要省心得多。

第三件是确认时钟漂移监控生效。VDP 有个机制是定期和 NTP 校时，你需要确认它在正常工作，做法是隔一天再登进去看时间差。如果发现每天都漂移几十秒，说明 NTP 服务器质量不行或者网段有拦截，赶紧换一个源。

4. 备份作业的设计：界面只是壳，策略才是核心

4.1 备份类型与保留策略的组合逻辑

VDP 5.5 创建备份作业的路径是：vSphere Web Client → vSphere Data Protection → 创建备份作业。向导里会让你选虚拟机、选调度、选保留策略、选备份类型。看起来选项不多，但每一项背后都有取舍。

备份类型这里有两个选项：完整映像和增量。这里的"完整"不是每次都传全量数据，因为底层是去重存储，每次完整备份只把变化的块写进去，没变的块指向已有数据。所以从存储开销上看，完整备份和增量备份的差别没有传统备份那么大，差别主要在恢复链路和作业时长上。我的习惯是每周做一次完整、其余时间做增量，这样恢复的时候链路短，出问题也好回退。

保留策略按天、周、月、年四个维度配置。这里的坑在于很多人把四个维度全部拉满，结果存储很快告警。合理的配置思路是先想清楚"我需要恢复到多久以前的哪个点"：日常误删，保留 7 到 14 天足够；月度归档需求，保留 3 到 6 个月；年度合规，那要看具体规定。四个维度里，把最长的那个限制在真正需要的范围内。

表格里的数字只是参考，真实环境下还要结合去重率和存储容量反推。算不清楚的时候先用保守值跑两周，看实际占用率再调，比一上来就配满要稳妥。

4.2 调度与备份窗口的错峰安排

VDP 5.5 单台设备的并发备份流是有限的，标准规格下同时能跑的作业数量不多，作业一多就会排队。所以调度不能拍脑袋，要考虑三件事：虚拟机的数量、每台的平均备份时长、你能容忍的窗口长度。

我的做法是先把虚拟机按重要性和体积分组，核心业务放在窗口前段，大容量低优先级的放在后段，中间留出缓冲。假设窗口是凌晨 0 点到 6 点，一共 6 小时，如果有 40 台虚拟机、平均每台 15 分钟，总时长 600 分钟，看起来 6 小时够用，但这是在串行且单流的前提下算的；如果有 4 个并发流，理论上 150 分钟能跑完，实际考虑排队和偶发的慢作业，留 50% 余量比较安全。

提示：别把所有作业都卡在整点开始。VDP 的调度粒度是分钟级的，把作业分散到 0:00、0:20、0:40 这样的时间点，能避免整点时刻所有作业同时启动造成的资源争抢。

还有一个经常被忽略的点：备份作业和快照清理的时间关系。VDP 备份时会创建虚拟机快照，备份完成后删除。如果一台虚拟机在备份期间又被另一个作业盯上，或者有别的工具同时在打快照，就会出现快照叠加，轻则备份失败，重则虚拟机的磁盘被锁定。所以配置作业时，同一台虚拟机只能属于一个作业，这一点在规划阶段就要确认。

4.3 应用一致性、客户机代理和无代理的取舍

VDP 5.5 的备份默认是崩溃一致性，也就是快照时刻的磁盘状态一致，但内存里的数据没落盘，对文件服务器、静态网站这类场景完全够用，对数据库就不一定了。要拿到应用一致性，需要在虚拟机里装客户机代理，并在作业里勾选对应的选项。

装代理这件事有代价：要维护代理的版本、要在每台虚拟机里开端口、升级 VDP 的时候代理可能也要跟着升。所以我的建议是按需装，数据库和应用服务器装，中间件和纯文件机器不装。代理的另一个好处是支持单文件恢复，没装代理的虚拟机只能整机恢复或者挂载恢复，做不了文件级的挑拣。

无代理模式的优势是省事、无侵入，缺点是恢复粒度粗、无法做应用一致性。这个取舍没有标准答案，取决于你更怕"恢复慢"还是更怕"恢复出来的数据库起不来"。我的经验是：数据库类虚拟机一定要装代理并做应用一致性，其他虚拟机用无代理模式，把复杂度控制在必要范围内。

5. 恢复才是验收标准，备份跑成功不代表能救回来

5.1 整机恢复的标准流程与几个必查项

恢复操作的入口在 VDP 插件的"恢复"标签下，选一个恢复点，选一台目标虚拟机，然后一路下一步。听起来简单，但有几个地方必须确认。

目标位置的选择：恢复到原位置会覆盖原虚拟机，恢复到新位置会新建一台虚拟机。我强烈建议第一次恢复演练时选新位置，避免误覆盖。新位置恢复时要注意目标数据存储的剩余空间够不够，恢复过程是把备份数据完整写一遍，不是链接克隆，空间不够会在中途失败。

网络配置：恢复到新位置的虚拟机默认会接上原来的端口组，如果原端口组已经不存在，恢复出来的虚拟机网卡是断开状态，需要手动改。这个细节在环境做过网络改造之后特别容易碰到。

恢复后的第一件事：不是开机看能不能起来，而是先核对磁盘数量和容量、检查虚拟机的硬件版本、确认快照链干净。我遇到过一次恢复出来的虚拟机带着一个残留快照，开机后性能异常，查了半天才发现是恢复过程中的中间状态没清理。所以恢复完成后，先在快照管理器里看一眼有没有多余快照。

5.2 瞬时恢复适合什么场景，不适合什么场景

瞬时恢复（Instant Recovery）是 VDP 5.5 里比较有意思的能力，它把备份数据直接以虚拟机的方式挂载运行，不用等完整的数据复制过程，几分钟内就能把业务拉起来。这个功能在"核心业务宕机、先恢复服务再慢慢修数据"的场景下非常好用。

但它有几个明显的限制，必须心里有数。第一，瞬时恢复的虚拟机运行在 VDP 设备的数据存储上，性能受限于那台设备的 IO 能力，跑个临时服务可以，跑生产数据库会很难受。第二，瞬时恢复期间备份数据不能被清理，如果保留策略到期把数据删了，运行中的虚拟机会直接崩掉。第三，瞬时恢复只是一个过渡状态，最终还是要做一次完整的迁移（Storage vMotion 或者重新恢复）把它落到正式存储上。

我的用法是把它当成应急开关：主库挂了，先瞬时恢复一台起来顶住业务，同时并行做整机恢复到正式存储，等正式的起来了再把临时的关掉。这个流程演练过两次之后，故障恢复时间能从两小时压到二十分钟左右。

5.3 单文件恢复与代理安装的细节

单文件恢复的前提是虚拟机装了客户机代理并且备份时做了客户机级备份。操作路径是在恢复向导里选"恢复文件"，然后浏览备份点里的文件系统树，勾选需要的文件恢复到指定位置。

这里有个实操细节：恢复的目标路径必须事先存在并且有写权限，VDP 不会帮你创建目录。另外恢复大文件的时候会占用较长时间，界面上有进度条但刷新不快，别以为卡住了就点取消，取消后可能留下半截文件。恢复完成后记得核对文件大小和修改时间，尤其是配置文件这类东西，恢复错了版本比没恢复更麻烦。

代理安装本身没什么难度，从 VDP 管理界面下载对应平台的安装包，Windows 上双击下一步，Linux 上用包管理器装。装完之后要在 VDP 界面里确认代理状态变成"已连接"，如果一直是"未连接"，检查虚拟机到 VDP 的 22 和 8543 端口通不通，以及两边时间是否同步。

6. 实测踩坑记录：那些让我熬到半夜的问题

6.1 部署到一半提示无法解析 FQDN

这个问题前面提过一次，但值得展开说，因为它出现频率实在太高。现象是 OVF 部署完成、开机、配置向导走到注册 vCenter 那一步，转圈很久然后报错，日志里写的是连接超时或者名称解析失败。

排查链路是这样的：先登录设备控制台，nslookup vdp01.corp.local看正向解析对不对；再nslookup <IP>看反向解析有没有；两个都通的话，检查/etc/resolv.conf里的 DNS 地址是不是写对了顺序；再不行就ping一下 vCenter 的 FQDN，看能不能通。九成的情况卡在反向解析上，也就是 PTR 记录没配。

如果环境里确实没法加 PTR 记录（有些小环境没有内部 DNS 服务器），退而求其次的做法是在 VDP 的/etc/hosts里手工加一条记录，同时保证 vCenter 那边也能解析到 VDP 的名字。这个做法不优雅，但能救急，代价是以后改 IP 要记得两处都改。

6.2 时间漂移引发的认证异常

症状是备份作业跑得好好的，某天开始所有作业都失败，报错信息模糊，只说认证失败或者无法连接。登录配置界面，用 admin 账号也登不进去，提示凭据无效。

这时候第一反应应该是看时间。SSH 进去敲date，和 vCenter 的时间对一下，差超过五分钟基本就能定性。原因是 VDP 和 vCenter 之间的认证走的是令牌机制，令牌有有效期，两边时钟差太多，签发的令牌直接被认为是过期的。

修复办法是ntpdate手动同步一次，然后检查 NTP 服务有没有在跑，/etc/ntp.conf里的服务器地址对不对。如果发现是 NTP 服务器本身有问题，换一个源。为了防止复发，我后来在监控里加了一条针对 VDP 时间偏移的告警，超过 30 秒就通知，这个做法比事后排查省事太多。

6.3 备份作业卡在快照创建中

这个问题的排查链路最长，也最值得完整走一遍。现象是作业状态一直显示"正在创建快照"，过了几个小时也不动，取消也取消不掉。

第一步，去 vCenter 里看这台虚拟机的快照管理器，是不是有大量残留快照或者一个卡在中间状态的快照。如果有，先尝试手动删除，删不掉说明有任务占用。

第二步，看这台虚拟机所在的 ESXi 主机的任务列表，有没有卡住的克隆或者快照任务。有的时候是之前的某个操作没结束，把后续全部堵住了。

第三步，检查虚拟机的磁盘配置，是不是有独立磁盘、物理兼容 RDM 这类 VDP 不支持的对象。有些虚拟机在创建的时候开了独立磁盘，平时用着没感觉，备份的时候就暴露了。

第四步，看数据存储的剩余空间和 IO。快照需要写入 delta 文件，空间不够或者 IO 打满，快照就会卡住。这种情况在其他虚拟机上可能表现为备份超时。

第五步，如果以上都正常，考虑重启那台虚拟机的 VMware Tools 或者重启管理代理，再不行就只能在维护窗口里重启主机了。我遇到过一次是某台主机的管理代理异常，导致该主机上所有虚拟机都无法打快照，重启代理后恢复。

6.4 去重存储告警与空间回收的逻辑

存储告警是迟早会遇到的问题。VDP 的去重存储有个特点：删除了备份数据，空间不会立刻释放，因为去重存储是按块引用的，被删掉的备份点只是解除了引用，实际的块要等垃圾回收流程跑完才会真正空出来。

所以看到容量告警时，不要急着删备份点就以为万事大吉。正确的顺序是：先删掉不再需要的备份点，然后在管理界面里手动触发一次垃圾回收，等它跑完再看容量。垃圾回收本身耗时较长，几百 GB 的规模可能要跑几个小时，期间不要中断。

如果回收完容量还是很紧张，那就要审视保留策略是不是配得太宽，或者去重率是不是远低于预期。去重率低通常意味着环境里的虚拟机差异太大，这时候要么扩容设备，要么把一部分虚拟机挪到另一套备份方案上去。

7. 日常维护与后续扩展的几个思路

7.1 每周应该看的几个指标

VDP 的日常维护不需要天天盯着，但有几个指标建议固定周期看一次，花不了几分钟，能提前发现大部分隐患。

存储占用率和去重率：这两个数字放在一起看，能判断你的容量规划是否合理。如果去重率持续下降，说明备份的数据越来越"独特"，容量会比预期消耗得快。

作业成功率：连续三天以上有作业失败，就值得停下来查原因，不要用"重跑一次就好了"来对付，失败的背后往往是一个会反复出现的问题。

设备时间和 NTP 同步状态：前面说过，这个是隐性杀手。

快照残留：定期扫一遍受保护虚拟机的快照列表，发现有残留的及时清理，避免下次备份失败。

7.2 升级路径和日志收集的实用技巧

VDP 的小版本升级一般是打补丁包，通过管理界面里的更新功能完成，升级前要确认 vCenter 的版本没变、时间同步正常、存储有足够余量。升级过程中 VDP 会重启服务，期间备份作业会中断，所以安排在无作业的窗口里做。

真遇到解决不了的问题，收集日志是第一步。VDP 提供了日志打包功能，能在管理界面里一键生成一个压缩包，里面包含系统日志、服务日志、作业记录。打包前最好先复现一次问题，让日志里有对应的记录。另外记住几个常用的日志路径，SSH 进去之后可以直接看：作业相关的日志、服务启动日志、认证日志分别在固定的目录下，具体路径在文档里有，我的建议是把常用的几条命令存成一个文本文件，用的时候直接粘贴。

最后分享一个我在老环境里用了很久的习惯：每季度做一次恢复演练，挑一台非核心虚拟机，从备份恢复到新位置，完整走一遍流程，包括开机、检查服务、核对数据。演练的目的不是证明备份能用，而是让你在真出事的时候不用临时查文档。这个习惯坚持下来之后，我至少两次在真实故障里省掉了大量摸索时间，因为每一步该点什么、会等多久、哪里容易卡，心里都有数。

这套流程跑顺之后，vSphere 5.5 这种老环境其实也能有相当可靠的本地恢复能力。关键不在于工具多先进，而在于部署阶段的那些细节有没有认真对待，以及恢复流程有没有真的被验证过。