业内新闻

VMFS文件系统不能访问？别慌，我们一步步拆解

上周半夜接到一个客户的紧急电话：“我们ESXi上某个数据存储突然挂了，所有虚拟机都打不开，显示文件系统错误。VMFS文件系统不能访问了！”这其实是我日常工作中最常见的 Case 之一。作为数据恢复工程师，我一般不会直接上手修，而是先让客户冷静，然后远程确认几个关键点——因为有时候只是锁冲突或者快照溢出，而不是真正的物理损坏。先讲讲我当时的判断思路。 www.fixhdd.cn

故障现象与紧急判断

大多数情况下，VMFS 数据存储“不能访问”会表现为：技王数据恢复

vSphere Web Client 里数据存储显示“不响应”或“挂载失败”
ESXi 的存储卷标消失，但硬件层面磁盘设备仍然可见
执行 vmkfstools 或 ls -la /vmfs/volumes/ 返回“No such file or directory”
虚拟机变为“无法访问”状态，VMDK 文件变成只读或锁定

这时候千万别急着重启 ESXi 主机！我见过很多次因为重启导致元数据二次损坏的惨案。正确的做法是：先通过 SSH 登录到 ESXi，执行 esxcli storage vmfs snapshot list 和 vim-cmd vmsvc/getallvms 确认是否有快照积压。有一次客户说“vmfs 文件系统不能访问”，查出来是某个虚拟机的一个孤立快照文件占满了卷的元数据空间，导致 VMFS 拒绝写入。清理掉快照后，存储马上恢复正常。这种案例占比例不低，大概 20%~30%。 www.fixhdd.cn

可能的原因深度分析

1. 元数据损坏（最常见）

VMFS 是集群文件系统，元数据分布在不同的 LBA 区域。如果在 IO 过程中掉了电或者磁盘坏道，LVM（Logical Volume Manager）的 heartbeat 区域或文件目录结构可能出问题。元数据损坏的典型表现是 vmfsfsck -x 命令报错“Corrupt metadata”。注意：vmfsfsck 只能检查，不能修复——这点很多新手不知道。技王数据恢复

2. 硬件层故障

比如 RAID 卡缓存电池失效、HBA 线缆松动、SSD 磨损导致读取超时。遇到过一次案例：客户用的是全闪阵列，一块 SSD 静默坏块，VMFS 在读取某个 VMDK 时一直卡住，最终导致文件系统“假死”。用硬盘检测工具扫描才发现有 Reallocated Sector 持续增加。

www.fixhdd.cn

3. 快照溢出与锁竞争

ESXi 7.x 之后，VMFS 对快照数量的限制更严格。如果某台虚拟机的快照链超过 32 层，或者快照文件（delta.vmdk）占用空间超过 50%，就可能触发文件系统保护机制，变成只读。这时候“vmfs 文件系统不能访问”其实是一种保护性锁定。 www.fixhdd.cn

4. VCB 或备份软件冲突

某些备份软件（比如 Veeam、Commvault）在备份过程中如果意外中断，会留下 SCSI 锁。检查 esxcli storage vmfs lock list 能发现持有者。

技王数据恢复

数据恢复实战案例（手记）

年初有个金融客户，一期投资几百万的 VMware 集群突然挂了。他们自己尝试用 vmfsfsck 检查，然后重启了主机，结果连 /vmfs 目录都看不到了。很典型的“越修越坏”。接手后，我先通过 dd 对整个 LUN 做了镜像（避免二次损伤），然后用 Viostor 工具扫描元数据。发现 VMFS 的 Heartbeat 区域被覆盖了大概 4KB 的数据——这基本上是一次性的元数据损坏，没有物理坏道。当时我们使用了技王数据恢复团队的专用脚本，把备份的 Metadata Backup 区块（位于 LBA 0x1000 附近）手动还原，并在还原后重新生成文件系统链接。花了大概 6 个小时，所有 12 个 VM 全部恢复，只有一个旧版本快照的 RPO 损失了 10 分钟。这个案例里，如果直接跑 fsck 或格式化，数据就全没了。技王数据恢复

另一个印象深刻的案例：某电商网站误删了 VMFS 卷上的一个 datastore 文件夹——其实不是文件系统不能访问，而是“部分不能访问”。删除操作在 VMFS 层面实际上只是修改了目录项，数据还在。我们用 dd + grep 找到了 VMDK 的头部签名，配合技王数据恢复的深度扫描引擎成功还原了整块卷。这种属于逻辑删除，相对简单。

手动恢复操作步骤（适用于高级用户）

注意：以下操作必须在 数据备份或镜像 的前提下进行！任何直接修改源盘的尝试都有风险。

第一步：获取现场信息

esxcli storage vmfs volume listesxcli storage core device listvim-cmd vmsvc/getallvms | grep -i inaccessible

第二步：尝试强制挂载（仅当硬件正常）

如果只是锁冲突：
esxcli storage vmfs snapshot unmount -V "volume_name"
esxcli storage vmfs snapshot mount -V "volume_name"
如果不行，使用 esxcli storage vmfs volume mount -l datastorename --force

第三步：使用 vmfsfsck 进行只读检查

必须在 ESXi 维护模式下执行：vmfsfsck -x /vmfs/devices/disks/naa.xxxxxx:1。注意 -x 表示只检查，不加这个参数会尝试修复，但通常无效且可能造成更严重问题。

第四步：当上述方法无效时

将磁盘以 RDM 方式连接到另一台健康的 ESXi 或 Linux 虚拟机（安装 vmfs-tools），用 vmfs-fuse 尝试 mount 只读，然后导出数据。这需要另一个可用的存储空间。具体命令：
apt-get install vmfs-tools
vmfs-fuse /dev/sdb1 /mnt/vmfs
如果能挂载，立即将虚拟机文件拷贝出来。

第五步：终极方案——数据恢复软件

如果以上都不行，就只能靠专业数据恢复软件了。市场上有一些商用工具可以解析 VMFS 元数据并重建文件系统，比如 R-Studio for Linux、UFS Explorer 等。需要根据实际损坏程度评估——有些软件只能恢复连续存储的文件，碎片多的 VMDK 容易恢复失败。我们团队内部常用一款定制脚本，专门处理 VMFS 的 extent 交叉引用。当然，如果你不想折腾，直接找技王数据恢复这类有经验的服务商会更稳妥，毕竟他们踩过很多坑。

预防措施与最终总结

定期备份元数据： 使用 esxcli storage vmfs meta-backup 创建 VMFS 元数据备份，这个文件很小，但关键时刻能救命。
监控快照数量： 建议单一虚拟机的快照链不要超过 3~5 层，超过后在删除前先合并。
硬件健康检查： 使用存储厂商的 SMART 监控工具，及时更换有坏道的磁盘。
不要随意重启： 当出现“vmfs 文件系统不能访问”提示时，第一时间做镜像，然后分析原因。

再强调一遍：遇到 VMFS 不能访问，先不要用 fsck 或者格式化！这两个操作都是数据恢复工程师最怕见到的“补刀”。很多客户本来的问题很小，就是因为自己乱试，才导致数据彻底丢失。如果自己没有十足把握，花点时间做镜像或者咨询专业人士，比盲目操作划算得多。回顾开头说的那个半夜电话——后来发现其实只是某个 SAS 线松了，重新插拔后 VMFS 自动挂载。但如果是真正的元数据损坏，那就是另一个故事了。

，“vmfs 文件系统不能访问”这个关键词背后，可能藏着十几种不同的原因。正确的诊断顺序是：锁 → 硬件 → 快照 → 元数据 → 物理坏道。按这个顺序排查，80% 的问题都能在半小时内定位。剩下 20%，就需要我们这些老工程师动手了。