SUN平臺服務(wù)器光纖共享存儲互斥失敗導(dǎo)致的數(shù)據(jù)恢復(fù)

服務(wù)器數(shù)據(jù)恢復(fù)故障描述：

• 服務(wù)器最初的設(shè)計思路為將兩臺SPARC SOLARIS系統(tǒng)通過光纖交換機(jī)共享同一存儲作為CLUSTER使用，正常情況下A服務(wù)器工作，當(dāng)A服務(wù)器發(fā)生故障宕機(jī)后即可將其關(guān)機(jī)然后開啟B服務(wù)器進(jìn)行接管。但由于服務(wù)器配置不當(dāng)導(dǎo)致兩臺SERVER并未很好地對存儲互斥
  
• 管理員對服務(wù)器進(jìn)行運(yùn)維檢查時開啟B服務(wù)器，查到B服務(wù)器連接了一組未知的大容量磁盤，由于B服務(wù)器并未啟用，處于閑置狀態(tài)，所以管理員以為磁盤也是閑置的，于是將整個磁盤的某個分區(qū)做了newfs。然而這個磁盤就是那個共享存儲，A服務(wù)器很快報警并宕機(jī)。
• 管理員于是對服務(wù)器做了如下操作：首先重啟A服務(wù)器但所有的文件系統(tǒng)均無法mount。然后執(zhí)行了fsck，多數(shù)分區(qū)數(shù)據(jù)修復(fù)成功，只有在B機(jī)做過newfs的文件系統(tǒng)結(jié)果不理想，根目錄下只有一個lost+found文件夾，里面有大量數(shù)字標(biāo)號的文件。
• 故障文件系統(tǒng)存儲了兩組ORACLE實例，原結(jié)構(gòu)為UFS，約有200~400個數(shù)據(jù)文件需要恢復(fù)。
  
  數(shù)據(jù)恢復(fù)分析：
• 光纖設(shè)備的共享沖突案例很多，起緣于光纖交換的靈活性。此例中，A機(jī)與B機(jī)同時對UFS這個單機(jī)文件系統(tǒng)進(jìn)行訪問是很糟糕的，兩臺SERVER都以想當(dāng)然的獨享方式對存儲進(jìn)行管理，A機(jī)正常管理的文件系統(tǒng)其實底層上已經(jīng)被B機(jī)做了文件系統(tǒng)初始化，A機(jī)從緩沖區(qū)寫入文件系統(tǒng)的數(shù)據(jù)也會破壞B機(jī)初始化的結(jié)果。
• B機(jī)newfs實際上直接會作用于原先的文件系統(tǒng)之上，但此例與單純的newfs會有些不同，在A機(jī)宕機(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)的UNIX文件系統(tǒng)，以塊組切割，每塊組分配若干固定的inode區(qū)。文件系統(tǒng)newfs時，如果結(jié)構(gòu)與之前的相同，文件系統(tǒng)最重要的inode區(qū)便會全部初始化，之前的無法保留，inode管理著所有文件的重要屬性，所以單純從文件系統(tǒng)角度考慮，數(shù)據(jù)恢復(fù)的難度很大。好在oracle數(shù)據(jù)文件的結(jié)構(gòu)性很強(qiáng)，同時UFS文件系統(tǒng)還是有一定的存儲規(guī)律性，可以通過對oracle數(shù)據(jù)文件的結(jié)構(gòu)重組，直接將數(shù)據(jù)文件、控制文件、日志等恢復(fù)出來。同時oracle數(shù)據(jù)文件本身會有表名稱描述，也可以反向推斷原來的磁盤文件名。
  
  數(shù)據(jù)恢復(fù)過程與結(jié)果：
• 首先對故障的文件系統(tǒng)做dd備份。針對整個鏡像文件做完全的oracle數(shù)據(jù)結(jié)構(gòu)分析、重組。然后對部分結(jié)構(gòu)太亂，無法重組的文件，參考ufs文件系統(tǒng)結(jié)構(gòu)特征進(jìn)行輔助分析。利用恢復(fù)的數(shù)據(jù)文件、控制文件在oracle平臺恢復(fù)數(shù)據(jù)庫。所有數(shù)據(jù)庫完全恢復(fù)。
  
  后記：
  fsck是很致命的操作，在fsck之前最好做好備份(dd即可)。光纖存儲的不互斥是非常多的數(shù)據(jù)災(zāi)難原因，方案應(yīng)謹(jǐn)慎部署與實施。