EMC Isilon(OneFS)資料恢復案例詳解

【故障描述】

    某大學因駭客入侵，導致其“教學系統”的重要資料被刪除。其中包括“教學系統”中的MSSQL資料庫，以及大量的MP4、ASF和TS型別的影片教學檔案。整體儲存架構採用EMC高階網路NAS（Isilon S200），節點數量為3個，每個節點配置12塊3T STAT硬碟，無SSD。所有資料一共分兩部分，一部分資料為vmware虛擬機器（WEB伺服器），透過NFS協議共享到ESX主機，另一部分資料為影片教學檔案，透過CIFS協議共享給虛擬機器（WEB伺服器）。駭客只刪除了NFS共享的所有資料（也就是所有虛擬機器），而CIFS共享的資料則沒有被刪除。

【資料備份】

因考慮到資料安全性，避免對資料造成二次破壞，需對所有硬碟進行全部備份。但是由於磁碟數量太多（單節點 12塊盤，3個節點36塊盤），且單盤容量太大（單盤3TB，一共108TB），因此備份週期會較長。最終客戶決定，只對儲存中現有資料進行備份，並且由北亞備份一次，客戶再備份一次，以確保現有資料安全。

【資料分析】

備份完所有資料後，在 Isilon的web管理介面中將Isilon正常關機。再將所有節點上的所有硬碟貼上標籤，並依次取出再放到北亞提供的資料恢復平臺中，開始分析所有硬碟中的資料。

 至此先簡單介紹一下Isilon的儲存結構，Isilon內部使用的是分散式檔案系統OneFS。在Isilon儲存叢集中，每個節點都是一個單一的OneFS檔案系統，因此Isilon支援橫向擴充套件，並且不會影響正在使用的資料。在儲存叢集工作時，所有節點提供相同的功能，節點與節點之前沒有主備之分。當使用者往儲存叢集中儲存檔案時，OneFS層會將檔案分成128K的片段分別存到不同的節點中，而在節點層又會將128K的片段分成8K的小片段分別存到該節點的不同硬碟中。而使用者檔案的Indoe資訊、目錄項及資料MAP則會分別儲存在所有節點中，這樣可以確保使用者不管從那個節點都可以訪問到所有資料。Isilon在初始化時會讓使用者選擇相應的儲存冗餘模式，不同的冗餘模式所提供的資料安全級別也不一樣（預設3個節點採用N+2:1模式）。

由於客戶資料是被刪除了，因此不用過多考慮儲存的冗餘級別，重點需要分析檔案刪除後，檔案 Indoe及資料MAP是否發生變化。和客戶溝通後，刪除的虛擬磁碟檔案都在64G或以上，並且儲存中沒有其他型別的大檔案。編寫掃描所有檔案Indoe的程式，將檔案大小符合64G或以上的Indoe都掃描出來。再仔細分析掃描出來的Indoe，發現Indoe中記錄的資料MAP位置，其index指向的內容已不再是正常資料，並且所有節點上的Indoe均是同樣的情況。再仔細分析Inode，發現大檔案的資料MAP會有多層（樹結構）,並且資料MAP中會記錄檔案的唯一ID，因此可以嘗試找到檔案最底層的資料MAP。抱著僥倖心理對檔案最底層的資料MAP做遍歷跟蹤操作，發現最低層的資料MAP果然還在。

【資料恢復 分析步驟 】

     1 、 編寫程式，從檔案的 Inode中取出檔案的唯一ID，然後對所有符合該ID的資料MAP做聚合。並根據資料MAP中的VCN號做排序，發現每個檔案的前17088項資料MAP都不存在，也就意味著每個檔案的前17088項資料是真的沒辦法恢復了（心情一下跌落低谷）。

    2 、 仔細換算了一下發現丟失的資料 MAP項總共才包含不到1G的資料，而刪除的檔案全是虛擬機器的vmdk檔案，裡面都是NTFS的檔案系統，而NTFS檔案系統的MFT基本都在3G的位置，也就是隻需要在每個vmdk檔案的頭部手動偽造一個MBR和DBR就可以解釋vmdk裡面的資料了（真不知到是巧合呢！還是巧合呢！）。趕緊編寫程式碼，對掃描到的資料MAP做解釋，並根據VCN號的順序匯出資料，沒有MAP的情況保留為零。

     3 、 經過不斷的測試，程式終於編好了，先匯出一個 vmdk檔案來看看。結果令我大吃一驚，匯出的vmdk檔案比實際情況要小，並且vmdk中MFT的位置也與自身描述不符。是程式的問題？還是資料MAP本身已損壞？手動隨機驗證了幾個MPA發現都能指向資料區，而程式解釋MAP的方式也都沒有問題。就在我百思不得其解的時候，我突然想到Isilon這麼高階的儲存不可能沒有檔案稀疏吧！否則空間得浪費多少啊！立馬根據資料MAP驗證了一下，發現檔案果然是稀疏的。

    4 、 修改程式碼，重新匯出剛才的 vmdk，這次vmdk大小符合實際大小，且MFT的位置也在相應位置。手工偽造一個MBR，分割槽表以及DBR，再用北亞開發的檔案系統解釋工具成功解釋其檔案系統，匯出vmdk裡面的資料庫及影片檔案。

5 、 在驗證了此 vmdk中的資料庫及影片檔案沒問題後，批次匯出所有重要的vmdk檔案，再手工一個一個的去修改每個vmdk檔案。

【資料驗收】

      整個恢復過程耗時 較長 ，雖然 在恢復研究 過程 中遇到了一些問題 ，但是 好在資料可以正常恢復 。 將客戶所有重要的資料恢復完成後，由客戶方安排工程師對恢復的所有資料做完整性及準確性檢測，經過長達 1天的驗證工作。資料最終確定完全沒有問題， 至此 資料恢復成功 。