服務器數據恢復環境：

北京某公司的EMC NAS，總共有3個節點，每個節點配置12塊STAT硬盤。

NAS中存放有vmware虛擬機(WEB 服務器)和視頻文件。

虛擬機通過NFS協議共享到ESX主機，視頻文件通過CIFS協議共享給虛擬機(WEB服務器)。

服務器故障：

由于工作人員誤操作將包括MSSQL數據庫，大量MP4、ASF和TS格式的視頻文件刪除。NFS共享的所有數據(虛擬機)被刪除而CIFS共享的數據則沒有被刪除。

服務器數據恢復過程：

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

2、基于鏡像文件分析所有硬盤中的數據。由于數據是被人為刪除的，需要分析文件被刪除后，文件的Indoe及數據MAP是否發生變化。

3、由于被刪除的虛擬磁盤文件大小都在64G或者以上，而且存儲中沒有其他類型的、文件大小超過64G的大文件。北亞企安數據恢復工程師編寫Indoe掃描程序，將大小符合64G或以上的文件的Indoe都掃描出來。

4、分析掃描出來的Indoe，找出數據MAP位置，其index指向的內容不是正常數據，并且所有節點上的Indoe均是同樣的情況。

5、分析Inode，發現大文件的數據MAP會有多層(樹結構),并且數據MAP中會記錄文件的唯一ID，因此可以嘗試找到文件底層的數據MAP。

6、對文件底層的數據MAP做遍歷跟蹤操作后發現底層的數據MAP果然還在。

7、從文件的Inode取出文件的唯一ID，聚合所有符合該ID的數據MAP。根據數據MAP中的VCN號排序，發現每個文件的前17088項數據MAP都不存在，這意味著每個文件的前17088項數據沒法恢復。

8、經過換算發現丟失的數據MAP項總共包含不到1G的數據，而刪除的文件全是虛擬機的vmdk文件,內部采用的NTFS文件系統，而NTFS文件系統的MFT基本都在3G的位置，也就是只需要在每個vmdk文件的頭部手動偽造一個MBR和DBR就可以解釋vmdk里面的數據。

9、解釋掃描到的數據MAP，根據VCN號的順序導出數據，沒有MAP的情況就保留為零。經過不斷的測試，嘗試導出一個vmdk文件，發現導出的vmdk文件比實際情況要小，并且vmdk中MFT的位置也與自身描述不符。

10、隨機驗證幾個MAP發現都能指向數據區，程序解釋MAP的方式也都沒有發現問題。所以初步判斷出現這種情況的原因可能是文件稀疏。

11、調整代碼后重新導出剛才的vmdk文件，這次vmdk文件大小符合實際，且MFT的位置正確。手工偽造一個MBR、分區表以及DBR，使用北亞企安自主開發的文件系統解釋程序成功解釋其文件系統，導出該vmdk文件里的數據庫及視頻文件。

12、驗證此vmdk中的數據庫及視頻文件沒有問題后，批量導出所有的vmdk文件，再手工修改每個vmdk文件。直至恢復出所有用戶需要的數據。

服務器數據驗證：

將所有重要數據恢復完成后，由用戶方安排工程師對恢復出來的數據做完整性及準確性驗證。經過反復驗證測試，用戶方確認數據完整有效。本次數據恢復工作完成。

審核編輯：湯梓紅