服务器数据恢复环境：
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能失常应用。
发表回复