分析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會清除，即便留下目錄信息，也沒法與數據一一對應，這時候，就只能參考文件內部格式進行類型式的恢復了。
【數據恢復過程】
一、完整備份故障卷，因RAID無端障，因此直接在SOLARIS環境中對原LUN作dd備份。
二、在備份中分析文件系統，肯定需恢復文件的inode已經所有清除，沒法還原。只好按文件類型進行處理。
三、對用戶須要恢復的特定文件進行分析，發現採用vfs公文系統的索引文件具備強的類型特徵，同時文件中包含目錄信息。
四、按照公文系統的索引結構特徵，寫程序提取，提取後根據特徵從新命名。
五、按類型恢復數據文件，以後用戶人工根據索引文件，對數據文件進行從新整理。
【數據恢復結論】
歷時24小時，目錄索引文件99%恢復成功，數據文件大部分恢復成功，其他已破壞沒法恢復的文件，用戶根據目錄索引文件從新向其餘部門採集。
結論上，用戶承認數據恢復成功。