推荐阅读:

一、事故来源

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模板,真的是全网都找不到,找到也是在论坛上,先付费注册才能进去的那种。

写这篇文章主要是为了让大伙知道数据恢复不再神秘,仔细研究原理也能靠自己成功。然后给后来者一点帮助。

最后的最后,别找我恢复数据,我也是惊魂未定。

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐