[ESXi5 虚拟化系统情景概述]
用户使用的存储模式是通过 iSCSI 方式来实现 FC SAN 的功能. 同时利用 DELL 服务器做的物理存储架构, 利用 FreeNAS 来实现 iSCSI. 并另外通过两台 DELL 服务器做 ESXi5.0 的虚拟化系统.
1,FreeNAS 层为 UFS2 文件系统, 整个存储建一个稀疏模式的文件, 挂载在 ESXi5.0 系统上.
2,ESXi 系统内运行 6 台虚拟机, 其中有三台最为重要.
3, 第一台 windows2003 系统虚拟机是此公司在当地的门户网站.
混合构架类型: ASP.NET 和 PHP
数据库类型: SqlServer2005 和 MySQL 5.1 .
4, 第二台 FreeBSD 系统, 运行 MySQL 数据库, 供其它多台虚拟机使用.
5, 第三台 windows2003 服务器, 存储新开发的程序代码.
[ESXi5 虚拟化系统故障描述]
工作人员在检查时发现 ESXi 系统无法连接存储, 通过后续的排查在 FreeNAS 中发现 UFS2 文件系统出现故障, 之后用 fsck 对文件系统进行修复. 修复后 ESXi 系统可以连上存储, 但 ESXi 系统未能识别到原来的数据存储和 VMFS 文件系统, 工作人员格式化 VMFS 后发现没有任何数据.
[ESXi5 虚拟化系统数据恢复步骤]
1,FreeNAS 文件系统 --- 应用构架层次:
FreeNAS(UFS2 文件系统 -> 一个大的稀疏模式的文件) -> ESXi 5.0(VMFS 文件系统层) -> 单台虚拟机的虚拟磁盘 (Windows-NTFS 文件系统 / FreeBSD-UFS2 文件系统).
2,FreeNAS 文件系统 -- 分析存储:
镜像 FreeNAS 层, 分析存储, 我们可以发现一个 900 多 GB 的大文件, 文件名: iscsidata1. 通过 UFS2 文件系统的二进制结构, 定位到 iscsidata1 文件的 Inode 数据, 发现此文件有被重建的迹象, inode 指针指向的数据量很少. FreeNAS 层无法解决, 就无法进入到的 VMFS 层分析阶段.
收集 UFS2 文件系统的重要结构:
块大小: 16KB
Segment 大小: 2KB
柱面组大小: 188176 KB
UFS2 一个数据指针占 8 字节, 一个块可存储 2048 个数据指针. 那么一个二级指针块则可存储: 2048204816KB= 64GB 数据. 一个三级指针块则可存储 64GB*2048= 128TB 数据. 如果能找到 iscsidata1 文件的三级指针块就能解决 FreeNAS 层问题. 但 iscsidata1 文件重建过, 过程和大小都和原始的一样, 估计有部分指针块已被覆盖. 原始 iscsidata1 文件的 inode 和新建的 iscsidata1 文件的 inode 就在一个位置, 尝试进行搜索, 无其它有用的 inode 出现. 只得现场写程序收集有用的指针块:
由于 iscsidata1 文件是使用稀疏模式, 收集条件只能放宽, 收集到了大量三级指针块和二级指针块. 对收集到的所有三级指针块进行分析, 都是无效的, 无 iscsidata1 文件使用的三级指针块, 估计在新建 iscsidata1 文件时被新的覆盖(新的 iscsidata1 文件在挂载到 ESXi5.0 后有个 VMFS 格式化过程, 而 ESXi5.0 使用 GPT 分区, GPT 分区会在磁盘最后写入冗余的 GPT 头和分区表信息数据, 这样会使用 iscsidata1 文件的三级指针块).
现只能分析收集到的二级指针块, 对有大量的二级指针块的指向数据进行 DUMP, 然后再从磁盘中的数据定位到二级指针. 这样得到大量 DUMP 的数据.
3,FreeNAS 文件系统 -- 开始分析 VMFS 层:
重格式化过 VMFS, 和原始 UFS2 的指针已丢失, 造成 VMFS 元文件已基本上不可用, 无重要的参考信息, 所幸虚拟机都无快照, 仍可恢复. 通过单台虚拟机层 (Windows(NTFS) 和 FreeBSD(UFS2)系统的文件系统结构), 向上定位到 VMFS 层, 在通过 VMFS 层定位到 DUMP 出的单个 64GB 文件, 通过多次组合, 最终这三台重要的虚拟机的虚拟磁盘都已恢复. 将恢复出的网页数据和数据库数据上传到一新构建的系统中, 拉起应用, 数据无问题.
[ESXi5 虚拟化系统恢复结果]
经用户验收, 数据无误, 至此数据恢复工作结束.
来源: http://www.bubuko.com/infodetail-3293424.html