【伺服器資料恢復】SAN LUN對映出錯導致檔案系統資料丟失的資料恢復案例

伺服器資料恢復環境：

SUN光纖儲存系統；

6塊硬碟組成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進行備份。

2、在備份中分析檔案系統，確定了需恢復檔案的inode已經全部清除，無法還原，所以只好按檔案型別進行處理。

3、對使用者需要恢復的特定檔案進行分析，發現採用vfs公文系統的索引檔案具有強的型別特徵，同時檔案中包含目錄資訊。

4、按照公文系統的索引結構特徵，北亞伺服器資料恢復工程師寫程式提取資料，提取後根據特徵重新命名。

5、按型別恢復資料檔案，然後由使用者根據索引檔案對資料檔案進行重新整理。

6、歷時24小時，目錄索引檔案99%恢復成功，資料檔案大部分恢復成功，其餘已破壞無法恢復的檔案由使用者根據目錄索引文

件重新向其他部門採集。使用者認可本次資料恢復結果。