服务器数据恢复环境：
某品牌存储中12块SAS硬盘组成RAID6，分成一个卷，分配给几台Vmware ESXI主机做共享存储；
卷中存放一定数量的Windows虚拟机，数据盘都是精简模式。
服务器存储故障：
机房断电后开机存储不可用。经过管理员检测诊断后初步判断是断电导致的存储阵列瘫痪。服务器管理员联系我们数据恢复中心进行数据恢复。
服务器存储数据恢复过程：
1、服务器数据恢复工程师将故障存储的所有磁盘连接到一台Windows Server服务器上，故障磁盘都设为脱机（只读）状态，连接状态如下图所示：(图中HD1-HD12为目标备份磁盘，HD13-HD24为源故障磁盘)：
2、使用工具以底层方式读取HD13-HD24的扇区时发现了大量扇区损坏，初步判断这种硬盘的读取机制比较独特。尝试更换操作主机、HBA卡、扩展柜和操作系统，但均出现相同故障。与服务器管理员沟通后得知此控制器对磁盘其实没有特殊要求。
3、使用专业工具对硬盘损坏扇区的分布规律进行检测，结果发现：
a、损坏扇区分布以256个扇区为单位。
b、除损坏扇区片段的起始位置不固定外，后面的损坏扇区都是以2816个扇区为间隔。所有磁盘的损坏扇区分布如下表（只列出前3个损坏扇区）：
北亚服务器数据恢复工程师临时编写小程序，跳过每块磁盘的损坏扇区，镜像完所有磁盘的数据。
服务器存储故障分析：
1、分析损坏扇区。
分析损坏扇区发现损坏扇区呈规律性出现：每段损坏扇区区域大小总为256；损坏扇区分布为固定区域，每跳过11个256扇区遇到一个坏的256扇区；损坏扇区的位置一直存在于RAID的P校验或Q校验区域；所有硬盘中只有10号盘中有一个自然坏道。
2、分析分区大小。
对HD13、HD23、HD24的0-2扇区做分析，结果发现分区大小和控制器中保留的RAID信息区域大小吻合。根据物理硬盘底层的表现发现原存储并未启用存储中常用的DA技术(520字节扇区）。
分区大小如下图(GPT分区表项底层表现，涂色部分表示分区大小，单位512字节扇区，64bit)：
3、重组RAID：
a、分析RAID结构。
存储使用的是标准的RAID6，只需要获取到RAID中硬盘数量以及RAID的走向就可以重组RAID。
b、分析RAID条带大小。
整个存储被分成一个卷分配给几台ESXI做共享存储。卷的文件系统是VMFS文件系统，而VMFS卷中又有存放了大量的Windows虚拟机。Windows虚拟机中大多使用的是NTFS文件系统，因此可以根据NTFS中的MFT的顺序分析出RAID条带的大小以及RAID的走向。
c、分析RAID是否存在掉线盘。
镜像完所有磁盘后发现最后一块硬盘中并没有像其他硬盘一样有大量的坏道，其中有大量未损坏扇区，这些未损坏扇区大多是全0扇区，因此可以判断这块硬盘是热备盘。
d、重组RAID
根据分析获取到的RAID信息重组RAID，重组后能看到目录结构，但是不确定是否为最新状态。服务器数据恢复工程师随机检测了几个虚拟机发现部分虚拟机正常，初步判断RAID中存在掉线的磁盘。依次将RAID中的每一块磁盘踢掉，然后查看刚才数据异常的地方但并没有发现问题。仔细分析底层数据发现问题不是出在RAID层面，而是出在VMFS文件系统上。VMFS文件系统如果大于16TB的话会存在一些其他的记录信息，因此在组建RAID的时候需要跳过这些记录信息。再次重组RAID后针对其中的一台虚拟机做验证，发现将所有磁盘加入RIAD后这台虚拟机是可以启动的，但在缺盘的情况下启动就有问题，因此可以判断RAID不缺盘的状态为最佳。
4、验证数据：
a、验证虚拟机。
对较为重要的虚拟机做验证，发现虚拟机大多可以开机进入登录界面；部分虚拟机开机蓝屏或开机检测磁盘，使用光盘修复后都可以启动。
部分虚拟机开机如下：
b、验证数据库。
对重要虚拟机中的数据库做验证没有发现问题，除了其中一个数据库缺少部分数据。经过仔细核对后发现这些数据在数据库中本来就不存在。通过查询master数据库中的系统视图，查出原来的所有数据库信息如下：
c、检测整个VMFS卷是否完整。
由于虚拟机数量很多，如果每台都去做验证所花费时间太长。我们对整个VMFS卷做检测发现部分虚拟机或虚拟机的文件被破坏，列表如下：
5、恢复数据：
a、服务器数据恢复工程师和管理员沟通了目前数据恢复的情况。管理员对几台重要的虚拟机进行验证后，用户反馈恢复出来的数据没有问题。数据恢复工程师立即着手恢复所有数据。
b、准备好目标阵列，将重组的RAID数据镜像到目标阵列上。然后利用工具解析整个VMFS文件系统。由于部分虚拟机的数据盘很大但数据很少，可以直接导出数据然后新建一个虚拟磁盘，最后将导出的数据拷贝至新建的虚拟磁盘中即可。
c、通过上述方法将恢复出来的虚拟机一台一台的恢复到用户的ESXI中。后续的数据迁移过程中由北亚数据恢复工程师和用户方工程师配合完成，这里就不赘述了。
数据恢复结果：
本案例存储故障是由坏道引起的，最终恢复出来的数据也有部分损坏，但不影响整体数据，最终的结果也在接受范围内。
阅读(362) | 评论(0) | 转发(0) |
