【北亞伺服器資料恢復】SAN環境下卷對映出錯導致檔案系統共享衝突的資料恢復案例

伺服器資料恢復環境：

san環境下的儲存上一組由6塊硬碟組建的RAID6，劃分為若干LUN，MAP到跑不同業務的伺服器上，伺服器上層是SOLARIS作業系統+UFS檔案系統。

伺服器故障：

業務需求需要增加一臺伺服器跑新增的應用，工作人員在原伺服器線上的狀態下將其中一個lun對映到一臺新伺服器上。實際上這個剛對映過去的卷已經map到了solaris生產系統上的某個lun上了。新伺服器對這個對映過來的捲進行初始化，原來的solaris系統上的磁碟報錯，重啟伺服器後這個卷已經無法掛載了。

聯絡原廠工程師尋求幫助，原廠工程師檢測後執行了fsck操作，完成fsck操作後檔案系統掛載成功，檢視資料時發現大量資料丟失或者檔案大小變為0，最新的資料全部丟失。

本案例故障情況在san環境下比較常見，多數情況下是工作人員在沒有考慮充分的情況下進行操作導致資料丟失。

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

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

伺服器資料恢復過程：

1、將出現問題的lun完整備份，後續的資料分析和資料恢復操作都在備份檔案進行，避免對原始資料造成二次破壞。

2、基於備份檔案解析檔案系統，經過分析發現檔案中的iNode已經被清除，無法透過還原iNode的方式來恢復資料，只能透過檔案型別進行處理。

3、對使用者需要恢復的特定檔案進行分析，發現採用vfs公文系統的索引檔案具有強的型別特徵，而且檔案中包含目錄資訊。

4、按照vfs公文系統的索引結構特徵，北亞企安資料恢復工程師編寫程式提取資料，提取資料完成後根據特徵重新命名。

5、按型別恢復資料檔案，然後由使用者方根據索引檔案重新整理資料檔案。

6、整理完成後對恢復出來的資料進行檢測，檢測完成後使用者方確認恢復資料完整有效。本次伺服器資料恢復工作完成。