LUN映射出錯導致文件系統共享沖突的服務器數據恢復案例

服務器數據恢復環境：

某公司的光纖SAN存儲系統，6塊硬盤組建一組RAID6，劃分若干LUN，MAP到不同的SOLARIS操作系統服務器上。

服務器故障&分析：

由于業務增長需要新增應用，工作人員增加了一臺IBM服務器，在SAN還在線的狀態下將存儲中的某個LUN映射到新增加的那臺IBM服務器上。工作人員在進行操作之前不知道這個映射的卷之前已經MAP到SOLARIS操作系統上的某個LUN上了。當工作人員發現到這個問題后，LUN已經進行了部分的初始化，SOLARIS操作系統中的磁盤報錯，重啟存儲后發現卷無法掛載。

聯系原廠工程師進行檢測后，執行fsck，完成操作后文件系統可成功掛載，但發現大量數據丟失或大小變為0，尤其是新數據破壞嚴重。

此類SAN故障較為常見。正常情況下，SAN分配出來的LUN是采用獨占模式的，如果同時被數個操作系統所控制，極易導致寫操作不互斥，文件系統一致性出錯。

本例中的存儲采用的UFS文件系統，所以對每一個需要恢復的文件而言，優先考慮目錄信息、節點、數據區是否正常，如果這3者均正常，數據可完整恢復。但在多數情況下，執行fsck后INODE會被清除，即使留下目錄信息，也無法與數據一一對應。這種情況下只能參考文件內部格式進行類型式的恢復了。

服務器數據恢復過程：

1、將故障存儲中所有磁盤以只讀方式做完整鏡像備份，后續的數據分析和數據恢復操作都基于鏡像文件進行，避免對原始磁盤數據造成二次破壞。

2、基于鏡像文件分析文件系統，經過分析北亞企安數據恢復工程師確定了需要恢復的文件的inode已經全部被清除，無法恢復，只能按照文件類型進行處理。

3、經過分析用戶需要恢復的特定文件，發現采用vfs公文系統的索引文件具有強的類型特征，同時文件中包含目錄信息。

4、按照vfs公文系統的索引結構特征，北亞企安數據恢復工程師編寫程序進行數據提取，提取數據后根據特征重新命名。

5、按照類型恢復數據文件，由用戶人工根據索引文件重新整理數據文件。

服務器數據恢復總結：

經過北亞企安數據恢復工程師團隊的努力，絕大部分的目錄索引文件和大部分的數據文件被恢復出來。對于已經完全破壞、無法恢復的文件，用戶可以根據目錄索引文件重新從其他部門采集。用戶認可數據恢復結果。

審核編輯：湯梓紅