SUN平台,光纖共享儲存互斥失敗導致的資料災難恢復

[資料恢復故障描述]

兩台sparc solaris系統通過光纖交換機共享同一儲存，本意是作為cluster使用，但配置不當，兩台server並未很好地對儲存互斥，設計意圖為：平時a伺服器正常工作，當a伺服器宕掉後，關掉a，開啟b接管服務。

偶然的機會，一位管理人員開啟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即可)。

光纖儲存的不互斥是非常多的資料災難原因，方案應謹慎部署與實施。