服務器數據恢復環境：
san環境下的存儲上一組由6塊硬盤組建的RAID6，劃分為若干LUN，MAP到跑不同業務的服務器上，服務器上層是SOLARIS操作系統+UFS文件系統。

服務器故障：

業務需求需要增加一臺服務器跑新增的應用，工作人員在原服務器在線的狀態下將其中一個lun映射到一臺新服務器上。實際上這個剛映射過去的卷已經map到了solaris生產系統上的某個lun上了。新服務器對這個映射過來的卷進行初始化，原來的solaris系統上的磁盤報錯，重啟服務器后這個卷已經無法掛載了。
聯系原廠工程師尋求幫助，原廠工程師檢測后執行了fsck操作，完成fsck操作后文件系統掛載成功，查看數據時發現大量數據丟失或者文件大小變為0，最新的數據全部丟失。
本案例故障情況在san環境下比較常見，多數情況下是工作人員在沒有考慮充分的情況下進行操作導致數據丟失。
在正常的工作模式下，san分配的卷為獨立占用模式，如果將卷映射給兩個或多個操作系統，就會導致文件系統一致性出錯。
在這種故障情況下恢復數據，首先需要分析文件系統各個結構的損壞狀態。本案例的文件系統是UFS，所以對任何一個需要恢復的文件，我們需要考慮目錄信息、節點、數據區是否正常。如果上述三者均正常，數據可完整恢復。但多數情況下，執行fsck后INODE會被清除，即使留下目錄信息，也無法與數據一一對應，這種情況下就只能參考文件內部格式進行類型式的恢復了。

服務器數據恢復過程：

1、將出現問題的lun完整備份，后續的數據分析和數據恢復操作都在備份文件進行，避免對原始數據造成二次破壞。
2、基于備份文件解析文件系統，經過分析發現文件中的iNode已經被清除，無法通過還原iNode的方式來恢復數據，只能通過文件類型進行處理。
3、對用戶需要恢復的特定文件進行分析，發現采用vfs公文系統的索引文件具有強的類型特征，而且文件中包含目錄信息。
4、按照vfs公文系統的索引結構特征，北亞企安數據恢復工程師編寫程序提取數據，提取數據完成后根據特征重新命名。
5、按類型恢復數據文件，然后由用戶方根據索引文件重新整理數據文件。
6、整理完成后對恢復出來的數據進行檢測，檢測完成后用戶方確認恢復數據完整有效。本次服務器數據恢復工作完成。

審核編輯 黃宇