惊魂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模板，真的是全网都找不到，找到也是在论坛上，先付费注册才能进去的那种。
写这篇文章主要是为了让大伙知道数据恢复不再神秘，仔细研究原理也能靠自己成功。然后给后来者一点帮助。
最后的最后，别找我恢复数据，我也是惊魂未定。
