一、故障描述
整个服务器的存储空间由6块SAS硬盘组成，其中5块硬盘组成一个RAID5的阵列，剩余1块做成热备盘使用。由于RAID5阵列中出现1块硬盘故障，所以服务器存储中的热备盘成功激活，在进行同步的过程中又一块硬盘出现故障，因此导致RAID5阵列瘫痪，上层LUN无法正常使用，服务器崩溃。服务器数据恢复工程师与硬件数据恢复工程师同时对客户存储进行检测发现该服务器存储中的硬盘存在有物理故障。
·
二、服务器存储数据恢复故障检测
IBM服务器存储的LUN都是基于RAID组的，因此要进行服务器数据恢复需要先分析底层RAID组的信息，然后根据分析的信息重构原始的RAID组。分析每一块数据盘，发现一块盘的数据同其它数据盘不太一样，初步认为可能是HotSpare盘。接着分析其他数据盘，分析Oracle数据库页在每个磁盘中分布的情况，并根据数据分布的情况得出RAID组的条带大小，磁盘顺序及数据走向等RAID组的重要信息。
服务器数据恢复中由于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应用能够完整启动。
接下来利用恢复的SAP数据结合之前恢复的数据库，即可启动SAP及所有应用了。
·
四、启动并修复Oracle数据及SAP应用
1、启动数据库并修复
把恢复的数据库文件还原到已搭建好的环境中，并尝试启动数据库。在启动过程中由于数据库的一些临时文件校验不一致导致数据库启动失败，之后协调我们Oracle数据库专家远程对数据库进行修复，在经过漫长时间的修复之后，数据库启动没有问题，数据库中的所有用户及所有表均完整，之后尝试启动SAP。
2、启动SAP并修复
将恢复的SAP文件还原至已搭建好的环境中，并按照之前的启动脚本启动SAP，之后SAP启动正常，但SAP中用户权限及使用不太正常，SAP表现为没有序列号。初步怀疑可能SAP的注册文件没有恢复，重新检测恢复过程，排查可能疏忽的步骤。结果确实因为文件系统的损坏导致某些文件没有恢复，重新修复文件系统，恢复这些数据。之后启动SAP正常，使用也正常。
·
五、服务器存储数据恢复成功
由用户方配合，启动用户服务器内的Oracle数据库，启动SAP，并通过SAP客户端验证SAP中所有的数据是否完整，最有验证结果为数据完整恢复，SAP能够正常使用，本次服务器存储数据恢复成功。
标签：数据恢复,数据库,探究,服务器,SAP,数据,LUN 来源： https://blog.51cto.com/sun510/2383192
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。