苏州某公司FreeNAS+ESXi5数据丢失恢复过程
此公司使用一种廉价的存储模式,用iSCSI方式来达到FC SAN的功能。物理存储构架在一台 DELL 服务器上,使用 FreeNAS 来做 iSCSI,然后使用两台 DELL 服务器做 ESXi5.0 的的虚拟化系统。FreeNAS 层为UFS2文件系统,整个存储建一个稀疏模式的文件,挂给ESXi5.0 系统。ESXi系统内跑有5台虚拟机,其中有三台最为重要。
一台windows2003系统虚拟机是此公司在当地的门户网站。使用 ASP.net和 PHP 混合构架,使用数据库为 SqlServer2005和 mysql 5.1 。
一台为FreeBSD 系统,跑有 Mysql数据库,供其它多台虚拟机使用。
一台为windows2003服务器,存储此公司新开发的程序代码。
【故障现象】
在一次存储突然断电之后,ESXi系统连不存储,管理员在FreeNAS中发现UFS2文件系统出现问题,然后管理员用fsck 修复好了文件系统,此时 ESXi 系统已能连上存储,但发现ESXi系统未能识别到原来的数据存储和VMFS文件系统,管理员格式化VMFS后,发现里面空无一物。
【数据恢复过程】
客户找到了几家数据恢复公司,耗时一个星期,仍无结果。事情太过于复杂。后经上海某运维公司介绍,客户联系上了我们。在进行详细沟通后制定了一个详细的数据恢复方案,经客户认可后工程师直接飞往苏州进行数据恢复。
分析故障,最大化利用可用信息。
开始抽丝剥茧:
应用构架层次:FreeNAS(UFS2文件系统–> 一个大的稀疏模式的文件) –> ESXi 5.0(VMFS文件系统层) -> 单台虚拟机的虚拟磁盘 (windows-NTFS文件系统/FreeBSD-UFS2文件系统)。
第一步是镜像 FreeNAS 层,然后分析整个存储,发现就一个900多GB的大文件,文件名: iscsidata。
通过UFS2文件系统的二进制结构,定位到 iscsidata 文件的Inode数据,发现此文件被重建过,inode指针指向的数据量很少。
FreeNAS层无法解决,就无法进入到下一步的 VMFS层分析。
收集UFS2文件系统的重要结构:
块大小:16KB
Segment 大小:2KB
柱面组大小:188176 KB
UFS2一个数据指针占 8字节,一个块可存储 2048个数据指针。
那么一个二级指针块则可存储:2048*2048*16KB= 64GB 数据。
一个三级指针块则可存储 64GB*2048= 128TB 数据
如果能找到 iscsidata 文件的三级指针块就能解决 FreeNAS层问题。
但iscsidata文件重建过,过程和大小都和原始的一样,估计有部分指针块已被覆盖。
原始 iscsidata 文件的 inode和新建的 iscsidata 文件的 inode 就在一个位置,尝试进行搜索,无其它有用的inode出现。
只得现场写程序收集有用的指针块:
图一:
image002
由于iscsidata文件是使用稀疏模式,收集条件只能放宽,收集到了大量三级指针块和二级指针块。对收集到的所有三级指针块进行分析,都是无效的,无iscsidata文件使用的三级指针块,估计在新建iscsidata文件时被新的覆盖(新的iscsidata文件在挂载到ESXi5.0后有个VMFS格式化过程,而 ESXi5.0 使用GPT分区,GPT分区会在磁盘最后写入冗余的GPT头和分区表信息数据,这样会使用iscsidata文件的三级指针块)。
现只能分析收集到的二级指针块,对有大量的二级指针块的指向数据进行DUMP,然后再从磁盘中的数据定位到二级指针。
这样得到大量DUMP的数据。
开始分析 VMFS 层:
重格式化过VMFS,和原始UFS2的指针已丢失,造成VMFS元文件已基本上不可用,无重要的参考信息,所幸虚拟机都无快照,仍可恢复。
通过 单台虚拟机层(windows(NTFS)和 FreeBSD(UFS2)系统的文件系统结构),向上定位到VMFS层,在通过VMFS层定位到DUMP出的单个64GB 文件,通过多次组合,最终这三台重要的虚拟机的虚拟磁盘都已完全恢复。
客户将恢复出的网页数据和数据库数据上传到一新构建的系统中,拉起应用,数据完全无问题。
图二:
image004
【数据恢复结果】
耗时2天,最终数据100% 恢复成功。
【数据恢复服务标准】
1. 免费检测
2. 与客户签订保密协议,对客户的数据严格保密
3. 数据恢复不成功不收费
4. 专业工程师提供服务
5. 数据恢复前报价,客户确认后工程师开始数据修复
6. 整个恢复过程不会对客户的原盘有任何的写操作,以确保原盘的数据完全