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

【故障描述】

    某大學因黑客入侵，導緻其“教學系統”的重要資料被删除。其中包括“教學系統”中的MSSQL資料庫，以及大量的MP4、ASF和TS類型的視訊教學檔案。整體存儲架構采用EMC高端網絡NAS（Isilon S200），節點數量為3個，每個節點配置12塊3T STAT硬碟，無SSD。所有資料一共分兩部分，一部分資料為vmware虛拟機（WEB伺服器），通過NFS協定共享到ESX主機，另一部分資料為視訊教學檔案，通過CIFS協定共享給虛拟機（WEB伺服器）。黑客隻删除了NFS共享的所有資料（也就是所有虛拟機），而CIFS共享的資料則沒有被删除。

<a href="http://s3.51cto.com/wyfs02/M02/72/4A/wKioL1XgD7iRHMbAAAHND0lmxTA723.jpg" target="_blank"></a>

【資料備份】

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

<a href="http://s3.51cto.com/wyfs02/M02/72/4E/wKiom1XgDh-SaO9XAANaQBSng4Q482.jpg" target="_blank"></a>

【資料分析】

    備份完所有資料後，在Isilon的web管理界面中将Isilon正常關機。再将所有節點上的所有硬碟貼上标簽，并依次取出再放到北亞提供的資料恢複平台中，開始分析所有硬碟中的資料。

<a href="http://s3.51cto.com/wyfs02/M02/72/4A/wKioL1XgEmOScQWxAAIjM92U7Xc367.jpg" target="_blank"></a>

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

<a href="http://s3.51cto.com/wyfs02/M00/72/4E/wKiom1XgDy-iwm48AAJpIJ7aiB8373.jpg" target="_blank"></a>

    由于客戶資料是被删除了，是以不用過多考慮存儲的備援級别，重點需要分析檔案删除後，檔案Indoe及資料MAP是否發生變化。和客戶溝通後，删除的虛拟磁盤檔案都在64G或以上，并且存儲中沒有其他類型的大檔案。編寫掃描所有檔案Indoe的程式，将檔案大小符合64G或以上的Indoe都掃描出來。再仔細分析掃描出來的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檔案比實際情況要小，并且vmdk中MFT的位置也與自身描述不符。是程式的問題？還是資料MAP本身已損壞？手動随機驗證了幾個MPA發現都能指向資料區，而程式解釋MAP的方式也都沒有問題。就在我百思不得其解的時候，我突然想到Isilon這麼高端的存儲不可能沒有檔案稀疏吧！否則空間得浪費多少啊！立馬根據資料MAP驗證了一下，發現檔案果然是稀疏的。

    修改代碼，重新導出剛才的vmdk，這次vmdk大小符合實際大小，且MFT的位置也在相應位置。手工僞造一個MBR，分區表以及DBR，再用北亞開發的檔案系統解釋工具成功解釋其檔案系統，導出vmdk裡面的資料庫及視訊檔案。

    在驗證了此vmdk中的資料庫及視訊檔案沒問題後，批量導出所有重要的vmdk檔案，再手工一個一個的去修改每個vmdk檔案。

<a href="http://s3.51cto.com/wyfs02/M01/72/4E/wKiom1XgEePjHbUXAAKq8CwJu_Q438.jpg" target="_blank"></a>

【資料驗收】

    将客戶所有重要的資料恢複完成後，由客戶方安排工程師對恢複的所有資料做完整性及準确性檢測，經過長達1天的驗證工作。資料最終确定完全沒有問題，資料恢複成功。

【資料恢複總結】

    整個恢複過程耗時一個月，雖然過程很曲折，但是結果很滿意。

本文轉自 張宇 51CTO部落格，原文連結：http://blog.51cto.com/zhangyu/1689331，如需轉載請自行聯系原作者