成功案例

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

2018-08-11 14:50:41
江苏省某外企,一个 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系统对于删除数据的底层处理机制。


沪公网安备 31010402007118号