共计 1427 个字符，预计需要花费 4 分钟才能阅读完成。
服务器数据恢复环境：
IBM 某型号服务器中 6 块硬盘搭建的 raid5 磁盘阵列，其中 1 块盘作为热备盘应用。
下层部署的是 SAP 利用 +Oracle 数据库。
服务器故障 & 检测：
服务器中 RAID5 磁盘阵列中的 1 块盘呈现故障离线，热备盘激活替换离线硬盘，在进行数据同步的过程中又有一块硬盘故障离线，RAID5 磁盘阵列瘫痪，下层 LUN 不可用，服务器解体。
IBM 服务器中的 LUN 是基于 RAID 组的。剖析故障 raid5 中的所有硬盘，发现其中一块盘的数据同其它盘有显著不同，初步判断这块盘就是 HotSpare 盘。剖析其余盘以及 Oracle 数据库页在每个磁盘中的散布状况，获取到该 RAID5 的条带大小、磁盘程序及数据走向等 RAID 相干信息。利用获取到的 raid 相干信息虚构重构 RAID5，而后剖析 LUN 在 RAID5 中的分配情况以及 LUN 调配的数据块 MAP。只须要将 LUN 的数据块散布 MAP 提取进去，针对这些信息编写相应的程序，解析 LUN 的数据 MAP，而后依据数据 MAP 导出 LUN 的数据即可复原数据。
服务器数据恢复过程：
一、复原 Oracle 数据库数据。
1、将蕴含 Oracle 数据库数据的 LUN 进行 JFS2 文件系统解析，人工修复文件系统的不残缺局部。
2、利用北亚企安自主开发的 JFS2 文件系统解析工具解析修复实现的 LUN，而后复原文件系统中所有的 Oracle 数据库文件。
3、检测 Oracle 数据库文件的完整性。针对检测有坏块的数据库文件，通过扫描所有硬盘找到所有 Oracle 碎片，组合扫描到的数据页，人工将有坏块的数据库文件修复残缺。
4、复原完所有 Oracle 数据库之后，发现 SAP 利用还是无奈失常应用。通过剖析发现 SAP 利用的一些重要数据也是寄存在损坏的存储中，如果没有这些重要的数据，即便在 Oracle 数据库残缺的状况下 SAP 利用也无奈失常应用。
二、复原 SAP 利用数据。
1、对复原进去的所有 LUN 都进行文件系统解析，将蕴含 SAP 利用数据的 LUN 进行文件系统的一致性检测。人工修复文件系统不残缺局部，直至复原出所有 SAP 及 SAP Test 的数据。
2、检测复原进去的 SAP 利用数据，对损坏的 SAP 利用数据进行修复，直至所有 SAP 数据都残缺，只有这样能力保障 SAP 利用可能失常应用。
3、SAP 数据修复实现后，联合之前复原进去的 Oracle 数据库，即可启动 SAP 利用了。
三、启动并修复 Oracle 数据库及 SAP 利用
1、启动数据库并修复。
把复原的 Oracle 数据库文件还原到已搭建好的环境中，并尝试启动 Oracle 数据库。在启动过程中因为数据库一些临时文件的校验不统一导致数据库启动失败。分割 Oracle 数据库工程师对数据库进行修复，修复实现后 Oracle 数据库启动胜利，通过重复验证确认数据库中的所有用户及所有表均残缺，而后尝试启动 SAP。
2、启动 SAP 并修复。
将复原进去的 SAP 数据还原到已搭建好的环境中并启动 SAP，SAP 启动失常，但 SAP 中的用户权限及应用异样，SAP 体现为没有序列号。北亚企安数据恢复工程师初步判断是因为 SAP 的注册文件没有复原进去。从新检测复原过程，排查可能忽略的中央，后果发现的确因为文件系统损坏导致某些文件没有复原进去。从新修复文件系统并复原这些数据，而后启动并查看 SAP，后果一切正常。
3、在用户方工程师配合下启动服务器内的 Oracle 数据库和 SAP，通过 SAP 客户端重复验证 SAP 中所有的数据，没有发现任何问题，复原进去的数据残缺可用。本次数据恢复工作实现。
