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

SUN平臺服務器光纖共享存儲互斥失敗導致的數據恢復