全是干貨和實戰，不上首頁天理不容
一、事故來源
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模板，真的是全網都找不到，找到也是在論壇上，先付費注冊才能進去的那種。
寫這篇文章主要是為了讓大伙知道數據恢復不再神秘，仔細研究原理也能靠自己成功。然后給后來者一點幫助。
最后的最后，別找我恢復數據，我也是驚魂未定。
五、套路
周末在家又想到了一些要補充的信息，關於這一行的套路，在數據找不回來的時候，我們也找過第三方的數據恢復公司。事后我覺得他明顯是在套路我，基於我們對數據的着急和不懂。
1. 找到某軍數據恢復公司，公司應該就他一個人，接到電話基本信息都沒了解的情況下就回答說這個肯定能恢復，你要相信我們某軍的實力。
2. 先款后遠程，不成功退錢，這一步只是2000-3000的小錢，還支持淘寶。付款，遠程。
3. 遠程后copy2個軟件在服務器上，一通操作，跟之前DiskGen的技術人員不一樣的是，他根本沒有進一步了解磁盤之前的結構和我們之前操作的歷史記錄。一通掃描后一個電話打過來。
4. 你們這個不好恢復，你看你們裝了個r-studio，破壞了磁盤數據。我回答我們沒有裝在丟失分區的磁盤，我們裝在C盤的，這個不影響的。 對方說，這個不跟你講了，好了吧。反正你們現在這個只有一條路，磁盤鏡像，我離線恢復，價格你可以去市場上打聽打聽，打聽完了再來我這里報價。我某軍的實力就擺在這里。之前的3000現在就給你退款，你申請退款，我秒退給你。
5. 然后3000塊退款回來，新的陷阱就是9500-10000的了。
為什么說是套路，沒做過磁盤恢復的我，總看過一些磁盤恢復的文章吧，違反常識的話，說我在其他盤寫操作影響了丟失分區的數據恢復，這個是第一點。 第二點，一個真心想恢復數據的技術員怎么能對客戶之前磁盤的狀態和操作記錄不感興趣，沒有這些信息你如何能進行數據恢復。 第三點，遠程操作過程中只是復制了2個軟件，進行了一通掃描，掃描結果我也看得懂，就是啥都沒做，一點技術含量都沒有。
這就是利用客戶着急的心情一步一步的套路你，雖然不知道某軍如果拿到磁盤鏡像后能不能搞定，但前面這一系列操作下來，跟另外一家公司的技術員對比下來，實在不敢恭維。
全網首發，轉載請保留鏈接
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