服務器數據恢復環境：

兩臺SPARC SOLARIS操作系統服務器通過光纖交換機共享一臺存儲作為集群使用。平時是一臺服務器(以下稱為主服務器)在運行，如果該服務器發生故障宕機，只需要將這臺服務器關機后開啟另外一臺服務器(以下稱備用服務器)進行接管即可。由于配置不當，兩臺服務器不能很好地對存儲互斥。

服務器故障&分析：

管理員在對服務器進行巡檢時開啟備用的那臺服務器，該服務器連接了一組未知的大容量磁盤。由于該服務器在主服務器正常工作的情況下不會啟用，處于閑置的狀態，所以管理員誤以為該服務器連接的這塊大容量磁盤也處于閑置狀態，于是將該大容量磁盤的某個分區做了newfs。然而這個大容量磁盤就是那臺共享存儲，主服務器報警宕機。

為了挽救數據，管理員做了以下操作：1、重啟主服務器，但所有文件系統均無法掛載。2、執行fsck，多數分區的數據修復成功，只有在備用服務器做過newfs的文件系統有問題，根目錄下只有一個lost+found文件夾，里面有大量數字標號的文件。

故障文件系統存儲了兩組ORACLE實例，原文件系統為UFS，約有200~400個數據文件需要恢復。

這是一個典型的由于配置不當，服務器不能很好地對存儲互斥導致共享沖突的案例。本案例中的2臺服務器同時對UFS這個單機文件系統進行訪問，以想當然的獨享方式對存儲進行管理，主服務器管理的文件系統其實在底層上已經被備用服務器做了文件系統初始化，主服務器從緩沖區寫入文件系統的數據也會破壞備用服務器初始化的結果。

在備用服務器上執行newfs會作用于原先的文件系統之上，但本案例中的情況和單純的newfs有些不同。在主服務器宕機之前，會有一小部分數據(包括元數據)會寫回文件系統。文件系統newfs如果結構與之前的相同，數據區是不會被破壞的。

UFS是傳統的UNIX文件系統，以塊組切割，每塊組分配若干固定的inode區。文件系統newfs時，如果結構與之前的相同，文件系統最重要的inode區會全部初始化，之前的無法保留。inode管理著所有文件的重要屬性，所以單純從文件系統角度考慮，數據恢復的難度很大。由于oracle數據文件的強結構性和UFS的存儲規律性，可以通過重組oracle數據文件的結構，將數據文件、控制文件、日志等恢復出來。同時，oracle數據文件本身會有表名稱描述，可以反向推斷原來的磁盤文件名。

服務器數據恢復過程：

1、對故障文件系統做鏡像備份。

2、北亞企安數據恢復工程師基于鏡像文件分析&重組oracle數據結構。

3、對部分結構混亂，無法重組的文件，北亞企安數據恢復工程師參考ufs結構特征進行輔助分析。

4、利用恢復的數據文件、控制文件在oracle平臺恢復數據庫。

5、恢復完成后，由用戶方工程師進行檢測，經過反復檢測，用戶方確認恢復出來的數據完整有效。本次數據恢復工作完成。

服務器數據恢復總結：

fsck是很致命的操作，在執行fsck操作之前最好做備份。

審核編輯：湯梓紅