驚魂36小時，一次生產事故，動態磁盤刪除卷分區丟失，數據恢復案例實戰
全是乾貨和實戰，不上首頁天理不容html
1、事故來源
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的空間，絕對不會有小數點的。這個錯誤的信息致使了咱們後面還原信息一再被誤導，包括技術人員也被這個信息誤導從而沒辦法還原數據，這個就不表了。運維
千萬不要作寫操做！！！！千萬不要作寫操做！！！！千萬不要作寫操做！！！！工具
動態磁盤千萬不要自信還原分區表！！！！動態磁盤千萬不要自信還原分區表！！！！動態磁盤千萬不要自信還原分區表！！！！ui
2、修復思路
爲何要提事故來源，並且說的這麼詳細，實際上是爲了讓後來者判斷，個人此次事故跟本身的事故是否是相似，是否是有可借鑑的地方，而不是看了半天發現根本不適用本身的問題。阿里雲
修復思路實際上是根據參考文獻2裏面提到的。根據動態磁盤的LDM數據庫，進行恢復。spa
LDM數據庫利用工具winHex就能夠查看，可是網上下載的winHex廣泛是不帶LDM的模板的，這個模板來源是參考文獻1裏面提到的，很是感謝參考文獻1的做者，提供了模板還提供了原理。.net
經過LDM數據庫給出的信息，咱們就能夠知道E盤的組成，而後利用r-studio工具，建立虛擬磁盤進行組合，而後就把一個完整的E盤的邏輯分區給恢復了，而後利用這個虛擬磁盤把文件導出到另一個磁盤中。
3、實戰操做
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數據庫給重寫了，致使咱們沒辦法還原每一個分區對應的扇區位置。
4、感謝
最後要感謝這2天來陪伴個人同事，他們陪我加班到12點，陪我分析可能的緣由，幫我找各類文章，聽我不斷的問各類問題，陪我分析各類原理。從一開始看參考文獻2像天書同樣，到今天操做winHex操做的熟練的一逼。
也要感謝DiskGen的技術人員，我是看了工具上的廣告找的他，一開始他就先幫我恢復數據，成功了再給錢，別人都是先給錢再幹活。當第一次嘗試失敗了以後，我又不斷找他，後來我先付了1000訂金，他又幫我搞了一下午，沒成功，次日一早又幫我弄，雖然仍是沒成功，他信守承退了700給我。而且作了磁盤的鏡像下載回去，準備上大招碎片分析。
還要感謝參考文獻1和參考文獻2，給個人幫助很是大。尤爲參考文獻1裏面提供的VBLK模板，真的是全網都找不到，找到也是在論壇上，先付費註冊才能進去的那種。
寫這篇文章主要是爲了讓大夥知道數據恢復再也不神祕，仔細研究原理也能靠本身成功。而後給後來者一點幫助。
最後的最後，別找我恢復數據，我也是驚魂未定。
5、套路
週末在家又想到了一些要補充的信息，關於這一行的套路，在數據找不回來的時候，咱們也找過第三方的數據恢復公司。過後我以爲他明顯是在套路我，基於咱們對數據的着急和不懂。
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
動態磁盤擴展卷丟失的恢復實例（早期提供完整思路的文章）