【服務(wù)器數(shù)據(jù)恢復】EMC NAS數(shù)據(jù)恢復案例

服務(wù)器數(shù)據(jù)恢復環(huán)境：

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

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

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

服務(wù)器故障：

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

服務(wù)器數(shù)據(jù)恢復過程：

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

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

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

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

5、分析Inode，發(fā)現(xiàn)大文件的數(shù)據(jù)MAP會有多層(樹結(jié)構(gòu)),并且數(shù)據(jù)MAP中會記錄文件的唯一ID，因此可以嘗試找到文件底層的數(shù)據(jù)MAP。

6、對文件底層的數(shù)據(jù)MAP做遍歷跟蹤操作后發(fā)現(xiàn)底層的數(shù)據(jù)MAP果然還在。

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

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

9、解釋掃描到的數(shù)據(jù)MAP，根據(jù)VCN號的順序?qū)С鰯?shù)據(jù)，沒有MAP的情況就保留為零。經(jīng)過不斷的測試，嘗試導出一個vmdk文件，發(fā)現(xiàn)導出的vmdk文件比實際情況要小，并且vmdk中MFT的位置也與自身描述不符。

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

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

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

服務(wù)器數(shù)據(jù)驗證：

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

審核編輯：湯梓紅