【故障描述】
某大學因******，導致其“教學系統”的重要數據被刪除。其中包括“教學系統”中的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果然還在。
【數據恢復】
編寫程序，從文件的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文件。
【數據驗收】
將客戶所有重要的數據恢復完成後，由客戶方安排工程師對恢復的所有數據做完整性及準確性檢測，經過長達1天的驗證工作。數據最終確定完全沒有問題，數據恢復成功。
【數據恢復總結】
整個恢復過程耗時一個月，雖然過程很曲折，但是結果很滿意。
作者：鄧奇 (北亞高級數據恢復工程師)
聯繫方式：18515283878