-
-
加入收藏
設為首頁
加入收藏
設為首頁
| 前階段，遇到個客戶，客戶ESX4.0的服務器，文件系統VMFS3,刪除了一個96G左右的VMDK，客戶要求，重新啟動。第一次遇到vmfs的，網上資料少的可憐，但是還好，官方的一些資料以及開源的vmfstools給予了本次恢復莫大的幫助。 首先看看客戶盤中現存的vmdk的情況，vmdk的碎片量非常大，幾個vmdk都看了一下碎片后，碎片總量在800-10000之間，因此對flat的vmdk做碎片基本是不可能了，只能從文件系統存儲角度考慮。  剛開始在網上查找資料，國內國外的統統看了一下，國內的基本上就是廣告，沒有實質性的東西，國外的止步于.FDC.SF（暫且可以理解為文件索引的一級索引）的分析（后面會講到）。 記得夜里加班的時候，我給我同事寫過四句話，這四句話其實可以概括了，所有的文件系統類型的反刪除恢復的基本操作步驟，當然，如果你對本文件系統相當了解的情況下，也可以直接跳過去，分享下四句話： 1. 文件系統如何讀文件？ 2. 刪除文件的時候發生了什么，是否會干掉所有pointer（類似fat那樣）？ 3. 哪些系統元數據是與數據指向有關的？（與編程一樣，都是靠pointer來實現尋址） 4. 制作一個工具，逆向這些步驟，你就可以恢復出來了。 ） 因此，通過上訴四句話，我們基本上可以了解了從一個未知的文件系統中恢復數據的基本邏輯步驟，因此作為第一步，我們需要一個測試環境，能夠讓我們隨意的創建和刪除文件用，因此我安裝了一個esx的虛擬機，作為分析，逐步解開vmfs的刪除操作之謎  這個是我測試用的vmfs文件系統，通過不斷反復幾十次的增，刪，改，查的方式，我們發現兩個箭頭中所指向的文件應該是恢復的重點。.fdc.sf(=file descriptor cluster.system file英文全稱，這樣好記一點，主要負責存儲文件元數據以及一級索引)，pbc.sf = pointer block cluster.system file，主要存儲2級索引。下面是我們測試的結果： 當我們刪文件的時候發生了什么？ 1. 文件的目錄項（包含名稱以及record id等信息）會被直接清空掉（搞不懂為何要用這種這么低效的辦法，對于文件數量龐大的存儲，vmfs絕對是噩夢，還好只是少量的vmdk） 2. 一級索引會被直接清空。因此小文件是無法通過索引恢復的。 那么一級和二級索引在文件刪除時發生了什么？ 一級索引，只有256個槽位，每個索引都是u_int32,因此一共可以存放256個索引，我們測試了一下，在默認情況下，一個vmfs的block的大小是1m的情況下，一級索引能夠承載的最大文件就是256M，如果文件一旦大于這個量一級索引就不會直接在指向數據區，而是改到二級索引位置由二級索引完成數據指向，從而達到擴展索引槽位的目的。當發現這個信息的時候，我們就激動了，因為vmdk基本不可能那么小，都是上百G，因此所有的二級索引都會被保留下來，通過對PBC中的二級索引進行提取即可完成所有碎片的搜集和恢復工作。 目前的局限性： 1. 目前只做了vmfs3的分析，vmfs5還有待我們后續深入，基本原理應該是差不多的。 2. 目前沒有涉及到vmdk的快照的恢復，因此我們還會繼續深入下去。 3. 本人的知識能力所限，可能有錯誤的地方，還請海涵 |
