EMC Isilon儲存誤刪除虛擬機器的恢復過程

【伺服器資料恢復故障描述】

北京某公司的EMC伺服器採用高階網路NAS（Isilon S200），共有三個節點，每一節點配置12塊硬碟，單盤介面為SATA硬碟，容量為3T。管理員工作中誤刪除虛擬機器，其中包括資料庫、MP4、AS、TS型別的影片檔案等。需要進行資料恢復的虛擬機器NFS協議共享到ESX主機，影片檔案透過CIFS協議共享給虛擬機器（WEB伺服器）。NFS共享的所有資料（也就是所有虛擬機器）被刪除而CIFS共享的資料則沒有被刪除。

【伺服器資料恢復第一步：備份】

在資料恢復過程中為保障資料安全、以免對資料造成二次破壞，資料恢復之前需要將所有硬碟進行全部備份。在本例中由於磁碟數量太多且單盤容量太大（單節點12塊盤，3個節點36塊盤，單盤3TB，一共108TB），因此備份週期會較長。

【伺服器資料恢復第二步：資料分析】

伺服器資料備份完成後在Isilon的web管理介面中將Isilon正常關機。將備份好的伺服器資料放到資料恢復平臺中對資料進行分析。由於資料丟失的原因是誤刪除，所以可以不用過多考慮該伺服器的冗餘級別，需要重點分析的是檔案刪除後Indoe及資料MAP是否發生變化。由於伺服器中被刪除的虛擬磁碟檔案大小都在64G或以上，該伺服器中再無其他大檔案。資料恢復工程師決定編寫掃描所有檔案Indoe的程式，將檔案不小於64G大小的indoe全部掃描出來，透過對Indoe進行掃描找出資料MAP位置，其index指向的內容已不再是正常資料，並且所有節點上的Indoe均是同樣的情況。再仔細分析Inode，發現大檔案的資料MAP會有多層（樹結構）,並且資料MAP中會記錄檔案的唯一ID，因此可以嘗試找到檔案最底層的資料MAP。抱著僥倖心理對檔案最底層的資料MAP做遍歷跟蹤操作，發現最低層的資料MAP果然還在。

【伺服器資料恢復過程】

透過檔案的Inode進行唯一ID的提取工作，然後對所有符合該ID的資料MAP做聚合。並根據資料MAP中的VCN號做排序，工程師透過分析發現每個檔案的前17088項資料MAP都不存在，理論上則每個檔案的前17088項資料是真的沒辦法恢復了。
透過仔細的資料換算得知丟失的資料MAP項總共才包含不到1G的資料，刪除的檔案全是虛擬機器的vmdk檔案，裡面都是NTFS的檔案系統，NTFS檔案系統的MFT基本都在3G的位置。如此看來只需要在每個vmdk檔案的頭部手動偽造一個MBR和DBR就可以解釋vmdk裡面的資料了。對掃描到的資料MAP做解釋，並根據VCN號的順序匯出資料，沒有MAP的情況保留為零。
資料恢復工程師將一個vmdk檔案進行匯出，但檔案比實際情況要小、vmdk中MFT的位置也與自身描述不符。手動隨機驗證了幾個MPA發現都能指向資料區，而程式解釋MAP的方式也都沒有問題。出現這種情況的原因可能為檔案稀疏！
資料恢復工程師重新調整了程式碼部分後再次匯出vmdk，這次匯出的資料正常且MFT的位置也在相應位置。手工偽造一個MBR，分割槽表以及DBR，再用北亞開發的檔案系統解釋工具成功解釋其檔案系統，匯出vmdk裡面的資料庫及影片檔案。
在驗證了此vmdk中的資料庫及影片檔案沒問題後，批次匯出所有重要的vmdk檔案，再手工一個一個的去修改每個vmdk檔案。

【伺服器資料恢復成功】

將客戶所有重要的資料恢復完成後，由客戶方安排工程師對恢復的所有資料做完整性及準確性檢測，資料最終確定完全沒有問題，資料恢復成功。