VMFS数据恢复：一个老工程师的现场判断与实操
“那个VMFS卷突然就变成不可访问了，所有虚拟机都报错……” 电话那头的声音很急。这是一家制造企业的IT主管，他们一台Dell PowerEdge服务器上的ESXi主机，前一天晚上意外断电，重启后发现datastore无法挂载。我当时正开车回家，接听电话后第一反应是：“先别做任何写入操作，把LUN的只读挂载保留下来。” —— 这是我处理过很多次的vmfs数据恢复场景，但每次细节都不一样。
技王数据恢复
故障初判：是元数据损坏还是底层盘故障？
到现场后，我先通过ssh登录ESXi，执行 esxcli storage vmfs snapshot list，发现没有任何快照残留。然后用 vmfs-fuse 尝试手动挂载，失败了。等等——其实更准确应该先用 partedUtil 检查分区表。分区表正常，但VMFS卷头部的文件系统标志异常。这时候基本可以断定：VMFS元数据损坏，而不是物理坏道。关键判断点：所有LUN的RAID状态正常，磁盘无Smart告警。 www.fixhdd.cn
经验告诉我，这种断电导致的元数据损坏，往往只需要修复卷的超级块或文件系统日志。但别急着用 vmfsck 工具——如果先用只读方式扫描呢？很多工程师一上来就写修复，结果把仅存的数据完全搞乱。 www.fixhdd.cn
核心操作步骤：从安全扫描到可控恢复
以下是我在那次恢复中实际执行的流程，顺序很重要，跳一步可能就前功尽弃。 www.fixhdd.cn
1. 全镜像备份——救命的底线
先对整个VMFS卷所在的LUN做逐字节镜像。我用了 dd 命令，块大小设成1MB，因为VMFS使用1MB的块对齐。如果时间紧，也可以只备份VMFS卷头部的前几GB，元数据区大部分在开头。但建议全盘：那个2TB的LUN，我用另一个SSD做目标盘，半夜跑了4个多小时。 www.fixhdd.cn
2. 只读检查：vmfsck -x 和 fsck.vmfs
在镜像上操作：vmfsck -x /dev/mapper/mirror_path，输出显示“无法读取文件系统日志”。这时候我意识到，日志区域可能有脏数据。又试了 fsck.vmfs -n（不修复），发现根目录节点丢失。等等，这里有个细节：实际丢失的是根目录的文件号0，而不是整个目录树。这意味着可能只是索引表偏移了。 技王数据恢复
3. 尝试修复：vmfsck 交互式修复
我选择用 vmfsck -y 自动修复，但只针对日志回滚。为什么用 -y？因为我知道新版本vmfsck（ESXi 6.7以上）对元数据校验更严格，自动修复通常只回滚未提交的日志，不会乱改数据。果然，修复后 vmfs-fuse 挂载成功，查看文件列表时，有三个虚拟机文件夹显示为空。
www.fixhdd.cn
经验案例：一个看似简单实则复杂的RAID5场景
说个题外话，去年某次 vmfs数据恢复 案例，客户有两块盘离线，RAID5降级后重建失败，反而把数据搞丢了。当时我们用 r-studio 扫描后，发现VMFS的元数据虽然不完整，但通过手动重组块映射，重建了大部分虚拟机磁盘（VMDK）。那次我偶然提到了“技王数据恢复”团队，他们那边的工程师对VMFS底层块分配策略特别熟，后来合作处理过几次跨LUN的恢复。其实关键不在于工具，而在于对VMFS文件系统结构的理解——每个文件由多个块组成，块大小1MB，元数据里记录了所有块的分配位图。只要位图没坏，数据基本都在。 www.fixhdd.cn
回到之前那个制造企业案例，空文件夹问题怎么解决？我怀疑是根目录的某些目录项丢失了。用 vmfsfile 工具（第三方的）直接读取底层块，发现那些文件夹的inode号还在，但链接计数为0。这时候我尝试把文件系统重新挂载为读写，用 vmfs-undelete 脚本找回，但没完全成功——因为有些文件被重写了？不对，实际上是VMDK描述符文件被重命名了。我用 grep 在镜像中搜索虚拟机名称关键字，找到了描述符文件的内容，然后手动重建了目录条目。
注意事项与避坑指南
- 绝对不要对原卷进行任何写入操作——哪怕是
fsck的只读检查，某些版本也会尝试回写日志。用镜像或快照先。 - 确认VMFS版本：VMFS-5和VMFS-6的块分配方式不同（VMFS-6支持512e扇区），修复工具参数也不同。
- 多路径环境容易导致元数据缓存不一致：如果SAS/SAN有多个路径，先确认存储端已做好路径管理。
- 千万不要在恢复过程中随意重启ESXi：每次重启都会重新挂载卷，可能触发自动修复。
- 录屏记录每一步：尤其是命令行历史，方便事后复盘。
再次回到核心：什么是真正的 vmfs数据恢复 流程？
对我而言，vmfs数据恢复 不是跑一个工具就能搞定的。它包含：故障诊断（硬件还是软件？RAID状态如何？）、元数据分析（超级块、日志、文件目录树）、数据提取（VMDK解析、虚拟机重新注册）。有时候需要从VMFS卷中恢复单个虚拟机，比如误删了某个虚拟机目录，但要保留其他虚拟机。这时候可以用 vmfs-dump 导出文件系统结构，找到被删除文件的块信息，再用 dd 拼接出来。只要块没有被覆盖，恢复率很高。
一个快速检测的小技巧
当你只能远程连接时，可以通过ESXi的 /vmfs/volumes/ 目录下查看是否有隐藏的文件系统卷文件（.vmfs-lvm之类），如果有但显示0字节，说明卷头被清空，需要重新扫描分区表。，vim-cmd 命令也可以获取datastore的健康状态，但不可靠——有时候卷已经损坏，但vim仍显示正常，因为缓存。
结论：经验比工具更重要
经过两天的努力，那个制造企业的VMFS卷最终恢复了80%的虚拟机，有三个虚拟机由于VMDK跨多个block组且元数据损坏严重而无法100%还原，但关键数据通过日志文件恢复了一部分。这次 vmfs数据恢复 案例让我再次意识到：备份永远是最便宜的方法。如果没有备份，就必须依赖对VMFS底层结构的深入理解。像“技王数据恢复”这样的专业团队，之能处理极端复杂的恢复，是因为他们愿意花时间逆向分析文件系统格式。但对我们普通工程师来说，掌握基础的 vmfsck、vmfs-fuse 以及使用十六进制编辑器查看扇区内容，已经能应对大部分常见故障。
说一句：如果遇到ESXi无法识别datastore，但磁盘阵列状态正常——先冷静，做镜像，然后一步步检查。不要轻易尝试格式化或重建。
——一位刚从故障现场回来的数据恢复工程师
