能恢复,但前提是你先管住自己的手。ESXi 虚拟机损坏后,绝大多数数据都还躺在 VMFS 数据存储里,真正导致彻底丢数据的往往不是故障本身,而是故障之后的误操作格式化卷、重建磁盘、覆盖写入,先断电隔离、先复制出 .vmdk 文件、先看清 .vmx 和 .vmdk 描述符,再谈修复,这是所有恢复路径的共同起点。
先判断:虚拟机损坏,数据到底还在不在
虚拟机的"三件套"文件,坏一个不等于全丢
一台 ESXi 虚拟机在数据存储里其实是一堆文件,理解它们的分工,才知道该救谁。
| 文件 | 作用 | 损坏后果 | 可否重建 |
|---|---|---|---|
.vmx |
虚拟机硬件配置,几 KB 文本 | 虚拟机从清单里消失、无法注册 | 完全可以重写 |
.vmdk(描述符,小文件) |
磁盘的几何参数、CID、父盘链、flat 文件指向 | 开机报"磁盘无法打开""找不到虚拟磁盘" | 多数可修 |
-flat.vmdk(数据文件,几个 G 到几个 T) |
真正的业务数据 | 报 I/O 错误、文件系统变 RAW | 只能抢救,不能重建 |
.vmsd / -00000x.vmdk |
快照元数据与增量盘 | 快照链断裂、无法合并 | 可绕过 |
.vmss / .vmem |
挂起状态与内存镜像 | 恢复后回到挂起时刻 | 可丢弃 |
看清一个关键事实:配置类文件(.vmx、描述符、.vmsd)损坏是"小病",-flat.vmdk 里的数据块损坏才是"大病"。前者靠手工重写或命令重建就能恢复,后者才需要动数据恢复工具。
哪些情况有救,哪些基本没戏
- 有救的典型场景:误删虚拟机后 VMFS 卷未被写入新数据;
.vmx被误改或损坏;升级 vSphere 后虚拟机无法注册;快照链断裂导致无法开机;数据存储重新挂载后虚拟机显示"孤立的"。 - 难度大的场景:
-flat.vmdk出现大面积坏块;VMFS 卷头或 LVM 元数据损坏;RAID 阵列崩溃后做过强制上线;已经被格式化成 VMFS 之外的文件系统。 - 基本没戏的场景:数据存储被整体格式化后又写入了新虚拟机;磁盘被多次清零。
业内专家指出,虚拟化环境的数据恢复成功率,与"故障发生后是否立即停止写入"呈强相关,而不是与故障类型的复杂程度强相关。
ESXi虚拟机损坏了怎么恢复数据:从只读到动手的完整路径
第一步:停止一切写操作,做只读隔离
这一步决定后面还有没有得救。
- 把受影响的 ESXi 主机从集群里移出,或直接关机(如果能安全停机)。
- 关机前先记录:数据存储名称、UUID、虚拟机目录路径、报错截图。
- 把底层存储(SAN LUN 或本地磁盘)以只读方式挂到另一台机器上取证,不要在故障卷上创建任何文件。
- 用 SSH 连上主机,先只做查看,别急着重挂、别急着加
-f参数。
esxcli storage vmfs extent list # 确认 VMFS 卷是否还正常识别 vmkfstools -P /vmfs/volumes/datastore1 # 查看卷的块大小、容量、版本 ls -lh /vmfs/volumes/datastore1/vm01/ # 确认 vmx、flat.vmdk 是否都在
如果这些命令能看到虚拟机目录和那几个 GB 级的 -flat.vmdk,说明数据主体大概率还在,接下来就是处理"外壳"。
第二步:看日志定位损坏类型
别猜,日志会告诉你答案,三处最有用:/var/log/vmkernel.log(存储与磁盘层报错)、/var/log/hostd.log(虚拟机注册与操作失败)、/var/log/vmkwarning.log(告警汇总)。
用 grep -i "error\|failed\|corrupt" /var/log/vmkernel.log | tail -50 过滤,重点看有没有 SCSI reservation、lost access to volume、cannot open disk 这类关键词。日志指向哪个文件,就从哪个文件下手,不要上来就重建整个虚拟机。
第三步:ESXi虚拟机文件损坏修复步骤:.vmx 和 .vmdk 分别怎么处理
.vmx 是纯文本,可以直接看,常见问题是多了一行错误参数、scsi0:0.fileName 指向了不存在的文件、或者文件被截断,处理办法是新建一台配置相近的虚拟机,把它的 .vmx 复制过来,逐行替换磁盘路径和网卡 MAC,然后在数据存储浏览器里右键 .vmx 选择"注册虚拟机";命令行等价操作是 vim-cmd solo/registervm /vmfs/volumes/datastore1/vm01/vm01.vmx。
.vmdk 描述符要更小心,打开它,末尾的 extent description 一般长这样:
RW 41943040 VMFS "vm01-flat.vmdk"
这个数字是扇区数,必须和 -flat.vmdk 的实际大小对得上(41943040 扇区 × 512 字节 = 20GB),数字对不上,虚拟机就会报磁盘大小不匹配。修描述符之前,先把整个虚拟机目录复制到另一块可用空间,用 cp -r 或 vmkfstools -i,这一步花的时间远比返工便宜。
如果描述符彻底丢了,只剩 flat 文件,思路是"造壳装数据":用 vmkfstools -c 创建一个大小完全一致的厚置备磁盘,删除新生成的 flat 文件,把原始 flat 文件改成新描述符要求的文件名,再修正描述符里的 CID 使其自洽,行业共识认为,这类操作必须在副本上做,原卷保持只读。
第四步:VMFS数据存储误删虚拟机恢复:先保住卷,再谈文件
误删虚拟机是最常见的求助场景,也是最容易挽回的场景。
- 发现误删后,立刻不要在任何虚拟机上执行新建、扩容、快照合并。VMFS 是日志式文件系统,新写入会覆盖已删除文件的块。
- 把数据存储以只读方式重新挂载:在 vSphere Client 中添加存储时,选择"保留现有签名",不要点格式化。
- 如果卷在别的阵列上仍有快照(存储层快照,如 SAN 的 LUN clone),优先从存储快照挂一份副本,这比任何软件恢复都快。
- 纯逻辑删除且没有存储快照时,才考虑第三方 VMFS 恢复工具做只读扫描,把识别出的虚拟机文件导出到另一块盘。
顺序不能反:先保住卷的完整性,再去逐个文件捞。
第五步:让快照和备份兜底
能开机进系统的,先把数据导出来,再谈修虚拟机,顺序别搞反,虚拟机可以重建,业务数据重建不了。
- 能进系统但磁盘报错:在虚拟机里做文件级备份,或热添加一块新盘,用
robocopy、rsync把数据搬过去。 - 完全无法开机但
-flat.vmdk完好:用vmkfstools -i转成厚置备磁盘,挂到一台临时虚拟机上读。 - 有 Veeam、Commvault 之类备份的,直接走整机恢复或 Instant Recovery,这通常是最快的一条路。
快照回滚和备份恢复怎么选,别把快照当备份
这是很多人踩过的坑,快照文件是增量盘(-000001.vmdk 这类 delta 文件),它只记录"从创建快照那一刻起的变化",不是一份独立完整的副本,快照链越长,开机、合并越慢,合并失败时整台虚拟机都会打不开。
对比一下两条路径:
| 维度 | 快照回滚 | 备份恢复 |
|---|---|---|
| 恢复粒度 | 整机,回到快照时刻 | 整机或单文件 |
| 依赖 | 原始磁盘完好、快照链完整 | 独立备份介质 |
| 风险 | 快照链断裂即失效 | 恢复时间长但可控 |
| 适用 | 打补丁、升级前的短时回退 | 误删、勒索、存储损坏 |
选择逻辑很直接:几小时内的配置失误,用快照;跨天的误删或卷级损坏,用备份。如果两者都没有,就走前面第三、第四步的文件级修复。
另外提醒一句:快照不要长期保留,近年来多起虚拟机无法开机的案例,根因都是快照链堆了几十个增量盘、合并时空间不足。
ESXi虚拟机数据恢复多少钱,什么情况该送专业机构
价格没有统一标准,通常按介质容量、损坏类型和工时计费:逻辑损坏(误删、描述符损坏、快照链断裂)一般按卷或按项目报价,物理损坏(磁盘坏道、RAID 崩溃、开盘)按盘和难度计费,从千元级到万元级都有。报价明显低于市场、又承诺"百分之百恢复"的,基本可以直接跳过。
以下几类情况,建议尽快停手并交给专业机构:
-flat.vmdk出现持续的 I/O 错误或坏块告警;- VMFS 卷头、LVM 元数据损坏,主机认不到卷;
- RAID 阵列掉盘后做过重建或强制上线;
- 涉及核心业务库,且没有可用备份。
自己可以处理的边界很清楚:文件还在、卷还认得到、只是配置坏了。
关于ESXi虚拟机恢复的常见问题
ESXi 虚拟机损坏后还能直接开机吗?
要看损坏位置。.vmx 或描述符坏了,修好后可以正常开机;-flat.vmdk 有坏块时强行开机,文件系统可能被进一步写坏,甚至触发 Windows 的 chkdsk 自动修复造成二次损伤,判断标准是日志里有没有磁盘层 I/O 错误,有就先别开。
虚拟机目录里出现 -000001.vmdk 是什么情况?
这是快照产生的增量盘,说明该虚拟机存在快照,此时不要手工删除增量盘,也不要把主盘和增量盘混着拷走,正确做法是用"快照管理器"执行合并,或在副本上用 vmkfstools -i 把增量链转成单一磁盘,直接删增量盘等于删掉快照以来的全部数据。
ESXi 虚拟机数据恢复通常要多久?
纯文件级修复一般几小时内能完成,前提是卷可正常挂载;涉及误删后的全卷扫描,视数据量大小通常需要一到数天;物理层故障需要开盘或阵列重组时,周期往往在一周左右,具体取决于备件和数据量,恢复时长的主要变量是介质容量与是否需要重建 RAID 参数,而不是虚拟机数量。