服務(wù)器數(shù)據(jù)恢復(fù)環(huán)境：

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

服務(wù)器故障&分析：

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

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

故障文件系統(tǒng)存儲了兩組ORACLE實例，原文件系統(tǒng)為UFS，約有200~400個數(shù)據(jù)文件需要恢復(fù)。

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

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

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)性和UFS的存儲規(guī)律性，可以通過重組oracle數(shù)據(jù)文件的結(jié)構(gòu)，將數(shù)據(jù)文件、控制文件、日志等恢復(fù)出來。同時，oracle數(shù)據(jù)文件本身會有表名稱描述，可以反向推斷原來的磁盤文件名。

服務(wù)器數(shù)據(jù)恢復(fù)過程：

1、對故障文件系統(tǒng)做鏡像備份。

2、北亞企安數(shù)據(jù)恢復(fù)工程師基于鏡像文件分析&重組oracle數(shù)據(jù)結(jié)構(gòu)。

3、對部分結(jié)構(gòu)混亂，無法重組的文件，北亞企安數(shù)據(jù)恢復(fù)工程師參考ufs結(jié)構(gòu)特征進行輔助分析。

4、利用恢復(fù)的數(shù)據(jù)文件、控制文件在oracle平臺恢復(fù)數(shù)據(jù)庫。

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

服務(wù)器數(shù)據(jù)恢復(fù)總結(jié)：

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

審核編輯：湯梓紅