这种方式解决EMC存储崩溃RAID离线问题，简单又高效

故障描述：
因为RAID5阵列中出现2块硬盘损坏，而此时只有一块热备盘成功激活，所以致使RAID5阵列瘫痪，上层LUN没法正常使用，整个存储空间由12块1TB SATA的硬盘组成的，其中10块硬盘组成一个RAID5的阵列，其他两块作成热备盘使用。
因为前两个步骤并无检测到磁盘有物理故障或者是坏道，由此推断多是因为某些磁盘读写不稳定致使故障发生。由于EMC控制器检查磁盘的策略很严格，一旦某些磁盘性能不稳定，EMC控制器就认为是坏盘，就将认为是坏盘的磁盘踢出RAID组。而一旦RAID组中掉线的盘到达到RAID级别容许掉盘的极限，那么这个RAID组将变的不可用，上层基于RAID组的LUN也将变的不可用。目前初步了解的状况为基于RAID组的LUN只有一个，分配给SUN小机使用，上层文件系统为ZFS。
解决过程
一、硬盘检测
因为存储是由于某些磁盘掉线，从而致使整个存储不可用。所以接收到磁盘之后先对全部磁盘作物理检测，检测完后发现没有物理故障。接着使用坏道检测工具检测磁盘坏道，发现也没有坏道。

二、备份数据
考虑到数据的安全性以及可还原性，在作数据恢复以前须要对全部源数据作备份，以防万一其余缘由致使数据没法再次恢复。使用winhex将全部磁盘都镜像成文件，因为源磁盘的扇区大小为520字节，所以还须要使用特殊工具将全部备份的数据再作520 to 512字节的转换。
三、分析RAID组结构
EMC存储的LUN都是基于RAID组的，所以须要先分析底层RAID组的信息，而后根据分析的信息重构原始的RAID组。分析每一块数据盘，发现8号盘和11号盘彻底没有数据，从管理界面上能够看到8号盘和11号盘都属于Hot Spare，但8号盘的Hot Spare替换了5号盘的坏盘。所以能够判断虽然8号盘的Hot Spare虽然成功激活，但因为RAID级别为RAID5，此时RAID组中还缺失一块硬盘，因此致使数据没有同步到8号硬盘中。继续分析其余10块硬盘，分析数据在硬盘中分布的规律，RAID条带的大小，以及每块磁盘的顺序。
四、分析RAID组掉线盘
根据上述分析的RAID信息，尝试经过北亚自主开发的RAID虚拟程序将原始的RAID组虚拟出来。但因为整个RAID组中一共掉线两块盘，所以须要分析这两块硬盘掉线的顺序。仔细分析每一块硬盘中的数据，发现有一块硬盘在同一个条带上的数据和其余硬盘明显不同，所以初步判断此硬盘多是最早掉线的，经过北亚自主开发的RAID校验程序对这个条带作校验，发现除掉刚才分析的那块硬盘得出的数据是最好的，所以能够明确最早掉线的硬盘了。
五、分析RAID组中的LUN信息
因为LUN是基于RAID组的，所以须要根据上述分析的信息将RAID组重组出来。而后分析LUN在RAID组中的分配信息，以及LUN分配的数据块MAP。因为底层只有一个LUN，所以只须要分析一份LUN信息就OK了。而后根据这些信息使用北亚raid恢复(datahf.net)程序，解释LUN的数据MAP并导出LUN的全部数据。
六、解释ZFS文件系统并修复
利用北亚数据恢复(datahf.net自主开发的ZFS文件系统解释程序对生成的LUN作文件系统解释，发现程序在解释某些文件系统元文件的时候报错。迅速安排开发工程师对程序作debug调试，分析程序报错缘由。接着安排文件系统工程师分析ZFS文件系统是否由于版本缘由，致使程序不支持。通过长达7小时的分析与调试，发现ZFS文件系统因存储忽然瘫痪致使其中某些元文件损坏，从而致使解释ZFS文件系统的程序没法正常解释。
上述分析明确了ZFS文件系统因存储瘫痪致使部分文件系统元文件损坏，所以须要对这些损坏的文件系统元文件作修复，才能正常解析ZFS文件系统。分析损坏的元文件发现，因当初ZFS文件正在进行IO操做的同时存储瘫痪，致使部分文件系统元文件没有更新以及损坏。人工对这些损坏的元文件进行手工修复，保证ZFS文件系统可以正常解析。
七、导出全部数据
利用程序对修复好的ZFS文件系统作解析，解析全部文件节点及目录结构。部分文件目录截图以下：

八、验证最新数据
因为数据都是文本类型及DCM图片，须要搭建太多的环境。由用户方工程师指点某些数据进行验证，验证结果都没有问题，数据均完整。部分文件验证以下: