導致 51cto 地方 校驗 信息 map ibm 故障 搭建

一、故障描述

整個服務器的存儲空間由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能夠正常使用，本次服務器存儲數據恢復成功。

服務器數據恢復案例探究