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

服務器數據恢復故障描述：

• 服務器最初的設計思路為將兩臺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即可)。光纖存儲的不互斥是非常多的數據災難原因，方案應謹慎部署與實施。