SAN LUN Mapping出錯導致的資料丟失恢復全過程

【伺服器資料恢復故障描述】

本次資料恢復伺服器為SUN 光纖儲存系統，中心儲存為6枚300G硬碟組成的RAID6，劃分為若干LUN，MAP到不同業務的伺服器上，伺服器上執行SUN SOLARIS作業系統。

本來伺服器並沒有物理故障，出於使用者業務需求需要再增加一臺伺服器用於新增應用。於是伺服器管理員在原伺服器線上的狀態下將其中一個lun對映到一臺心伺服器上。管理員沒有注意到的是，這個剛剛對映過去的卷已經map到了solaris生產系統上的某個lun上了，如此一來，對映到ibm伺服器後，伺服器對這個捲開始進行了初始化的操作，原本的solaris上的磁碟出現報錯，重啟伺服器後這個卷已經無法掛載了。

這時候sun工程師經過檢測執行了fsck操作，完成後掛載檔案系統成功，檢視資料時發現多數資料丟失或者檔案大小為0，最新資料全部丟失。只能透過伺服器資料恢復手段進行資料恢復操作。

【伺服器資料恢復故障分析】

本次案例中的故障情況再san環境下比較多見，多數是管理員在操作時不注意導致的資料丟失。這裡簡單解釋一下：

在正常的工作模式下，san分配的卷為獨立佔用模式，如果管理員將其對映給兩個或多個作業系統將會導致檔案系統一致性出錯。

這種故障情況下如果想要進行資料恢復首先需要分析檔案系統各個結構的損壞狀態。在本次資料恢復案例中，因檔案系統採用UFS，所以對任何一個需要恢復的檔案而言，優先考慮目錄資訊、節點、資料區是否正常，如上述3個結構均正常，資料可完整恢復。但多數情況下，fsck後INODE會清除，即使留下目錄資訊，也無法與資料一一對應，這樣一來就只能參考檔案內部格式進行型別式的恢復了。

【伺服器資料恢復過程】

1. 對出現故障的lun進行完整備份，在本次資料恢復案例中不涉及raid陣列硬體故障，所以只要直接dd就可以了。

2. 在備份檔案中對檔案系統進行解析，經過分析發現元檔案中的iNode確實已經被清除了，無法透過還原iNode恢復資料，只能透過檔案型別進行處理。

3. 伺服器資料恢復工程師對使用者需要恢復的特定檔案進行分析，發現採用vfs公文系統的索引檔案具有強的型別特徵，同時檔案中包含目錄資訊。

4. 按照公文系統的索引結構特徵，寫程式提取，提取後根據特徵重新命名。

5. 按型別恢復資料檔案，之後使用者人工根據索引檔案，對資料檔案進行重新整理。
   

【資料恢復結論】

經過2個工作日的資料分析和恢復操作，伺服器資料恢復工程師最終提取了客戶伺服器內99%的資料和目錄索引檔案，經過客戶對恢復成功的資料驗證，最終確認客戶所需要的重要資料已經全部恢復，本次資料恢復成功。