服務器數據恢復環境：
SUN光纖存儲系統；
6塊硬盤組成RAID6，劃分若干LUN，MAP到不同業務的服務器上，
服務器運行SUN 操作系統。
服務器故障&分析：
由于業務擴展的需要，用戶新增了一臺IBM服務器用于新增應用，在光纖存儲在線的狀態下將存儲中的某個LUN映射到新增的IBM服務器中。不料映射的卷原先已經MAP到生產系統上的某個LUN上了，IBM服務器對此LUN進行了部分初始化，之后上的磁盤報錯，重啟后發現卷無法掛載。用戶聯系SUN工程師進行檢測后，進行了fsck的操作，完成操作后文件系統可掛上，但很多數據丟失或大小變為0，尤其最新數據破壞嚴重。于是用戶聯系我們數據恢復中心進行數據恢復。
SAN環境下此類故障較為常見，多數是人為導致數據庫一致性錯誤修復，本案例故障也是如此。正常情況下，SAN分配出來的LUN是采用獨占模式的，如果同時被幾個操作系統控制，容易造成寫操作不互斥，文件系統一致性出錯。
如果要恢復此部分數據，需要深入文件系統檢查各結構的破壞情況。本案例中，文件系統采用UFS，所以對任何一個需要恢復的文件而言，優先考慮目錄信息、節點、數據區是否正常，如上述3個結構均正常，數據可完整恢復。但多數情況下，fsck后INODE會清除，即使留下目錄信息，也無法與數據一一對應，這時候就只能參考文件內部格式進行類型式的數據恢復了。
北亞數據恢復——SAN數據恢復
服務器數據恢復過程：
1、服務器數據恢復工程師對故障卷做完整備份，因RAID無故障，所以可以直接在環境中對原LUN進行備份。
2、在備份中分析文件系統，確定了需恢復文件的inode已經全部清除，無法還原，所以只好按文件類型進行處理。
3、對用戶需要恢復的特定文件進行分析，發現采用vfs公文系統的索引文件具有強的類型特征，同時文件中包含目錄信息。
4、按照公文系統的索引結構特征，北亞服務器數據恢復工程師寫程序提取數據，提取后根據特征重新命名。
5、按類型恢復數據文件，然后由用戶根據索引文件對數據文件進行重新整理。
6、歷時24小時數據庫一致性錯誤修復，目錄索引文件99%恢復成功，數據文件大部分恢復成功，其余已破壞無法恢復的文件由用戶根據目錄索引文件重新向其他部門采集。用戶認可本次數據恢復結果。
北亞數據恢復——SAN數據恢復
