惊魂36小时，一次生产事故，动态磁盘删除卷分区丢失，数据恢复案例实战

全是干货和实战，不上首页天理不容

 

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的空间，绝对不会有小数点的。这个错误的信息致使了咱们后面还原信息一再被误导，包括技术人员也被这个信息误导从而没办法还原数据，这个就不表了。

 

 

千万不要作写操做！！！！千万不要作写操做！！！！千万不要作写操做！！！！

动态磁盘千万不要自信还原分区表！！！！动态磁盘千万不要自信还原分区表！！！！动态磁盘千万不要自信还原分区表！！！！

 

2、修复思路

为何要提事故来源，并且说的这么详细，实际上是为了让后来者判断，个人此次事故跟本身的事故是否是相似，是否是有可借鉴的地方，而不是看了半天发现根本不适用本身的问题。

 

修复思路实际上是根据参考文献2里面提到的。根据动态磁盘的LDM数据库，进行恢复。

LDM数据库利用工具winHex就能够查看，可是网上下载的winHex广泛是不带LDM的模板的，这个模板来源是参考文献1里面提到的，很是感谢参考文献1的做者，提供了模板还提供了原理。

 

经过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

 

动态磁盘扩展卷丢失的恢复实例（早期提供完整思路的文章）

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