【伺服器資料恢復】RAID5崩潰導致上層OA不可用的資料恢復案例

伺服器資料恢復環境：

某公司一臺伺服器中組建一組raid5磁碟陣列；

上層作業系統為linux redhat，部署OA系統，後端資料庫為oracle。

伺服器故障&初檢：

raid5中有2塊磁碟先後掉線，伺服器崩潰。oracle已經不對該OA系統提供後續技術支援，使用者方要求恢復資料和作業系統。

經過初步檢測，發現熱備盤沒有啟用，硬碟無明顯的物理故障和同步表現。

伺服器資料恢復過程：

1、將故障伺服器中所有硬碟做好標記，取出後掛載至只讀環境，對所有硬碟以只讀方式做完全映象備份，映象過程中發現

有一塊磁碟（2號盤）有少量壞扇區，其他磁碟均沒有發現壞道。映象完成後將硬碟按照編號復原至原伺服器，之後的資料

分析和資料恢復操作都基於映象檔案進行，避免對原始資料造成二次破壞。

2、基於映象檔案分析RAID結構，獲取到原RAID級別，條帶規則，條帶大小，校驗方向，META區域等RAID相關資訊。分

析結構：0,1,2,3盤序，缺3號盤，塊大小512扇區，backward parity(Adaptec)。

raid結構：

3、檢測虛擬重構的RAID結構是否正確，經過檢測發現200M以上的最新壓縮包解壓無報錯，確定結構正確。直接按此結

構生成虛擬RAID到一塊單硬碟上，開啟檔案系統無明顯報錯。

4、確定備份包安全的前提下，經使用者方同意後，北亞企安資料恢復工程師用全新硬碟更換損壞的2號盤，然後對原盤重建

RAID。將恢復好的單盤用USB方式接入故障伺服器，再用linux SystemRescueCd啟動故障伺服器，之後透過dd命令進行

全盤迴寫。

5、完成回寫後啟動作業系統，結果發現無法進入系統並報錯，

報錯資訊為：“/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied”。懷疑此檔案許可權有問題，用SystemRescueCd

重啟後檢查發現此檔案的時間，許可權，大小均有明顯錯誤，顯然是節點損壞。

6、重新分析&重組資料中的根分割槽，定位出錯的/sbin/pidof，發現問題是由2號盤壞道導致的。

7、透過raid中的另外3塊盤對2號盤的損壞區域進行xor補齊。補齊後重新校驗檔案系統，依然有錯誤，再次檢查inode表，

發現2號盤損壞區域有部分節點表現為下圖中的55 55 55部分。

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

，確實沒有任何辦法能找回此損壞節點。只能嘗試修復此節點或複製一個相同的檔案過來。

9、北亞企安資料恢復工程師對所有可能有錯誤的檔案透過日誌確定原節點塊的節點資訊並做修正。

10、修正後重新dd根分割槽，執行fsck -fn /dev/sda5進行檢測，出現報錯：

報錯提示在系統中發現有多個節點共用同樣的資料塊。按此提示進行底層分析，發現因3號盤早掉線，存在節點資訊的新舊

交集。

11、按節點所屬的檔案進行區別，清除錯誤節點後再次執行fsck -fn /dev/sda5進行檢測，依然有極少量的報錯資訊。根據

報錯資訊的提示，發現這些節點多位於doc目錄下，不影響系統的啟動，於是直接執行fsck -fy /dev/sda5強行修復。

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

13、由使用者方工程師親自驗證，經過反覆驗證，確認恢復結果有效。至此，本次資料恢復工作完成。