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

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

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

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

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

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

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

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

審核編輯 黃宇