172
服務器 raid5數據丟失的恢複過程
第一部分：數據恢複方案
【用戶單位】某醫藥公司
【故障描述】
IBM X3850服務器，5塊73G SAS硬盤，其中4塊組成一個RAID5，另一塊做為熱備盤(Hot-Spare)，3號盤早已經離線，但熱備盤未自動激活rebuild（原因不明），之後2號盤離線，RAID崩潰。
操作係統為linux redhat 5.3,應用係統為構架於oracle的一個oa，數據重要，時間很急。因oracle已經不再對本oa係統提供後續支持，用戶要求盡可能數據恢複+操作係統複原。
【初檢結論】
熱備盤完全無啟用，硬盤無明顯物理故障，無明顯同步表現。數據通常可恢複
【恢複方案】
1、保護原環境，關閉服務器，確保在恢複過程中不再開啟服務器。
2、將故障硬盤標好序號，確保在拿出槽位後可以完全複原。
3、將故障硬盤掛載至隻讀環境，對所有故障硬盤做完全鏡像(參考<如何對磁盤做完整的全盤鏡像備份>)。備份完成後交回原故障盤，之後的恢複操作直到數據確認無誤前不再涉及原故障盤。
4、對備份盤進行RAID結構分析，得到其原來的RAID級別，條帶規則，條帶大小，校驗方向，META區域等。
5、根據得到的RAID信息搭建一組虛擬的RAID5環境。
6、進行虛擬磁盤及文件係統解釋。
7、檢測虛擬結構是否正確，如不正確，重複4-7過程。
8、確定數據無誤後，按用戶要求回遷數據。如果仍然使用原盤，需確定已經完全對原盤做過備份後，重建RAID，再做回遷。回遷操作係統時，可以使用linux livecd或win pe(通常不支持)等進行，也可以在故障服務器上用另外硬盤安裝一個回遷用的操作係統，再進行扇區級別的回遷。
9、數據移交後，由北亞數據恢複中心延長保管數據3天，以避免可能忽略的紕漏。
【恢複周期】
備份時間，約2小時。
解釋及導出數據時間，約4小時。
回遷操作係統，約4小時。
【恢複費用】
略。。。
第二部分:數據恢複及係統複原過程
1、對原硬盤進行完整鏡像，鏡像後發現2號盤有10-20個壞扇區，其餘磁盤，均無壞道。
2、分析結構：得到的最佳結構為0,1,2,3盤序，缺3號盤，塊大小512扇區，backward parity(Adaptec)，結構如下圖：
圖一：
3、組好後數據驗證，200M以上的最新壓縮包解壓無報錯，確定結構正確。
4、直接按此結構生成虛擬RAID到一塊單硬盤上，打開文件係統無明顯報錯。
5、確定備份包安全的情況下，經客戶同意後，對原盤重建RAID，重建時已經用全新硬盤更換損壞的2號盤。將恢複好的單盤用USB方式接入故障服務器，再用linux SystemRescueCd啟動故障服務器，之後通過dd命令進行全盤回寫。
6、回寫後，啟動操作係統。正常情況下，這時候所有工作應該完成了。不巧的是，因幫頗費周折才解決，特意另起一段敘述。
係統複原過程：
dd所有數據後，啟動操作係統，無法進入，報錯信息為：/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied
懷疑此文件權限有問題，用SystemRescueCd重啟後檢查，此文件時間，權限，大小均有明顯錯誤，顯然節點損壞。
重新分析重組數據中的根分區，定位出錯的/sbin/pidof，發現問題因2號盤壞道引起。
使用0，1，3這3塊盤，針對2號盤的損壞區域進行xor補齊。補齊後重新校驗文件係統，依然有錯誤，再次檢查inode表，發現2號盤損壞區域有部分節點表現為(圖中的55 55 55部分)：
圖二：
很明顯，雖然節點中描述的uid還正常存在，但屬性，大小，以最初的分配塊全部是錯誤的。按照所有可能進行分析，確定無任何辦法找回此損壞節點。隻能希望修複此節點，或複製一個相同的文件過來。
對所有可能有錯的文件，均通過日誌確定原節點塊的節點信息，再做修正。
修正後重新dd根分區，執行fsck -fn /dev/sda5，進行檢測，依然有報錯，如下圖：
圖三：
根據提示，在係統中發現有多個節點共用同樣的數據塊。按此提示進行底層分析，發現，因3號盤早掉線，幫存在節點信息的新舊交集。
按節點所屬的文件進行區別，清除錯誤節點後，再次執行fsck -fn /dev/sda5,依然有報錯信息，但已經很少。根據提示，發現這些節點多位於doc目錄下，不影響係統啟動，於是直接fsck -fy /dev/sda5強行修複。
修複後，重啟係統，成功進入桌麵。
啟動數據庫服務，啟動應用軟件，一切正常，無報錯。
到此，數據恢複及係統回遷工作完成。
最後更新：2017-09-06 18:32:34