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

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

 

一、事故来源

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