“虚拟机文件突然消失？别急，先看看底层发生了什么”

说实话，干了十五年数据恢复，接到“esxi恢复数据”的求助电话，我第一反应不是拍胸脯保证，而是先问一句：存储层是直接丢卷了，还是只丢了某个.vmdk？ 这两个场景的恢复路径完全不同，甚至可能连工具都不一样。上个月有个客户，机房断电后ESXi主机重启，发现数据存储里一个2TB的虚拟机目录只剩一个vmx文件，剩下全是空白。他以为是系统Bug，反复重启，结果VMFS卷的元数据被反复写入，差点把原来还能恢复的数据彻底覆盖。

，如果你遇到类似情况，第一条铁律就是：立即停止对故障存储的任何写操作。 哪怕只是挂载一个ISO、新建一个快照都可能让数据彻底消失。

先诊断：是VMFS卷损坏，还是文件系统层面的逻辑删除？

很多时候，用户急急忙忙找到我，说“esxi恢复数据”，但问题其实分两种：

• 情况A：VMFS卷在vSphere客户端显示“未挂载”或“不可访问” —— 这通常是元数据损坏或者心跳丢失。需要先尝试用 vmkfstools 或 vmfs-tools 扫描底层块设备。
• 情况B：虚拟机能正常看到，但里面某个虚拟机报了“文件未找到” —— 比如 .vmdk 描述符文件还在，但磁盘数据区（.flat.vmdk）被误删除或快照合并失败导致链断裂。

我们团队处理过一个典型A类案例：某公司一台Dell服务器，四块SSD组RAID5，VMFS 5卷。系统突然报警“datastore not mounted”。客户自己尝试用esxcli storage vmfs snapshot mount，结果提示“文件系统类型未识别”。他们怀疑是RAID卡故障，但检查硬件一切正常。我们把整个RAID逻辑卷DD镜像到一块备份盘，用WinHex逐扇区分析，发现VMFS的PBL（卷块定位器）表头偏移0x40处的校验值被写错了零头。这种损坏通常是因为异常关机时写缓存未刷新，只要把备份卷重新生成corrected PBL，再挂载回来就能读到文件。但前提是——备份前千万不能格式化或重建VMFS。

恢复的常规路径：从DD镜像到虚拟磁盘重组

不管哪种情况，标准的工作流大致是：

1. 对故障存储做全量扇区级镜像 —— 用 dd_rescue 或 vmkfstools -P /vmfs/volumes/datastore --raw 导出。注意，如果ESXi系统已无法启动，可以把硬盘拆到Linux主机上用 dd 做镜像。
2. 分析VMFS卷结构 —— 用 vmfs-tools （Linux下的开源工具）或者 Hex Workshop 手工解析。检查 File Name Index （FIB） 和 Volume Locator 是否完整。
3. 提取虚拟机核心文件 —— 关键是 .vmx, .vmdk, .vswp, 以及快照 delta.vmdk。如果是删除了 .vmdk 但 FIB 未被完全清除，可以通过扫描已知的 VMDK 头签名“KDMV”或“# Disk DescriptorFile”来找回。

有一次在深夜处理一个医疗器械公司的案例，他们的PACS虚拟机丢失了十个月的患者影像数据。我们通过扫描整个VMFS卷的未分配空间，找到了三个被删除的大块连续扇区，头部都有VMDK描述符标志。但其中一个描述符文件损坏，只读出了“# Extent description”行。后来用技王数据恢复自研的VMDK解析工具，手动补全了extent的几何参数（Cylinders/Heads/Sectors），居然把整个虚拟磁盘还原了。那个客户的工程师后来开玩笑说：这相当于在垃圾堆里拼回了一具恐龙骨架。

，esxi恢复数据 这件事，工具只能帮你到80%，剩下20%要靠对VMFS文件系统底层布局的直觉。比如，默认的VMFS块大小是1MB，但如果你创建虚拟磁盘时开启了“磁盘置零”，那么数据区的分布就不是连续的，恢复时就要注意处理稀疏文件。

常见误操作与避坑指南

这里列几个我亲眼见过的“好心办坏事”场景：

• 误用 vmkfstools -C 重建VMFS —— 这个命令会在现有物理分区上创建新的空卷，会彻底擦除旧元数据。如果你只是希望系统识别卷，应该用 vmfs-fuse 或 vmkfstools -P 只读挂载。
• 安装第三方恢复软件到故障存储上 —— 有些用户把 PE 系统或恢复U盘插入服务器，直接在故障数据存储上安装软件，结果写入数百个小文件，覆盖了关键区域。遇到这种情况，我会建议先把硬盘拆下来，接另一台主机做只读镜像。
• 快照链断裂后强行删除快照 —— 如果父快照损坏，删除子快照会导致所有子快照数据不可访问。正确做法是先复制完整虚拟磁盘到另一个位置，再用 vmkfstools -i 合并。

一个反面教材：本地SSD缓存导致的快照损坏

上周有个做电商的小团队，ESXi 7.0 U3 主机上跑了三个访客。运维同学为了加速，给虚拟机启用了“VMFS 本地SSD写入缓存”。某天一次手动快照合并后，虚拟机变成“孤儿状态”——父快照 .vmdk 被标记为“已提交”但实际数据没有写回。他们连续重启了三次，SSD缓存里残存的数据和磁盘上不一致，导致 .vmdk 中的虚拟扇区映射表（Grain Directory）多处CRC错误。

我们当时的处理方式：先用 dd 将整个VMFS卷导出到 NFS 共享（避免写回影响），然后用 vmfs-tools 的“rsbh”模式逐个扫描每个块，标记出有效的Grain Table。由于丢失了部分映射，我们不得不根据虚拟机操作系统（Windows Server 2019）的NTFS $MFT 分区规律，推断出丢失的扇区范围。恢复出95%的数据，客户的数据库日志文件因为被覆盖无法完全还原。这就是为什么我总强调：一旦怀疑VMFS有问题，第一件事不是分析，而是断写。

核心操作步骤：手把手，但别照搬

以下是一个经过验证的通用流程，但每个环境都不同，请根据实际情况调整。

1. 准备恢复环境

准备一台 Linux 主机（Ubuntu 22.04 或 CentOS 7+），安装 vmfs-tools 和 ddrescue。如果故障存储是本地磁盘，请先通过 SATA/SAS 转USB 或直接接入主板 SATA 口。注意：写保护跳线 是你的好朋友。

2. 创建扇区级镜像

sudo ddrescue -f -n /dev/sdd /data/backup.img /data/backup.log

ddrescue 可以跳过坏块并重试，日志文件记录映射状态。如果遇到大量坏道，可以用 -d 强制直读。

3. 挂载VMFS卷（只读）

sudo vmfs-fuse /data/backup.img /mnt/vmfs

如果提示 "Unable to find filesystem"，则可能元数据首部损坏，需要手工解析偏移量。通常 VMFS 卷起始于扇区 0 或 1，但RAID5 情况下需要先确定条带参数。这时候需要经验判断，或者直接用 photorec 扫描 VMDK 签名。

4. 提取关键文件

一旦挂载成功，直接用 ls -la /mnt/vmfs/ 列出文件。如果目录为空，可能 FIB 表损坏。用 vmfs-tools 的 lsblk 模式扫描blocks：

sudo vmfs-tools -b /data/backup.img -l

这会打印出所有文件的 inode 号和大小。重点找 .vmdk 和 .vmdk.flt 后缀的文件。

5. 修复虚拟磁盘链

如果只找到子快照而父快照丢失，需要先用 vmkfstools -i 尝试合并：

vmkfstools -i child.vmdk -d thin merged.vmdk

但如果父快照损坏，合并会失败。这时需要手动用十六进制编辑器修改子快照的 parentCID 和 parentFileNameHint 指向新的父盘。这个技巧我在十年前的论坛上学到，至今仍然有效。

6. 验证数据完整性

一旦恢复出 .vmdk 文件，用 qemu-img check 或 vmkfstools -e 检查一致性。然后挂载到另一个虚拟机里，逐步导出数据。

经验案例（随机顺序）

案例一： 某制造企业，一台ESXi 6.7 主机上存放的ERP虚拟机因为存储控制器驱动崩溃导致VMFS卷变成只读。他们尝试用“存储vMotion”迁移，但迁移到一半失败，源卷元数据被污染。我们用技王数据恢复的VMDK重组方案，从底层扇区直接重构了虚拟磁盘的Grain分配表，恢复了所有业务数据。客户唯一的损失是迁移中断那5分钟的新增交易记录，需要从数据库归档重放。

案例二： 一位个人开发者，在他自己的NUC上跑ESXi做测试，误删除了一个包含近期代码的虚拟机目录（rm -rf /vmfs/volumes/datastore/test_vm）。他立刻断电拆盘，送到我这里。我扫描了剩余空间，找到了被释放的inode，但文件名已丢失。由于他记得虚拟机名是“dev_env”，我用strings命令在镜像中搜索“dev_env”，在日志文件数据块里发现了.vmx路径，进而定位到了关联的.vmdk。这个案例说明，只要底层存储没被覆盖，esxi恢复数据 的成功率其实很高。 但关键是要快，因为VMFS在空闲时可能会做TRIM回收。

案例三： 某医院PACS系统，三个ESXi主机共享一个FC存储LUN，结果误操作把一个LUN的VMFS卷重新格式化为VMFS6（原有数据是VMFS5）。新格式写入了新的PBL和FIB，覆盖了原来的元数据区域。这种覆盖几乎无法用常规方法恢复，因为最关键的定位信息被彻底冲掉了。但幸运的是，他们之前做过一次快照（但快照链也被复制到新卷上了），我们通过解析快照中的原始Grain Table，反向推导出部分原卷布局，恢复了大约70%的非结构化医疗影像。这是一个惨痛的教训：操作前先做完整镜像，再格式化。

结论：别慌，但别犹豫

回想这些年的经历，esxi恢复数据 最怕的不是技术难度，而是用户在不恰当的时候做了不恰当的操作。如果你遇到了虚拟机文件缺失、存储不可用或快照错误，请一定：

• 第一时间断电或禁止写操作（拔网线或者卸载存储）。
• 不要尝试任何图形界面的“修复”或“挂载”按钮。
• 找专业团队做扇区级备份，再分析元数据结构。

，我想说一句可能会得罪同行的实话：市面上大多数“一键恢复软件”对ESXi环境几乎无效，因为VMFS是高级文件系统，它的分布式逻辑卷管理和快照链不是你常见的NTFS或ext4。如果你真的没有把握，宁可找像技王数据恢复这样有实战经验的团队，也比自己乱试强。毕竟，数据恢复里最贵的成本不是钱，而是“已经操作过”之后的后悔。

本文由资深数据恢复工程师撰写，基于真实案例，但所有个人信息已脱敏。技术细节仅供参考，实际操作请按自身环境评估风险。