北京某公司IBM X3650M3存储崩溃的解决过程

存储数据恢复故障情况：

北京某公司的一台IBM X3650M3存储由于未知原因崩溃，管理员排查故障时发现存储中有两块硬盘离线导致该组阵列无法使用，存储内数据丢失，需要进行raid阵列数据恢复。

Raid5阵列数据恢复检测：

数据恢复工程师赶到客户现场对raid阵列中的磁盘进行数据恢复检测发现该raid中离线的两块硬盘均没有硬件问题，直接进行raid阵列数据恢复操作即可。

Raid5阵列数据恢复过程：

1.数据恢复工程师首先将客户的raid阵列中所有磁盘使用数据恢复工具进行镜像备份，备份文件存储至数据恢复平台上，然后将客户的原存储中所有磁盘还原到原始状态交还客户，随后的数据恢复操作均在数据恢复平台中进行操作，以保障客户原始数据不被修改和破坏。
·
2.服务器数据恢复工程师对原raid阵列的镜像文件进行了仔细分析发现该raid阵列中有两块热备盘，硬盘离线时只有一块热备盘成功激活，此时raid5阵列仍然处于缺盘状态，数据并未同步。于是工程师开始分析原raid阵列中的硬盘分布规律和raid条带信息、盘序信息等，以便在后期的数据恢复工作中可以通过这些信息重组raid阵列，恢复数据。
·
3.根据上述分析的RAID信息，仔细分析每一块硬盘中的数据，发现有一块硬盘在同一个条带上的数据和其他硬盘明显不一样，因此初步判断此硬盘可能是最先掉线的，工程师使用一款自用的RAID校验程序对这个条带进行校验发现除掉刚才分析的那块硬盘得出的数据是最好的，因此可以明确最先掉线的硬盘了。
·
4.数据恢复工程师根据分析来的raid信息重组raid阵列，再通过重组出的raid阵列分析lun的分配和数据块情况，在使用数据恢复软件导出lun并解析文件系统时文件系统提示报错，工程师重新调试数据恢复软件后报错情况依然存在，可以排除软件故障导致文件系统解析报错，于是对导出的文件进行手动检查发现导致数据恢复软件解析报错的原因为文件系统元文件损坏导致软件无法自动解析而报错。出现这种情况的原因可能是因为存储瘫痪时zfs文件正在进行IO操作，导致的文件系统元文件没有更新和元文件损坏（后来证明的确如此）。由于数据恢复软件无法继续解析文件系统，只好由工程师手动进行zfs文件系统中损坏的元文件进行修复后再进行解析。
·
5.将修复好的文件系统再次使用数据恢复软件进行解析，成功解析所有文件节点和文件目录结构，将数据导出。

Raid5数据恢复结果：

用户在数据恢复平台上对导出的数据进行验证，数据恢复成功。

转载于:https://blog.51cto.com/sun510/2153209