服务热线：010-82207707 | 7x24小时服务热线:13693060057
北京安数云和科技有限公司

vSphere/ESXCASE SHOW

北京安数云和科技有限公司

北京安数云和科技有限公司 > 案例展示 > vSphere/ESX >
北京安数云和-专注于业级数据安全!

记录一次vSphere的VMFS删除虚拟机的数据恢复

来源：北京安数云和原创

作者：VMxDB

简介：记录一次vSphere的VMFS删除虚拟机的数据恢复……

浏览：

发布于：2015-08-07 13:15


江苏省某外企，一个 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，这当然无法恢复了，不过我让客户把主机重启之后，指针块全部出现，数据得以恢复。

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

2. ESX系统对于删除数据的底层处理机制。