共计 1671 个字符，预计需要花费 5 分钟才能阅读完成。
服务器数据恢复环境：
6 块 SAS 硬盘中的 5 块硬盘组成一个 RAID5 的阵列，1 块作为热备盘应用。
服务器故障：
RAID5 中 1 块硬盘故障，热备盘激活开始同步数据，在同步数据过程中又有一块硬盘故障离线，导致 RAID5 瘫痪，下层 LUN 无奈失常应用。
服务器故障检测和备份：
1、检测磁盘。初步判断是 RAID 阵列中某些磁盘掉线导致存储不可用。因而在接管到磁盘当前先对所有磁盘做物理检测，检测发现只有一块硬盘有物理故障。
2、备份数据。将所有磁盘都镜像成文件，备份过程中也没有发现其余磁盘物理故障。
服务器故障剖析：
1、剖析故障起因
因为 IBM 存储控制器对于磁盘的检测策略很严格，磁盘性能不稳固也会被 IBM 存储控制器断定为坏盘并踢出 RAID 组。因而检测出的故障磁盘有可能是读写不稳固，也有可能存在物理故障。而一旦 RAID 中掉线盘数超过这组 RAID 自身容许掉盘的最大数量，那么这个 RAID 组将不可用，基于 RAID 组的 LUN 也将不可用，因而导致数据失落
2、剖析 RAID 组构造
IBM 存储的 LUN 都是基于 RAID 组的，因而须要先剖析底层 RAID 组的信息，而后利用剖析获取到的信息重构原 RAID 组。剖析每一块数据盘，如果那块盘的数据同其它数据盘不太一样，能够初步认定为 HotSpare 盘。剖析其余数据盘，剖析 Oracle 数据库页在每个磁盘中散布的状况，并依据数据分布的状况得出 RAID 组的条带大小，磁盘程序及数据走向等 RAID 组的重要信息。
3、剖析 RAID 组中的 LUN 信息
因为 LUN 是基于 RAID 组的，因而须要根据上述获取到的信息将 RAID 组虚构重组进去，而后剖析 LUN 在 RAID 组中的分配情况，以及 LUN 调配的数据块 MAP。只须要将 LUN 的数据块散布 MAP 提取进去。而后针对这些信息编写相应的程序，对 LUN 的数据 MAP 做解析，而后依据数据 MAP 导出 LUN 的数据。
服务器数据恢复解决方案：
1、实施方案一
对复原的蕴含 Oracle 数据库的 LUN 进行 JFS2 文件系统解析，并对文件系统不残缺的局部进行人工修复。利用北亚自主开发的 JFS2 文件系统解析工具解析复原的 LUN，而后复原文件系统中所有的 Oracle 数据库文件，并检测 Oracle 数据库的文件是否残缺。对检测有坏块的数据库文件所在磁盘进行扫描 Oracle 碎片操作，将扫描到的数据页进行组合，而后将有坏块的数据库文件通过人工的形式填补修复残缺。在实现所有 Oracle 数据库文件的复原之后，利用 SAP 还是无奈失常应用。SAP 利用的一些重要数据寄存在损坏的存储中，缺失这些数据会导致 SAP 即便在数据库残缺的状况下也无奈失常应用，因而还需采纳计划二来复原所有 SAP 的重要数据。
2、实施方案二
对复原进去的所有 LUN 进行文件系统解析，将蕴含 SAP 的数据 LUN 进行文件系统的一致性检测。对文件系统不残缺的局部进行人工修复，最初复原所有 SAP 及 SAP Test 的数据。对 SAP 的数据进行检测，并对损坏的数据进行修复，确保复原进去的 SAP 数据是残缺的，这样能力保障 SAP 利用可能残缺启动。利用复原的 SAP 数据联合之前复原进去的 Oracle 数据库，即可启动 SAP 及所有利用。
启动并修复 Oracle 数据及 SAP 利用：
1、启动 Oracle 数据库并修复
把复原进去的数据库文件还原到已搭建好的环境中，并尝试启动数据库。在启动过程中因为数据库的一些临时文件校验不统一导致数据库启动失败。协调 Oracle 数据库工程师近程对数据库进行修复后，数据库失常启动，数据残缺，而后尝试启动 SAP。
2、启动 SAP 并修复
将复原的 SAP 文件还原至已搭建好的环境中，并依照之前的启动脚本启动 SAP，SAP 启动失常，但 SAP 中用户权限及应用不失常，SAP 体现为没有序列号。初步判断是 SAP 的注册文件没有复原，从新检测复原过程，排查可能出问题的局部。排查后发现是因为文件系统的损坏而导致某些文件没有复原胜利。从新修复文件系统，复原这些数据。启动 SAP 失常，应用失常。
数据验证：
启动 Oracle 数据库，启动 SAP，通过 SAP 客户端验证 SAP 中所有的数据，数据恢复残缺，SAP 能失常应用。
