【北亞資料恢復】IBM伺服器raid5硬碟離線，熱備盤未啟用導致raid崩潰的資料恢復案例

伺服器資料恢復環境：

IBM X系列伺服器；

作業系統為linux redhat；

5塊73G SAS硬碟，4塊組成RAID5，1塊作為熱備盤(Hot-Spare)。

故障：

3號盤最早離線，熱備盤未自動啟用rebuild（原因不明），然後2號盤離線，RAID崩潰。使用者聯絡北亞資料恢復中心進行

資料恢復。

應用是基於oracle資料庫的一個OA系統。因oracle已經不再對本OA系統提供後續支援，使用者要求儘可能恢復資料和操作

系統。熱備盤完全無啟用，硬碟無明顯物理故障，無明顯同步表現。

伺服器資料恢復方案：

1、關閉伺服器，將故障硬碟標好序號。

2、將故障硬碟掛載到北亞資料恢復備份伺服器，對所有故障硬碟做完全映象。備份完成後交還原故障盤。

3、通過對備份盤進行RAID結構分析，北亞資料恢復工程師獲取到其原來的RAID級別，條帶規則，條帶大小，校驗方向，

META區域等。

4、根據得到的RAID資訊，由北亞資料恢復工程師搭建一組虛擬的RAID5環境。

5、進行虛擬磁碟及檔案系統解釋。

6、檢測虛擬結構是否正確，如不正確，重複3-6的過程。

7、確定資料無誤後回遷資料。如果仍然使用原盤，需確定已完全對原盤做過備份，重建RAID，再做回遷。回遷作業系統時

，可以使用linux livecd或win pe(通常不支援)等進行，也可以在故障伺服器上用另外硬碟安裝一個回遷用的作業系統，再進

行扇區級別的回遷。

伺服器資料恢復過程：

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重啟後檢查，此檔案時間，許可權，大小均有明顯錯誤

，顯然節點損壞。

7、北亞資料恢復工程師重新分析，重組資料中的根分割槽，定位出錯的/sbin/pidof/datahf.net，發現問題因2號盤壞道引起。

8、使用0，1，3這3塊盤針對2號盤的損壞區域進行xor補齊。補齊後重新校驗檔案系統，發現依然有錯誤，再次檢查inode

表，發現2號盤損壞區域有部分節點表現為(圖中的55 55 55部分)：

很明顯，雖然節點中描述的uid還正常存在，但屬性、大小和最初的分配塊全部是錯誤的。按照所有可能進行分析，北亞數

據恢復工程師判斷無法找回此損壞節點，只能修復此節點，或複製一個相同的檔案過來。

9、對所有可能有錯的檔案，均通過日誌確定原節點塊的節點資訊，再做修正。修正後重新dd根分割槽，執行

fsck -fn /dev/sda5/datahf.net，進行檢測，依然有報錯，如下圖：

10、根據提示，在系統中發現有多個節點共用同樣的資料塊。按此提示進行底層分析，北亞資料恢復工程師發現因3號盤早

掉線因而存在節點資訊的新舊交集。

11、按節點所屬的檔案進行區別，清除錯誤節點後，再次執行fsck -fn /dev/sda5依然有報錯資訊，但已經很少。根據提示

，發現這些節點多位於doc目錄下，不影響系統啟動，於是執行fsck -fy /dev/sda5/datahf.net強行修復。

12、修復完成後重啟系統，成功進入桌面。啟動資料庫服務，啟動應用軟體，一切正常，無報錯。

至此，資料恢復及系統回遷工作完成，經過使用者檢測後資料完整，正常可用，資料恢復成功。