-4006-505-646 -4006-505-646 本次分享的案例是由于机房突然断电导致整个存储瘫痪，加电后存储依然无法使用。经过用户方工程师诊断后认为是断电导致存储阵列损坏。整个存储是由12块盘组成的RAID-6磁盘阵列，被分成一个卷，分配给几台Vmware的ESXI主机做共享存储。整个卷中存放了大量的Windows虚拟机，虚拟机基本都是模板创建的，系统盘都为统一大小，数据盘大小不确定，并且数据盘都是精简模式。
将故障存储的所有磁盘和备份sss数据的目标磁盘连入到一台Windows Server 2008的服务器上。以底层方式读取扇区，发现了大量损坏扇区。初步判断可能是这种硬盘的读取机制与常见的硬盘不一样。尝试更换操作主机，更换HBA卡，更换扩展柜，更换为Linux操作系统，均呈现相同故障。跟用户沟通了解到控制器对磁盘没有特殊要求。使用专业工具对硬盘损坏扇区的分布规律进行检测，发现损坏扇区分布以256个扇区为单位，除损坏扇区片断的起始位置不固定外，后面的损坏扇区都是以2816个扇区为间隔。临时写了个小程序，对每个磁盘的损坏扇区做绕过处理，用此程序镜像完所有盘的数据。
【分析故障情况】
对损坏扇区进行分析，分析后发现，损坏扇区呈规律性出现。每段损坏扇区区域大小总为256；损坏扇区分布为固定区域，每跳过11个256扇区遇到一个坏的256扇区；损坏扇区的位置一直存在于RAID的P校验或Q校验区域，所有硬盘中只有10号盘中有一个自然坏道。
【RAID重组】
1、分析RAID结构：存储使用的是标准的RAID-6阵列，接下来只需要分析出RAID 成员数量以及RAID的走向就可以重组RAID。
2、分析RAID条带大小：整个存储被分成一个大的卷，分配给几台ESXI做共享存储，因此卷的文件系统肯定是VMFS文件系统。而VMFS卷中又有存放了大量的Windows 虚拟机。Windows虚拟机中大多使用的是NTFS文件系统，因此可以根据NTFS中的MFT的顺序分析出RAID条带的大小以及RAID的走向。
3、分析RAID是否存在掉线盘：镜像完所有磁盘。后发现最后一块硬盘中并没有像其他硬盘一样有大量的坏道。其中有大量未损坏扇区，这些未损坏扇区大多是全0扇区。因此可以判断这块硬盘是热备盘。
4、重组RAID
根据分析出来的RAID结构重组RAID，能看到目录结构。但是不确定是否为最新状态，检测几个虚拟机发现有部分虚拟机正常，但也有很多虚拟机数据异常。初步判断RAID中存在掉线的磁盘，依次将RAID中的每一块磁盘踢掉，然后查看刚才数据异常的地方，未果。又仔细分析底层数据发现问题不是出在RAID层面，而是出在VMFS文件系统上。VMFS文件系统如果大于16TB的话会存在一些其他的记录信息，因此在组建RAID的时候需要跳过这些记录信息。再次重组RAID，查看以前数据异常的地方可以对上了。针对其中的一台虚拟机做验证，将所有磁盘加入RAID中后，这台虚拟机是可以启动的，但缺盘的情况下启动有问题。因此判断整个RAID处在不缺盘的状态为最佳。
【数据验证及结果】
针对用户较为重要的虚拟机做验证，发现虚拟机大多都可以开机，可以进入登陆界面。有部分虚拟机开机蓝屏或开机检测磁盘，但是光盘修复之后都可以启动。针对重要的虚拟机中的数据库做验证，发现数据库都正常。
检测整个VMFS卷是否完整
由于虚拟机的数量很多，每台都验证的话，所需的时间会很长，用户对部分较为重要的虚拟机进行了验证，用户对验证结果还是比较满意的。由于部分虚拟机的数据盘很大，而数据很少。像这种情况就可以直接导出数据，然后新建一个虚拟磁盘，最后将导出的数据拷贝至新建的虚拟磁盘中即可。
统计了一下整个存储中虚拟机的数量，大约有200台虚拟机。目前的情况只能通过上述方式将恢复的虚拟机一台一台的恢复到用户的ESXI中。由于是通过网络传输，因此整个迁移的过程中网络是一个瓶颈。经过不断的调试以及更换主机最终还是无法达到一个理想的状态，由于时间紧张，最终还是决定在当前的环境迁移数据。
整个恢复过程，用户方要求紧急，我方也安排工程师加班加点，最终在最短的时间内将数据恢复出来。后续的数据迁移过程中由我方工程师和用户方工程师配合完成，本次数据恢复圆满成功。
【北京北亚数据恢复中心】
地址：北京市海淀区温泉镇中光村创客小镇16号221
电话：4006-505-646
网址：www.frombyte.com