服務器數據恢復環境&故障：
某公司的一臺服務器中的raid5磁盤陣列有兩塊磁盤先后掉線，服務器崩潰。故障服務器的操作系統為linux，操作系統部署了oa，數據庫為oracle。oracle數據庫已經不再對該oa系統提供后續支持，用戶要求盡可能恢復操作系統和數據。
經過北亞企安數據恢復工程師檢測，發現熱備盤完全無啟用，所有硬盤不存在明顯物理故障，無明顯同步的表現。

數據恢復及操作系統還原過程：
1、對故障服務器中所有硬盤以只讀方式進行完整鏡像，鏡像過程中后發現raid中2號盤有少量壞扇區，其余磁盤均無壞道。
2、基于鏡像文件分析raid結構，獲取到條帶規則、條帶大小、校驗方向、META區域等信息。raid最佳結構為0,1,2,3盤序，缺3號盤，塊大小512扇區，backward parity(Adaptec)。

北亞企安數據恢復——RAID5數據恢復

3、按照上面獲取到的raid信息重組raid后驗證數據，發現200M以上的最新壓縮包解壓無報錯，確定raid結構正確。
4、按照此結構生成RAID到一塊單硬盤上，打開文件系統無明顯報錯。
5、經客戶同意后，用全新硬盤更換損壞的2號盤，然后使用原盤重建RAID。將恢復好的單盤接入故障服務器，再用linux SystemRescueCd啟動故障服務器，之后通過dd命令進行全盤回寫。
6、回寫后啟動操作系統。如果正常進入系統，則所有工作就完成了。不巧的是，dd所有數據后，啟動操作系統，無法進入，報錯信息為：“/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied”。
7、懷疑此文件權限有問題，用SystemRescueCd重啟后檢查，此文件時間，權限，大小均有明顯錯誤，顯然節點損壞。
8、重新分析重組數據中的根分區，定位出錯的/sbin/pidof，發現問題是由raid中的2號盤壞道引起。
9、使用0號，1號，3號這3塊盤對2號盤的損壞區域進行xor補齊。補齊后重新校驗文件系統，依然有錯誤。再次檢查inode表，發現2號盤損壞區域有部分節點表現為下圖中55 55 55部分。

北亞企安數據恢復——RAID5數據恢復

很明顯，雖然節點中描述的uid還正常存在，但屬性、大小、最初的分配塊全部是錯誤的。基于所有可能進行分析，確定無任何辦法找回此損壞節點。只能希望修復此節點，或復制一個相同的文件過來。
10、針對所有可能有錯的文件，均通過日志確定原節點塊的節點信息，再做修正。
11、修正后重新dd根分區，執行fsck -fn /dev/sda5進行檢測，依然有報錯。

北亞企安數據恢復——RAID5數據恢復

12、根據提示，在系統中發現有多個節點共用同樣的數據塊。按此提示分析底層，發現由于3號盤很早就掉線，所以存在節點信息的新舊交集。
13、按節點所屬的文件進行區別，清除錯誤節點后，再次執行fsck -fn /dev/sda5，依然有少量報錯信息。提示中信息表示這些節點多位于doc目錄下，不影響系統啟動，于是直接執行fsck -fy /dev/sda5進行強行修復。
14、修復后，重啟系統，成功進入系統桌面。啟動oracle數據庫服務和OA應用軟件，一切正常，無報錯。
15、經過用戶檢測后，確認恢復數據完整有效，認可數據恢復結果，本次數據恢復工作結束。

審核編輯 黃宇