EMC存储Raid故障数据分析报告

一、 故障描述

用户的 EMC   FC   AX-4存储 出现 崩溃 现象 , 整个存储 空间 由 12 块 1TB STAT 的硬盘组成的，其中 10块硬盘组成一个RAID5的阵列，其余两块做成热 备盘使用。 由于 RAID5阵列中出现2块硬盘损坏，而此时只有一块热备盘成功激活，因此导致RAID5阵列瘫痪，上层LUN无法正常使用。

二、检测磁盘

由于存储是因为某些磁盘掉线，从而导致整个存储不可用。因此接收到磁盘以后先对所有磁盘做物理检测，检测完后发现没有物理故障。接着使用坏道检测工具检测磁盘坏道，发现也没有坏道。

三、 备份数据

考虑到数据的安全性以及可还原性，在做数据恢复之前需要对所有源数据做备份，以防万一其他原因导致数据无法再次恢复。使用 winhex 将所有磁盘都镜像成文件，由于源磁盘的扇区大小为 520 字节，因此还需要使用特殊工具将所有备份的数据再做 520  to 512 字节的转换。

四、故障分析 及恢复过程

1、分析故障原因

由于前两个步骤并没有检测到磁盘有物理故障或者是坏道，由此推断可能是由于某些磁盘读写不稳定导致故障发生。因为 EMC 控制器检查磁盘的策略很严格，一旦某些磁盘性能不稳定， EMC 控制器就认为是坏盘，就将认为是坏盘的磁盘踢出 R AID 组。而一旦 R AID 组中掉线的盘到达到 RAID 级别允许掉盘的极限，那么这个 RAID 组将变的不可用，上层基于 RAID 组的 LUN 也将变的不可用。目前初步了解的情况为基于 RAID 组的 LUN 只有一个，分配给 SUN 小机使用，上层文件系统为 ZFS 。

2、分析RAID组结构

EMC 存储的 LUN 都是基于 RAID 组的，因此需要先分析底层 RAID 组的信息，然后根据分析的信息重构原始的 RAID 组。分析每一块数据盘， 发现 8 号盘和 11 号盘完全没有数据，从管理界面上可以看到 8 号盘和 11 号盘都属于 H ot Spare ，但 8 号盘的 Hot Spare 替换了 5 号盘的坏盘。因此可以判断虽然 8 号盘的 Hot Spare 虽然成功激活，但由于 RAID 级别为 RAID5 ，此时 RAID 组中还缺失一块硬盘，所以导致数据 没有同步到 8 号硬盘中。继续分析其他 10 块硬盘，分析数据在硬盘中分布的规律， RAID 条带的大小，以及每块磁盘的顺序。

3、分析RAID组掉线盘

根据上述分析的 RAID 信息，尝试通过北亚自主开发的 RAID 虚拟程序将原始的 RAID 组虚拟出来 。但由于整个 RAID 组中一共掉线两块盘，因此需要分析这两块硬盘掉线的顺序。仔细分析每一块硬盘中的数据，发现有一块硬盘在同一个条带上的数据和其他硬盘明显不一样，因此初步判断此硬盘可能是最先掉线的，通过北亚自主开发的 RAID 校验程序对这个条带做校验，发现除掉刚才分析的那块硬盘得出的数据是最好的，因此可以明确最先掉线的硬盘了。

4、分析RAID组中的LUN信息

由于 LUN 是基于 RAID 组的，因此需要根据上述分析的信息将 RAID 组重组出来 。然后分析 LUN 在 RAID 组中的分配信息，以及 LUN 分配的数据块 MAP 。由于底层只有一个 LUN ，因此只需要分析一份 LUN 信息就 OK 了。然后根据这些信息 使用北亚 raid 恢复 ( datahf.net ) 程序，解释 LUN 的数据 MAP 并导出 LUN 的所有数据。

五、 解释 ZFS文件系统并修复

1、 解释 ZFS文件系统

利用北亚数据恢复 ( datahf.net ) 自主开发的 Z FS 文件系统解释程序对生成的 LUN 做文件系统解释，发现程序在解释某些文件系统元文件的时候报错。迅速安排开发工程师对程序做 debug 调试，分析程序报错原因。接着安排文件系统工程师分析 ZFS 文件系统是否因为版本原因，导致程序不支持。经过长达 7 小时的分析与调试，发现 ZFS 文件系统因存储突然瘫痪导致其中某些元文件损坏，从而导致解释 ZFS 文件系统的程序无法正常解释。

2、 修复 ZFS文件系统

上述分析明确了 ZFS文件系统因存储瘫痪导致部分文件系统元文件损坏，因此需要对这些损坏的文件系统元文件做修复，才能正常解析ZFS文件系统。分析损坏的元文件发现，因当初ZFS文件正在进行IO操作的同时存储瘫痪，导致部分文件系统元文件没有更新以及损坏。人工对这些损坏的元文件进行手工修复，保证ZFS文件系统能够正常解析。

六、 导出所有数据

利用程序对修复好的 ZFS 文件系统做解析，解析所有文件节点及目录结构。部分文件目录截图如下：

七、验证最新数据

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

八、数据恢复结论

由于故障发生后保存现场环境良好，没用做相关危险的操作，对后期的数据恢复有很大的帮助。整个数据恢复过程中虽然遇到好多技术瓶颈，但也都一一解决。最终在预期的时间内完成数据恢复，经用户验收数据无误，至此数据恢复工作结束。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31380569/viewspace-2645863/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31380569/viewspace-2645863/