记录一次不太完整的vSphere的VMFS数据恢复和形成原因
江苏省某外企，一个 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次这个命令。
这个命令不发了，自己思索， 太轻易得来的东西没人会珍惜。
作者：小尹 沙发 真给力 顶1顶 顶你个肺 学习了，谢谢分享
页:
[1]