服務(wù)器數(shù)據(jù)恢復(fù)環(huán)境&故障：
兩臺SOLARIS系統(tǒng)（SPARC平臺）的服務(wù)器通過光纖交換機(jī)共享同一個存儲作為CLUSTER使用。正常情況下只有A服務(wù)器工作。如果A服務(wù)器發(fā)生故障宕機(jī)，可將A服務(wù)器關(guān)機(jī)，開啟B服務(wù)器接管。但由于配置不當(dāng)導(dǎo)致共享存儲互斥出現(xiàn)問題。
管理員進(jìn)行運(yùn)維檢查時發(fā)現(xiàn)B服務(wù)器連接了一塊未知磁盤。由于B服務(wù)器并未啟用，處于閑置狀態(tài)，所以管理員也將這塊磁盤當(dāng)作閑置的，于是在B服務(wù)器上將磁盤的某個分區(qū)做了newfs。沒想到這塊磁盤就是那個共享存儲，執(zhí)行操作沒有多長時間A服務(wù)器就開始報(bào)警并宕機(jī)。
發(fā)生問題后，管理員又做了如下操作：1、重啟A服務(wù)器但發(fā)現(xiàn)所有的文件系統(tǒng)均無法掛載。2、執(zhí)行fsck。多數(shù)分區(qū)數(shù)據(jù)修復(fù)成功，只有在B服務(wù)器做過newfs的文件系統(tǒng)修復(fù)結(jié)果不理想，根目錄下只有一個lost+found文件夾，里面有大量數(shù)字標(biāo)號的文件。
故障文件系統(tǒng)存放了兩組ORACLE實(shí)例，文件系統(tǒng)為UFS，約有數(shù)百個數(shù)據(jù)文件需要恢復(fù)。

故障分析&數(shù)據(jù)恢復(fù)方案：
光纖環(huán)境下的共享沖突案例很多。本案例中，A服務(wù)器與B服務(wù)器同時對UFS這個單機(jī)文件系統(tǒng)進(jìn)行訪問，兩臺服務(wù)器都以獨(dú)享方式對共享存儲進(jìn)行管理。A服務(wù)器正常管理的文件系統(tǒng)其實(shí)底層上已經(jīng)被B服務(wù)器做了文件系統(tǒng)初始化，A服務(wù)器從緩沖區(qū)寫入文件系統(tǒng)的數(shù)據(jù)也會破壞B服務(wù)器初始化的結(jié)果。
B服務(wù)器上做newfs實(shí)際上直接會作用于原先的文件系統(tǒng)之上，但本案例與單純的newfs有些不同，在A服務(wù)器宕機(jī)之前，會有一小部分?jǐn)?shù)據(jù)(包括元數(shù)據(jù))回寫回文件系統(tǒng)。newfs的結(jié)構(gòu)如果與之前的相同，數(shù)據(jù)區(qū)是不會被破壞的。如果有一小部分元數(shù)據(jù)存在，部分?jǐn)?shù)據(jù)還是可以恢復(fù)的。
UFS文件系統(tǒng)以塊組切割，每塊組分配若干固定的inode區(qū)。文件系統(tǒng)newfs時，如果結(jié)構(gòu)與之前的相同，文件系統(tǒng)最重要的inode區(qū)會全部初始化，之前的無法保留。inode管理著所有文件的重要屬性，所以單純從文件系統(tǒng)角度考慮，數(shù)據(jù)恢復(fù)的難度很大。幸虧oracle數(shù)據(jù)文件的強(qiáng)結(jié)構(gòu)性和UFS文件系統(tǒng)的規(guī)律性，可以通過對oracle數(shù)據(jù)文件的結(jié)構(gòu)重組，將數(shù)據(jù)文件、控制文件、日志等恢復(fù)出來。oracle數(shù)據(jù)文件本身會有表名稱描述，也可以反向推斷原來的磁盤文件名。

服務(wù)器數(shù)據(jù)恢復(fù)過程：
1、將所有文件系統(tǒng)做只讀鏡像。
2、基于鏡像文件分析&重組oracle數(shù)據(jù)結(jié)構(gòu)。
3、針對部分結(jié)構(gòu)亂，無法重組的文件，北亞企安數(shù)據(jù)恢復(fù)工程師參考ufs文件系統(tǒng)結(jié)構(gòu)特征進(jìn)行輔助分析。
4、利用恢復(fù)出來的數(shù)據(jù)文件、控制文件在oracle平臺恢復(fù)數(shù)據(jù)庫。
5、恢復(fù)完所有數(shù)據(jù)庫文件后，交由用戶方檢測。經(jīng)過仔細(xì)檢測，確認(rèn)恢復(fù)出來的數(shù)據(jù)完整。

Tips：
fsck是很致命的操作，在fsck之前最好做好備份。光纖環(huán)境中存儲互斥不當(dāng)是非常多的數(shù)據(jù)災(zāi)難的原因，應(yīng)謹(jǐn)慎部署與實(shí)施。

審核編輯 黃宇