【ESXi 5 虚拟化 系统 情景概述 】

用户使用的存储模式是通过 iSCSI 方式 来实现 FC SAN 的功能。 同时利用 DELL 服务器做的物理存储架构，利用 FreeNAS 来 实现 iSCSI 。并另外通过 两台 DELL 服务器做 ESXi5.0 的虚拟化系统。

1、 FreeNAS 层为 UFS2 文件系统，整个存储建一个稀疏模式的文件， 挂载在 ESXi5.0 系统 上 。

2、 ESXi 系统内 运行 6 台虚拟机，其中有三台最为重要。

3、 第一台 windows2003 系统虚拟机是此公司在当地的门户网站 。

混合构架类型： ASP.net 和 PHP

数据库 类型：  SqlServer2005 和 M ysql 5.1 。

4、 第二台 FreeBSD 系统， 运行 Mysql 数据库，供其它多台虚拟机使用。

5、 第三台 windows2003 服务器，存储新开发的程序代码。

【ESXi 5 虚拟化 系统故障 描述 】

工作人员在检查时发现 ESXi 系统 无法连接 存储， 通过后续的排查 在FreeNAS 中发现 UFS2 文件系统出现 故障 ， 之后用 fsck 对文件系统进行修复 。 修复后 ESXi 系统可以连上存储，但 ESXi 系统未能识别到原来的数据存储和 VMFS 文件系统， 工作人员 格式化VMFS 后发现 没有任何数据 。

【 ESXi 5 虚拟化 系统 数据恢复步骤 】

1 、 FreeNAS 文件系统 --- 应用构架层次：

FreeNAS(UFS2 文件系统– > 一个大的稀疏模式的文件 ) – > ESXi 5.0(VMFS 文件系统层 ) -> 单台虚拟机的虚拟磁盘 (windows-NTFS 文件系统 /FreeBSD-UFS2 文件系统 ) 。

2 、 FreeNAS 文件系统 -- 分析存储：

镜像 FreeNAS 层，分析存储， 我们可以 发现一个900 多 GB 的大文件，文件名： iscsidata 1 。通过UFS2 文件系统的二进制结构，定位到 iscsidata 1   文件的Inode 数据，发现此文件 有被重建的迹象 ，inode 指针指向的数据量很少。 FreeNAS 层无法解决，就无法进入到的 VMFS 层分析 阶段 。

收集UFS2 文件系统的重要结构：

块大小：16KB

Segment 大小： 2KB

柱面组大小：188176 KB

UFS2 一个数据指针占 8 字节，一个块可存储 2048 个数据指针。那么一个二级指针块则可存储： 2048*2048*16KB= 64GB 数据。一个三级指针块则可存储 64GB*2048= 128TB 数据。如果能找到 iscsidata 1   文件的三级指针块就能解决 FreeNAS 层问题。但 iscsidata 1 文件重建过，过程和大小都和原始的一样，估计有部分指针块已被覆盖。原始 iscsidata 1   文件的 inode 和新建的 iscsidata 1   文件的 inode 就在一个位置，尝试进行搜索，无其它有用的 inode 出现。只得现场写程序收集有用的指针块：

由于iscsidata 1 文件是使用稀疏模式，收集条件只能放宽，收集到了大量三级指针块和二级指针块。对收集到的所有三级指针块进行分析，都是无效的，无iscsidata 1 文件使用的三级指针块，估计在新建iscsidata 1 文件时被新的覆盖（新的iscsidata 1 文件在挂载到ESXi5.0 后有个 VMFS 格式化过程，而 ESXi5.0 使用 GPT 分区， GPT 分区会在磁盘最后写入冗余的 GPT 头和分区表信息数据，这样会使用 iscsidata 1 文件的三级指针块）。

现只能分析收集到的二级指针块，对有大量的二级指针块的指向数据进行DUMP ，然后再从磁盘中的数据定位到二级指针。这样得到大量 DUMP 的数据。

3 、 FreeNAS 文件系统 -- 开始分析 VMFS 层：

重格式化过VMFS ，和原始 UFS2 的指针已丢失，造成 VMFS 元文件已基本上不可用，无重要的参考信息，所幸虚拟机都无快照，仍可恢复。通过单台虚拟机层 (windows(NTFS) 和 FreeBSD(UFS2) 系统的文件系统结构 ) ，向上定位到 VMFS 层，在通过 VMFS 层定位到 DUMP 出的单个 64GB 文件，通过多次组合，最终这三台重要的虚拟机的虚拟磁盘都已恢复。将恢复出的网页数据和数据库数据上传到一新构建的系统中，拉起应用，数据无问题。

【ESXi 5 虚拟化 系统恢复结果】

经用户验收，数据无误，至此数据恢复工作结束。