【故障概述】
华为S5300存储系统，配置了多种容量FC硬盘共计12块，其中包括450GB和600GB的硬盘。这些硬盘中，有11块构建了RAID5阵列，另外一块作为热备盘使用。但在运行过程中，由于RAID5阵列中连续发生了两次硬盘故障，导致阵列瘫痪，从而使得上层LUN无法正常使用。
【数据恢复流程详解】
一、磁盘初步检查与深入分析
首先对所有磁盘进行物理检测，确定故障来源。检测结果显示，除一块硬盘存在明显物理故障外，其余硬盘状态正常。针对这一情况，我们深入分析了存储系统的日志和配置信息，以找出故障的根本原因。
二、数据安全性保障
在数据恢复过程中，保证数据的安全性和可还原性至关重要。我们使用dd命令和winhex工具将所有磁盘镜像为文件，以便在恢复过程中进行比对和验证。
三、详细的故障分析与处理
1. 原因探究：结合磁盘检测和日志分析的结果，我们判断故障原因可能与部分磁盘的读写不稳定及物理故障有关。华为S5300存储系统的控制器对磁盘检测策略严格，一旦检测到性能不稳定，便会将相关磁盘踢出RAID组。当RAID组中的掉线磁盘数量达到阈值，整个RAID组及上层LUN将变得不可用。初步判断承载Oracle数据库的重要数据盘出现了同步损坏。
2. RAID组结构重构：由于LUN是基于RAID组构建的，我们需要深入分析RAID组的信息以重构原始RAID组。通过比较各数据盘的分布情况以及Oracle数据库的页面分布，我们获取了RAID组的条带大小、磁盘顺序以及数据走向等重要信息。
3. 损坏硬盘的精准识别：利用北亚自主开发的RAID虚拟程序尝试虚拟出原始RAID组，对两块掉线硬盘以及一块同步损坏硬盘进行详细分析。我们发现其中一块硬盘在相同条带上的数据与其他硬盘存在明显差异，经过北亚的RAID校验程序验证后，确定此硬盘为被同步损坏的硬盘。
4. LUN数据的提取与解析：根据最新的RAID组状态，我们虚拟出LUN在RAID组中的分配情况，并提取LUN的数据块MAP。基于此信息，我们编写程序解析LUN的数据MAP，并成功导出LUN的数据。
四、文件系统解析及数据库修复流程
1. EXT3文件系统解析：由于使用的是热备盘虚拟的RAID结构，EXT3文件系统无法正常挂载。我们利用北亚自主研发的文件系统解析程序进行解析，成功导出数据库文件，并交给数据库工程师进行校验和验证。
2. 数据库文件的检测与修复：使用Oracle数据库文件检测工具对数据库文件进行完整性检查，发现存在问题。经过更严格的北亚自主研发的检测工具的进一步检查，我们发现部分数据库文件和日志文件存在错误。数据库工程师对这些问题文件进行了修复工作，包括创建控制文件、创建undo表空间、启动数据库至mount状态等步骤。但由于system数据文件存在坏块导致数据库无法打开，需要通过搭建数据库环境并使用dmp文件还原数据库。在导入过程中我们特别注意避免导入错误和数据丢失的问题。最终通过用户方的验证，数据恢复成功完成。
