IBM伺服器硬碟離線資料恢復方法

伺服器資料恢復背景介紹：
客戶的一臺ibm x3850X5伺服器上有兩塊硬碟由於未知故障離線，導致伺服器資料丟失，需要進行資料恢復。資料恢復中心安排伺服器資料恢復工程師對客戶的故障伺服器進行初檢，客戶伺服器由5塊硬碟組成raid5磁碟陣列、linux redhat 5.3作業系統、儲存一個oracle資料庫。陣列中有兩塊硬碟處於離線狀態，熱備盤未啟用。硬碟無物理故障，無明顯同步表現。

資料恢復中心資料恢復方案：
將故障伺服器關機並保證在資料恢復過程中保持伺服器關機狀態，將故障盤進行標記後取出槽位掛載至資料恢復的備份伺服器環境進行映象備份。完成後恢復原故障伺服器。
分析備份盤中的raid結構，得到原陣列中的raid界別、條帶大小、校驗方向、條帶規則以及meta區域等資訊。
根據分析出來的raid資訊虛擬搭建一組raid5環境對磁碟檔案系統進行解釋，對虛擬結構的正確性檢測，資料無誤即可回遷資料。

伺服器資料恢復及系統復原過程：
3. 對原硬碟映象後發現除了2號盤有10-20個壞扇區外其他硬碟均正常。
4. 對raid結構進行分析，最佳盤序結構是0-1-2-3，缺失3號盤，結構如下圖：

組好後資料驗證，200M以上的最新壓縮包解壓無報錯，按照這一結構將虛擬raid生成到一塊硬碟上，透過USB的方式把恢復後的單盤接入原伺服器，透過linux SystemRescueCd啟動故障伺服器後使用dd命令進行全盤迴寫。
6. 資料回寫完成後無法進入作業系統，報錯資訊為：/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied。工程師使用SystemRescueCd重啟後檢查發現檔案的許可權、時間、大小都有明顯錯誤，對根分割槽再次分析定位出錯的/sbin/pidof/datahf.net，得出問題原因是2號盤壞道。
7. 透過其他盤針對2號盤的損壞區域進行xor補齊並重新校驗檔案系統，依然有錯誤，工程師只好再次對inode表進行檢查，發現2號盤損壞區域有部分節點表現為(圖中的55 55 55部分)：

可以看出雖然節點中描述的uid還正常存在，但大小、屬性、最初的分配塊全部是錯誤的。透過日誌確定原節點塊的節點資訊後進行修正，重新dd根分割槽，執行fsck -fn /dev/sda5/datahf.net檢測，報錯情況如下圖：

經過分析發現，原來3號盤最先離線，節點資訊新舊交集導致有多個節點共用資料塊，工程師按節點所屬的檔案進行區別，清除錯誤節點後，再次執行fsck -fn /dev/sda5,依然有部分位於doc目錄下的節點報錯，由於不影響啟動所以強行修復後重啟系統，系統正常，啟動資料庫正常。

伺服器資料恢復結論：
由客戶方工程師對伺服器資料進行驗證，資料正常，資料恢復100%成功。