569
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%恢複成功，數據文件大部分恢複成功，其餘已破壞無法恢複的文件，用戶根據目錄索引文件重新向其他部門采集。結論上，用戶認可數據恢複成功。
最後更新：2017-06-19 15:01:51