一、故障描述
北京一家医院的EMC FC AX-4存储崩溃、raid瘫痪。北亚数据恢复中心接到客户电话后第一时间安排工程师携带服务器赶赴用户现场。经过工程师初检发现存储空间由1TB STAT的硬盘共12块组成raid5，其中两块是热备盘，目前设备中有两块硬盘损坏但只有一块热备盘激活成功，因此此raid5阵列瘫痪、上层lun无法正常使用。先对所以磁盘进行物理检测没有发现物理故障，后使用坏道检测工具进行坏道检测也没有坏道存在。</br>
</br>
二、备份数据
由于数据恢复工作的特殊性，在数据恢复之前必须对所有原始数据进行备份，在本次raid5数据恢复中我们使用winhex把全部磁盘镜像成文件，由于源磁盘的扇区大小是520字节，所以还需要使用特殊工具把所有备份的数据再做520 to 512字节的转换。
</br>
三、故障分析及恢复过程
1、分析故障原因。由于设备中并不存在物理故障和坏道，由此推断故障原因是部分磁盘读写不稳定导致的，因为EMC控制器有着非常严格的检查磁盘策略，如果发生磁盘性能不稳定的情况就会被EMC控制器认定为坏盘踢出raid组，当raid组中掉线盘达到raid级别的允许掉盘极限，此raid组即不可用，基于此raid的上层lun不可用。在本案例中只有一个lun分配给sun小机，上层文件系统是ZFS。</br>
</br>
2、分析RAID组结构。EMC存储的LUN都是基于RAID组的，因此需要先分析底层RAID组的信息，然后根据分析的信息重构原始的RAID组。通过对所有硬盘数据分析发现8号盘和11号盘完全没有数据，从管理界面上可以看到8号盘和11号盘都属于Hot Spare，但8号盘的Hot Spare替换了5号盘的坏盘。因此可以判断虽然8号盘的Hot Spare虽然成功激活，但由于RAID级别为RAID5，此时RAID组中还缺失一块硬盘，所以导致数据没有同步到8号硬盘中（frombyte.com）。继续分析其他10块硬盘，分析数据在硬盘中分布的规律，RAID条带的大小，以及每块磁盘的顺序。
</br>
3、分析RAID组掉线盘。根据上述分析的RAID信息，尝试通过北亚自主开发的RAID虚拟程序将原始的RAID组虚拟出来。但由于整个RAID组中一共掉线两块盘，因此需要分析这两块硬盘掉线的顺序。仔细分析每一块硬盘中的数据，发现有一块硬盘在同一个条带上的数据和其他硬盘明显不一样，因此初步判断此硬盘可能是最先掉线的，通过北亚自主开发的RAID校验程序对这个条带做校验，发现除掉刚才分析的那块硬盘得出的数据是最好的，因此可以明确最先掉线的硬盘了。
</br>
4、分析RAID组中的LUN信息。由于LUN是基于RAID组的，因此需要根据上述分析的信息将RAID组重组出来。然后分析LUN在RAID组中的分配信息，以及LUN分配的数据块MAP。由于底层只有一个LUN，因此只需要分析一份LUN信息就OK了。然后根据这些信息使用北亚raid恢复(frombyte.com)程序，解释LUN的数据MAP并导出LUN的所有数据。
</br>
四、解释ZFS文件系统并修复
1、解释ZFS文件系统。利用北亚数据恢复自主开发的ZFS文件系统解释程序对生成的LUN做文件系统解释，发现程序在解释某些文件系统元文件的时候报错。于是安排开发工程师对程序做debug调试并分析程序报错原因。接着安排文件系统工程师分析ZFS文件系统是否因为版本原因，导致程序不支持。经过长达7小时的分析与调试，发现ZFS文件系统因存储突然瘫痪导致其中某些元文件损坏，从而导致解释ZFS文件系统的程序无法正常解释。
</br>
2、修复ZFS文件系统。以上分析明确了ZFS文件系统因存储瘫痪导致部分文件系统元文件损坏，因此需要对这些损坏的文件系统元文件做修复才能正常解析ZFS文件系统。分析损坏的元文件发现，因当初ZFS文件正在进行IO操作的同时存储瘫痪，导致部分文件系统元文件没有更新以及损坏。人工对这些损坏的元文件进行手工修复，保证ZFS文件系统能够正常解析。
</br>
五、导出并验证数据
利用程序对修复好的ZFS文件系统做解析，解析所有文件节点及目录结构。由于数据都是文本类型及DCM图片，需要搭建太多的环境。由用户方工程师指点某些数据进行验证，验证结果都没有问题，数据均完整。
</br>
六、数据恢复结论
由于故障发生后保存现场环境良好，没用做相关危险的操作，对后期的数据恢复有很大的帮助。整个数据恢复过程中虽然遇到好多技术瓶颈，但也都一一解决。最终在预期的时间内完成整个数据恢复，恢复的数据用户方也相当满意。
北京一家医院的EMC FC AX-4存储崩溃、raid瘫痪。北亚数据恢复中心接到客户电话后第一时间安排工程师携带服务器赶赴用户现场。经过工程师初检发现存储空间由1TB STAT的硬盘共12块组成raid5，其中两块是热备盘，目前设备中有两块硬盘损坏但只有一块热备盘激活成功，因此此raid5阵列瘫痪、上层lun无法正常使用。先对所以磁盘进行物理检测没有发现物理故障，后使用坏道检测工具进行坏道检测也没有坏道存在。</br>
</br>
二、备份数据
由于数据恢复工作的特殊性，在数据恢复之前必须对所有原始数据进行备份，在本次raid5数据恢复中我们使用winhex把全部磁盘镜像成文件，由于源磁盘的扇区大小是520字节，所以还需要使用特殊工具把所有备份的数据再做520 to 512字节的转换。
</br>
三、故障分析及恢复过程
1、分析故障原因。由于设备中并不存在物理故障和坏道，由此推断故障原因是部分磁盘读写不稳定导致的，因为EMC控制器有着非常严格的检查磁盘策略，如果发生磁盘性能不稳定的情况就会被EMC控制器认定为坏盘踢出raid组，当raid组中掉线盘达到raid级别的允许掉盘极限，此raid组即不可用，基于此raid的上层lun不可用。在本案例中只有一个lun分配给sun小机，上层文件系统是ZFS。</br>
</br>
2、分析RAID组结构。EMC存储的LUN都是基于RAID组的，因此需要先分析底层RAID组的信息，然后根据分析的信息重构原始的RAID组。通过对所有硬盘数据分析发现8号盘和11号盘完全没有数据，从管理界面上可以看到8号盘和11号盘都属于Hot Spare，但8号盘的Hot Spare替换了5号盘的坏盘。因此可以判断虽然8号盘的Hot Spare虽然成功激活，但由于RAID级别为RAID5，此时RAID组中还缺失一块硬盘，所以导致数据没有同步到8号硬盘中（frombyte.com）。继续分析其他10块硬盘，分析数据在硬盘中分布的规律，RAID条带的大小，以及每块磁盘的顺序。
</br>
3、分析RAID组掉线盘。根据上述分析的RAID信息，尝试通过北亚自主开发的RAID虚拟程序将原始的RAID组虚拟出来。但由于整个RAID组中一共掉线两块盘，因此需要分析这两块硬盘掉线的顺序。仔细分析每一块硬盘中的数据，发现有一块硬盘在同一个条带上的数据和其他硬盘明显不一样，因此初步判断此硬盘可能是最先掉线的，通过北亚自主开发的RAID校验程序对这个条带做校验，发现除掉刚才分析的那块硬盘得出的数据是最好的，因此可以明确最先掉线的硬盘了。
</br>
4、分析RAID组中的LUN信息。由于LUN是基于RAID组的，因此需要根据上述分析的信息将RAID组重组出来。然后分析LUN在RAID组中的分配信息，以及LUN分配的数据块MAP。由于底层只有一个LUN，因此只需要分析一份LUN信息就OK了。然后根据这些信息使用北亚raid恢复(frombyte.com)程序，解释LUN的数据MAP并导出LUN的所有数据。
</br>
四、解释ZFS文件系统并修复
1、解释ZFS文件系统。利用北亚数据恢复自主开发的ZFS文件系统解释程序对生成的LUN做文件系统解释，发现程序在解释某些文件系统元文件的时候报错。于是安排开发工程师对程序做debug调试并分析程序报错原因。接着安排文件系统工程师分析ZFS文件系统是否因为版本原因，导致程序不支持。经过长达7小时的分析与调试，发现ZFS文件系统因存储突然瘫痪导致其中某些元文件损坏，从而导致解释ZFS文件系统的程序无法正常解释。
</br>
2、修复ZFS文件系统。以上分析明确了ZFS文件系统因存储瘫痪导致部分文件系统元文件损坏，因此需要对这些损坏的文件系统元文件做修复才能正常解析ZFS文件系统。分析损坏的元文件发现，因当初ZFS文件正在进行IO操作的同时存储瘫痪，导致部分文件系统元文件没有更新以及损坏。人工对这些损坏的元文件进行手工修复，保证ZFS文件系统能够正常解析。
</br>
五、导出并验证数据
利用程序对修复好的ZFS文件系统做解析，解析所有文件节点及目录结构。由于数据都是文本类型及DCM图片，需要搭建太多的环境。由用户方工程师指点某些数据进行验证，验证结果都没有问题，数据均完整。
</br>
六、数据恢复结论
由于故障发生后保存现场环境良好，没用做相关危险的操作，对后期的数据恢复有很大的帮助。整个数据恢复过程中虽然遇到好多技术瓶颈，但也都一一解决。最终在预期的时间内完成整个数据恢复，恢复的数据用户方也相当满意。
本文转自 宋国建 51CTO博客，原文链接：http://blog.51cto.com/sun510/2045148，如需转载请自行联系原作者
