分析SAN LUN Mapping出錯導致檔案系統共享衝突的情況

【資料恢復故障描述】
SUN 光纖儲存系統，中心儲存為 6 枚 300G 硬碟組成的 RAID6 ，劃分為若干 LUN ， MAP 到不同業務的伺服器上，伺服器上執行 SUN SOLARIS 作業系統。
正常工作狀態下，使用者需要新增應用，所以增加了一臺IBM 伺服器，之後線上狀態下將儲存中的某個 LUN 對映到新增的 IBM 伺服器，不料，對映的卷是原先已經 MAP 到 SOLARIS 生產系統上的某個 LUN 上了，由於並未及時發現， IBM 伺服器上已經對此 LUN 進行了部分初始化操作 ( 操作不詳 ) ，之後 SOLARIS 上磁碟報錯，重啟後發現問題，卷無法掛載。
SUN 工程師檢測後，執行 fsck ，完成後檔案系統可掛上，但很多資料丟失或大小變為 0 ，尤其最新資料破壞嚴重。

【資料恢復故障分析】
SAN 環境下此類故障較為常見，但多數是人為不小心導致，此故障也是如此。正常情況下， SAN 分配出來的 LUN 是獨佔模式的，如果同時為幾個作業系統所控制，極易導致寫操作不互斥，導致檔案系統一致性出錯。
如果要恢復此部分資料，需要深入檔案系統，考察其各結構的破壞情況。本例中，因檔案系統採用UFS ，所以對任何一個需要恢復的檔案而言，優先考慮目錄資訊、節點、資料區是否正常，如上述 3 個結構均正常，資料可完整恢復。但多數情況下， fsck 後 INODE 會清除，即使留下目錄資訊，也無法與資料一一對應，這時候，就只能參考檔案內部格式進行型別式的恢復了。

【資料恢復過程】
1 、完整備份故障卷，因 RAID 無故障，所以直接在 SOLARIS 環境中對原 LUN 做 dd 備份。
2 、在備份中分析檔案系統，確定需恢復檔案的 inode 已經全部清除，無法還原。只好按檔案型別進行處理。
3 、對使用者需要恢復的特定檔案進行分析，發現採用 vfs 公文系統的索引檔案具有強的型別特徵，同時檔案中包含目錄資訊。
4 、按照公文系統的索引結構特徵，寫程式提取，提取後根據特徵重新命名。
5 、按型別恢復資料檔案，之後使用者人工根據索引檔案，對資料檔案進行重新整理。

【資料恢復結論】
歷時24 小時，目錄索引檔案 99% 恢復成功，資料檔案 大部分 恢復成功，其餘已破壞無法恢復的檔案，使用者根據目錄索引檔案重新向其他部門採集。
結論上，使用者認可資料恢復成功。