记录一次不太完整的vSphere的VMFS数据恢复和形成原因

intohard · 发表于 2014-12-19 12:53:45

江苏省某外企，一个 vSphere 集群，其中一个 VMFS 卷上一台虚拟机被误删除。
vSphere 版本为 4.1 ，虚拟化系统为 ESX4.1 ，被删除的虚拟机为 windows 系统，虚拟磁盘500GB ，虚拟磁盘为精简模式，无快照。

恢复被删除的精简模式的虚拟磁盘比较麻烦，需要逐块定位。
这个案例的 VMFS 块大小为 4MB，一个指针块4K，一个指针块有1024个指针，可定位数据大小：1024*4MB= 4GB

500GB 的虚拟磁盘则要定位 125 个指针块。

很容易定位第一个块，分析这个块数据发现块指针仅前 2.5GB 部分正常，后部指针全为0。
而windows 的NTFS 文件系统，一般从第3GB开始是 MFT （Master File Table）区域，MFT大小视文件数量多少而定。这个案例的MFT大小约250MB。
MFT是NTFS文件系统中是核心的元文件，记录了文件或目录的名称，大小，时间和最重要的指向数据指针。如果此部分数据无法恢复，这个案例就可以宣布失败了。

下图是 VMFS中500GB虚拟磁盘不完整的前 4GB 的指针块：

可以看到绿色选择部分全为0，而此部分和后面部分都是指向的是 500GB 虚拟磁盘的 MFT区域。这太要命了。

没办法，只有从NTFS底层结构入手，临时写一个程序分析和 dump MFT。

dump 出MFT后，补上第一个4GB的块，文件目录名已完整，NTFS的文件目录树已形成。

再通过 MFT再定位后面的496GB数据，很快定位完成，通过得到的125个指针块直接dump这个 500GB 的 VMDK，用软件打开，一却正常：

一般到说，到此步骤，数据恢复工作就可完成，但仔细的验证文件，却发现有少量文件数据不正常，再次分析所有NTFS上损坏的数据定位到VMFS 层，也一样发现有指针块的后部分为0。没办法，继续修补数据，但这个案例的虚拟磁盘是精简模式的啊，数据很少连续，用户数据也不能像MFT这样来定位，修补效果有限。

在 ESX上这种情况很多，这种情况也同时存在于 LINUX和UNIX上，很久以前恢复ESX数据时就遇到过此情况，那时以为是被不良数据恢复公司坐地起价做了手脚，后来发现不是被人动过，而是类UNIX系统的特性决定的。

那时在上门给河南移动恢复一个 SUSE Linux 下误删除的 DB2 数据库时，他们在 dd 镜像存储后，我分析发现所有DB2 容器文件在EXT3文件系统中的指针块全为0，这当然无法恢复了，不过我让客户把主机重启之后，指针块全部出现，数据得以恢复。

分析此情况出现的原因：
Linux/UNIX 以及类Linux(如：ESX)的系统喜欢把文件系统大量的元数据（如 inode 或指针块）加载到内存中，而本地磁盘上的数据也不会及时回写。如果做镜像时系统仍在工作，有可能就会得到到一个缺少元数据的镜像。
见议在做类似镜像时，可以将系统重启一下，不方便重启的话可以执行一个同步内存数据到磁盘的命令后再做镜像。

这个同步内存数据到磁盘的命令很管用，以前老的 solaris 系统管理员，被要求定时或在 solaris系统重启或关机前要执行3-5次这个命令。
这个命令不发了，自己思索，太轻易得来的东西没人会珍惜。

作者：小尹