全是乾貨和實戰，不上首頁天理不容

一、事故來源

9月3日，在阿里雲伺服器上進行了50g的磁碟擴容，然後對磁碟2新擴容的50G進行了操作擴展卷，發現E盤變成了141G，不對啊，我想給F盤擴容的，然後就做了一個讓我後悔的操作，對著那個小方塊點了一下刪除卷，彈出的確定框本能的就點選了確定，然後就變成下圖所示了。E盤整個沒了！！！E盤原來就是下圖所示的框框所框起來的地方。他是跨磁碟的動態磁碟分割槽。分割槽表丟失。原本以為這只是一個普通的事故，分割槽表丟失的情況下資料其實都還在，我們可以通過還原分割槽表來恢復資料。

然後事實給了我們一個響亮的耳光，先說下難點。

1. 利用DiskGen是不能直接恢復分割槽表的，因為這是一個動態磁碟，直接通過工具恢復出來的分割槽50G後面的資料都是0000000000，也就是說資料是隻有一半的，尤其是我們的資料庫檔案，後面一半全是0000000

2. 磁碟3這個磁碟，進行了多次壓縮卷和擴展卷的操作，導致了資料恢復技術人員直接說，你們這個磁碟是不是調整過多次，我根本沒辦法進行恢復。原來磁碟3是100G全分配給F盤的，我們的運維發現其他磁碟空間不夠了，就給F盤壓縮卷，然後通過動態磁碟的方式給D盤和E盤分配過4次空間，而且時間太久了，他記得是一次25G 給E盤，一次1G給E盤，一次10G給D盤，一次15G給E盤。而且這裡他很篤定的說我每次都算1024算的整G的空間，絕對不會有小數點的。這個錯誤的資訊導致了我們後面還原資訊一再被誤導，包括技術人員也被這個資訊誤導從而沒辦法還原資料，這個就不表了。

千萬不要做寫操作！！！！千萬不要做寫操作！！！！千萬不要做寫操作！！！！

動態磁碟千萬不要自信還原分割槽表！！！！動態磁碟千萬不要自信還原分割槽表！！！！動態磁碟千萬不要自信還原分割槽表！！！！

二、修復思路

為什麼要提事故來源，而且說的這麼詳細，其實是為了讓後來者判斷，我的這次事故跟自己的事故是不是類似，是不是有可借鑑的地方，而不是看了半天發現根本不適用自己的問題。

修復思路其實是根據參考文獻2裡面提到的。根據動態磁碟的LDM資料庫，進行恢復。

LDM資料庫利用工具winHex就可以檢視，但是網上下載的winHex普遍是不帶LDM的模板的，這個模板來源是參考文獻1裡面提到的，非常感謝參考文獻1的作者，提供了模板還提供了原理。

通過LDM資料庫給出的資訊，我們就可以知道E盤的組成，然後利用r-studio工具，建立虛擬磁碟進行組合，然後就把一個完整的E盤的邏輯分割槽給恢復了，然後利用這個虛擬磁碟把檔案匯出到另外一個磁碟中。

三、實戰操作

3.1 磁碟分析

先用winHex載入磁碟，這個都不會的話，建議請找專業的資料修復人員操作吧。

先到Disk2磁碟的末尾，用WinHex搜尋Hex。搜尋的內容其實是LDM資料庫的關鍵詞，TOCBLOCK的16進位制的程式碼，這個可以利用線上字串轉16進位制工具辦到。

很快就找到了，說明磁碟的末尾有LDM資料庫，這裡的磁碟是指的物理磁碟，不是每個分割槽後面都有。這個TOC沒有起到實質的作用。

接下來往下走一點可以看到VMDB的資料，這個在我使用的過程中也沒有起到實質的作用。

接下來往下來一點或者搜尋56424C4B就可以找到這個地方。

這裡很抱歉，我沒辦法做實戰了，因為技術人員給我備份磁碟image的時候，竟然吧後面全0000的部分給忽略了，所以我到這裡就沒有真實資料可以演示了。我只能借參考文獻裡的相似的圖來解說了

注意我框的04，05 這個是VBLK的序號，從4開始，每個VBLK都會有這個序號，我當時磁碟一共數下來有17個，參考文獻1裡面講的很清楚，原理是為了讓LDM能夠描述類似RAID0 RAID5等等各種情況。具體看參考文獻吧。

然後再注意我框的34和35，是講的這個VBLK是什麼型別的，不同的型別他裡面的資料也是不一樣的。然後根據不同的型別去呼叫winHex的不同模板。

元件的VBLK：0x32 
分割槽的VBLK：0x33 
磁碟的VBLK：0x34 
磁碟組的VBLK：0x35 
卷的VBLK：0x51

譬如上圖序號為04的VBLK，是34，所以就按ALT+F12，開啟模板管理，選擇裡面的0x34這個模板。

PS:這裡有個小細節游標一定要定位在第一個位元組的第一個字元上，即56的5上面，否則模板解析的資料就混亂了。

解析出來大概是這樣子的

然後我當時用excel記錄了我一共17個VBLK的記錄，其中磁碟型別的有3個，如下圖所示，都是從模板裡面記錄下來的。

然後是卷的記錄，是51的模板卷結構，用模板開啟來就是這個樣子的。

我一共記錄了3個卷，卷很重要，就是我們的碟符E盤我找到了他，他的大小是91.0341。

對上面這個記錄，我特別說一下，長度是16進位制的，可以用計算器，點選檢視，選擇程式設計師型，然後選擇16進位制，貼上進去，然後再轉十進位制，得到一個190912512數字，這個是扇區數量，一個扇區是512B，所以對190912512*512/1024/1024/1024 就得到了他的大小是91.0341G，剛好是我之前的E盤的大小。所以這個方法有戲。

接下來是33型別的分割槽資訊，非常重要的資訊，我們就是通過這個資訊來對分割槽的

我一共找到7個分割槽資訊，這個數字其實在開頭的LDM裡面有，這裡剛好吻合，這裡說一下，起始位置，7C1，轉換成十進位制是1985，然而根據之前看別的磁碟修復的經驗，找到的55AA所在扇區是2048，兩者剛好差了63，所以我用1985和2048都去嘗試了一下，發現實際上用2048才能拼接出準確的資料。這裡的原理不是很清楚，是通過實驗得到的結果。當時我利用2號分割槽的末尾去對3號分割槽的開頭，發現只要3號分割槽的起始位置加63他們的資料就能是連續的有規律的，不加就感覺對不上斷層的。

 有了這些資訊，加上我們一開始所有的資訊就可以進行推測了，我們的E盤應該是

49.99G+24.41G+0.99G+15.62G=91.034G

而且根據卷偏移我們也可以得到一個同樣的順序，如果你不知道順序的話，根據卷偏移從小到大排列也是可以得到這個結論。

這裡補充一下，運維人員一開始篤定的說我是25G+1G的說法導致我們在一開始嘗試的時候，誤導繞彎路，直到我作出了這個表，然後他竟然從阿里雲工單裡找到了一張截圖，證實了這個結論。就是下面這個圖。啪。

3.2 R-STUIDO恢復資料

接下來有了每個分割槽的起始位置和長度就可以非常簡單的操作了，配置R-studio。

找到磁碟2，選擇建立區域

依次輸入起始位置和大小，後面的型別選擇扇區，起始位置等於我們在LDM資料庫裡找到的資料+63，實驗得出，原理不清楚，之前也講過了。

重複上面的步驟，再點選磁碟3，分別建立區域把24G 1G 15G的3個區域都建立好。

然後建立虛擬卷集

然後在右側依次把剛才新增的區域0 區域1這樣的新增進來，確保順序是對的。

然後回到左側，此時虛擬卷組1 下面應該有個直接卷，雙擊他，進過短暫的載入後就可以看到我們的目錄了

目錄出來了

開啟一個db看看

拉到最後看看，資料都在，一切就跟做夢一樣。我的資料竟然通過我自己的能力找回來了。

在簡單開啟一個txt檔案，發現行的位置一點沒有錯位，說明我們拼接的分割槽是對的。在這之前，我們也用r-studio試過很多次，每次開啟這個conf檔案，裡面都是一些log日誌，原因就是我們之前被25G這個正數給誤導了，磁碟的檔案記錄說這個檔案在磁碟偏移的15W的位置，實際上找到的確實一個log檔案的內容。只要我們能準確的還原分割槽的開始和大小，就能從新拼接回這些資料。這也就是為什麼千萬不要做寫操作，因為寫操作會損壞原來位置的資料，導致恢復回來的資料有些許不一樣。也不要重建分割槽表，因為可能會將原本還在的LDM資料庫給重寫了，導致我們沒辦法還原每個分割槽對應的扇區位置。

四、感謝

最後要感謝這2天來陪伴我的同事，他們陪我加班到12點，陪我分析可能的原因，幫我找各種文章，聽我不斷的問各種問題，陪我分析各種原理。從一開始看參考文獻2像天書一樣，到今天操作winHex操作的熟練的一逼。

也要感謝DiskGen的技術人員，我是看了工具上的廣告找的他，一開始他就先幫我恢復資料，成功了再給錢，別人都是先給錢再幹活。當第一次嘗試失敗了之後，我又不斷找他，後來我先付了1000訂金，他又幫我搞了一下午，沒成功，第二天一早又幫我弄，雖然還是沒成功，他信守承退了700給我。並且做了磁碟的映象下載回去，準備上大招碎片分析。

還要感謝參考文獻1和參考文獻2，給我的幫助非常大。尤其參考文獻1裡面提供的VBLK模板，真的是全網都找不到，找到也是在論壇上，先付費註冊才能進去的那種。

寫這篇文章主要是為了讓大夥知道資料恢復不再神祕，仔細研究原理也能靠自己成功。然後給後來者一點幫助。

最後的最後，別找我恢復資料，我也是驚魂未定。 

全網首發，轉載請保留連結

https://www.cnblogs.com/JangoJing/p/13616106.html

參考文獻：

LDM詳解(重要，全靠這篇文章提供的VBLK模板，全網都找不到下載)

https://blog.csdn.net/qq_40890756/article/details/89526212

動態磁碟擴展卷丟失的恢復例項（早期提供完整思路的文章）

https://www.dgxue.com/huifu/120.html