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%恢復成功，數據文件大部分恢復成功，其余已破壞無法恢復的文件，用戶根據目錄索引文件重新向其他部門采集。

結論上，用戶認可數據恢復成功。