本例是一个在成员盘的中部存放配置信息的RAID-5案例。对于这种把RAID信息放在成员盘中部的RAID,分析RAID结构的难度比较大,如果不能准确地找到物理盘中部的配置信息并把它们去除,那么在重组RAID后就会影响到逻辑卷大部分数据的正确性,不只是系统配置信息所在地址后面的数据会受影响,系统配置信息所在地址前面的数据也同样会受影响,因为NTFS文件系统内的数据是分布存储的,逻辑卷的中间插入了RAID信息,就会导致很多地址的指向发生错误。下面我们开始具体分析。
这个RAID-5案例由3块SCSI硬盘组成,每个成员盘的容量为18GB,我们将3块成员盘做成3个文件镜像,因为这个案例比较复杂,需要全盘分析,所以我们对3块物理盘都做了完整镜像,这里称文件“0.img”为“硬盘0”,文件“1.img”为“硬盘1”,文件“2.img”为“硬盘2”,但文件的编号只是随意编排的,并不一定与RAID-5中各个成员盘的盘序相符。
用WinHex同时打开3个镜像文件,从第一个扇区入手,“硬盘0”的0号扇区内容如图17-161所示。
从内容看“硬盘0”的第一个扇区肯定不是MBR。
再看“硬盘1”,它的0号扇区内容如图17-162所示。
“硬盘1”的第一个扇区的内容与“硬盘0”第一个扇区的内容类似,同样不是MBR。
最后再看“硬盘2”,它的0号扇区内容如图17-163所示。
“硬盘2”的第一个扇区显然是MBR,但仔细分析发现分区表中有一个动态磁盘分区的表项,难道说这个RAID-5是动态磁盘软RAID?
其实根据经验来看,“硬盘0”和“硬盘1”的第一个扇区的数据是RAID信息,所以“硬盘2”的第一个扇区的数据也应该是RAID信息,但可能是用户或者其他技术人员把该硬盘独立连接到计算机上被系统做了初始化并自动转换为动态磁盘,所以第一个扇区被写入MBR,同时该硬盘的6号扇区也会写入动态磁盘的私有头,硬盘最后1MB的空间还会被写入LDM,这属于一种二次破坏,是数据恢复最忌讳的行为。幸运的是,该硬盘前部存放的是RAID配置信息,而最后1MB的空间则没有使用,所以这个二次破坏并没有影响到用户的数据。
接下来在3块物理盘中搜索十六进制数值“55 AA”,目的是查找RAID-5逻辑盘的MBR,结果在“硬盘2”128号扇区发现了MBR,如图17-164所示。
在MBR的分区表中有3个分区表项,用WinHex模板查看其具体数值,如图17-165所示。
分区表的第一项描述了一个配置分区,分区开始于63号扇区,大小为64 197扇区;分区表的第二项描述了一个NTFS分区,分区开始于64 260号扇区,大小为8 241 345扇区;分区表的第三项也描述了一个NTFS分区,分区开始于8 305 605号扇区,大小为62 765 892扇区。从这些数值可以计算出所有分区所占扇区数的总和为71 071 497,这与3块18GB的物理盘组成的RAID-5逻辑盘的总扇区数之和基本相等,所以可以判断这个MBR就是RAID-5逻辑盘的有效MBR,从而也证明了该MBR所在扇区128就是RAID起始扇区。
从图17-165所示的分区表参数模板中我们可以看到该RAID-5逻辑盘的第一个分区开始于63号扇区,也就是说RAID-5逻辑盘的63号扇区应该是该分区的DBR。现在我们跳转到硬盘2的相对63号扇区,换算为绝对扇区号为191,该扇区内容如图17-166所示。
从图17-166可以看出来这个扇区的确是DBR,并且是FAT16文件系统的DBR,其BPB参数如图17-167所示。
DBR的BPB参数中显示分区的扇区总数为64 197,隐藏扇区数为63,这些数值都与128号扇区的MBR分区表中第一个表项的信息相符,说明这就是该RAID-5逻辑盘第一个分区的DBR,同时也证明了该RAID-5的条带大小是大于或等于64扇区的。
DBR的BPB参数中还显示“DBR保留扇区数”为1,说明在逻辑结构上DBR之后紧跟着的扇区就应该是FAT表的开始。我们往下翻一个扇区,即192号扇区,其内容如图17-168所示。
“硬盘2”的192号扇区的确是FAT表的数据结构,但并不是FAT表的开始,从这里可以推断该RAID-5的条带大小一定就是64扇区了,所以FAT表开始扇区的数据写到其他成员盘中了。
为了进一步确认以上的结论,我们可以同时查看“硬盘0”和“硬盘1”的128号扇区,看看有没有FAT表开始扇区的数据。“硬盘0”的192号扇区内容如图17-169所示。
“硬盘0”的128号扇区很像是校验信息。再看“硬盘1”的128号扇区,如图17-170所示。
“硬盘1”的128号扇区正是FAT表的开始,这就进一步验证了该RAID-5的条带大小一定是64扇区。
通过前面的分析已经知道,“硬盘2”的128号扇区是MBR,191号扇区是DBR;而“硬盘1”的128号扇区是FAT表的起始扇区,该内容应该衔接在“硬盘2”的191号扇区之后;“硬盘0”的128号扇区是校验。根据以上这些信息可知,如果该RAID-5是左结构,“硬盘2”就是“0号盘”,“硬盘1”是“1号盘”,“硬盘0”则是“2号盘”,其结构如图17-171所示。
如果该RAID-5是右结构,那么“硬盘0”就是“0号盘”,“硬盘2”是“1号盘”,“硬盘1”则是“2号盘”,其结构如图17-172所示。
所以只要把该RAID-5的左、右结构确定了,盘序也就可以确定了。
我们从“硬盘2”入手分析,“硬盘0”的128号扇区是MBR,所以其第一个条带是数据块,只要判断出“硬盘2”的第二个条带是数据块还是校验块,就可以知道该RAID-5是左结构还是右结构了。可以对照图17-171和图17-172来看,如果“硬盘2”的第二个条带是数据块,那么该RAID-5就是左结构;如果硬盘2的第二个条带是校验块,那么该RAID-5就是右结构。
已经知道该RAID-5的起始扇区是物理盘的128号扇区,条带大小是64扇区,所以第二个条带在物理盘中的绝对起始扇区号是192,“硬盘2”的192号扇区我们在前面已经查看过,可以参考图17-168,其内容是FAT表的数据结构,也就是说这个扇区是数据,不是校验。为了进一步验证,我们再查看一下“硬盘0”的192号扇区和“硬盘1”的192号扇区。
“硬盘0”的192号扇区内容如图17-173所示。
“硬盘0”的192号扇区也是FAT表内的数据结构,不是校验,所以“硬盘1”的192号扇区就应该是校验了,其内容如图17-174所示。
从图17-174中的内容看,“硬盘1”的192号扇区内的数据的确是由“硬盘0”的192号扇区和“硬盘2”的192号扇区的数据经过异或运算的结果,所以它就是校验信息,从而确定了“硬盘2”的192号扇区是数据,不是校验,所以该RAID-5一定为左结构,从而得出其盘序为:“硬盘2”是“0号盘”,“硬盘1”是“1号盘”,“硬盘0”是“2号盘”。
数据的循环方向即同步和异步,我们已经分析出该RAID-5是左结构,所以它要么是左异步,要么是左同步。如果是左异步,其结构如图17-175所示。
如果是左同步,其结构如图17-176所示。
现在我们只要分析数据块“1”最后一个扇区后面衔接的数据在“0号盘”上还是在“2号盘”上。如果在“0号盘”上,就是左异步;如果在“2号盘”上,就是左同步。
数据块“1”是“1号盘”的第一个条带,其最后一个扇区也就是“硬盘1”的191号扇区,该扇区的内容如图17-177所示。
从内容看,“硬盘1”的191号扇区是FAT表中的部分数据,其最后一个表项值为“00 40”。为了判断该扇区之后的数据写入的位置,我们需要分别查看“0号盘”和“2号盘”第二个条带的开始扇区。
“0号盘”第二个条带的开始扇区也就是“硬盘2”的192号扇区,其内容如图17-178所示。
“硬盘0”的192号扇区也是FAT表中的部分数据,其第一个表项值为“01 80”,显然与“硬盘1”的191号扇区中最后一个表项值“00 40”不衔接。
再看“硬盘2”的192号扇区,其内容如图17-179所示。
“硬盘2”的192号扇区同样是FAT表中的部分数据,其第一个表项值为“01 40”,显然与“硬盘1”的191号扇区中最后一个表项值“00 40”衔接,所以该RAID-5的数据的循环方向为异步结构。
综上所述,该RAID-5应该为左异步结构。
为了分析的时候更加直观,我们选择用WinHex进行重组,打开菜单栏“专业工具”下的“重组RAID”选项,按照分析好的盘序及RAID结构设置各个参数,如图17-180所示。
RAID参数设置完成后单击“确定”按钮,WinHex中就会出现一个“RAID 5:2+1+0”选项卡,如图17-181所示。
这个“RAID 5:2+1+0”选项卡中的数据就是虚拟重组出来的RAID-5逻辑盘,我们可以看到逻辑盘中有3个分区,如图17-182所示。
表面看起来这3个分区都是正确的,第一个分区是配置分区,没有用户的数据,可以不用理会;第二个分区是系统区,大小为3.9GB,打开后数据完全正常,但该分区也没有重要数据;第三个分区是数据分区,大小为29.9GB,用户的重要数据都在这个分区内,其中最重要的是一个数据库文件,我们直接打开这个分区,如图17-183所示。
单击分区3的“打开”选项后,WinHex会对这个分区内的数据做一遍“磁盘快照”,然后就能够预览分区内的数据了。
在数据浏览框内找到用户的数据库文件,结果发现文件是错误的,并且文件的大小显示为0字节,如图17-184所示。
用户说这个数据库文件非常重要,其他文件都可以不要,但如果这个数据库文件如果恢复不成功,损失将会非常大。
根据该数据库文件的MFT记录分析,其Data Run所指向的地址中的内容根本就不是数据库的结构,看来问题比较严重。
经过对该分区其他文件的分析发现,分区内的大部分数据都是错误的,这说明RAID结构上可以会有问题。
回顾前面的分析过程,RAID起始扇区、盘序、条带大小、循环方向都分析得很严谨,不会是这些环节出现问题,那么问题还会出现在哪个环节呢?
考虑到该RAID-5逻辑盘的三个分区中,前两个分区的数据都完全正常,只有第三个分区的数据不正常,所以就从逻辑盘的第三个分区入手进行分析。
在上一步中我们已经用WinHex把该RAID-5进行了虚拟重组,并且能够直接访问逻辑盘的第三个分区,这就是我们选用WinHex进行重组的原因。WinHex的这一功能非常方便,对我们的分析有很大帮助。
我们利用NTFS文件系统的结构知识,对逻辑盘的第三个分区进行了大量的计算和分析,最终发现在$MFT文件当中夹着一段RIAD信息,把$MFT文件隔开了,所以导致分区内的很多文件出错。
RIAD信息在第三个分区中的开始位置是80 325号扇区,而80 324号扇区还是完好的文件记录,如图17-185所示。
80 324号扇区是一个文件记录的前半部分,80 325号扇区则应该是这个文件记录的后半部分,但实际上80 325号扇区已经不是文件记录的内容了,如图17-186所示。
据此分析可知,RAID信息是从80 325号扇区开始的。继续往后分析发现,80 324号扇区所在文件记录的后半部分出现在分区3的83 067号扇区,其内容如图17-187所示。
83 067号扇区的前一个扇区,即83 066号扇区则是一个空扇区,如图17-188所示。
从这一现象可以推断,RAID信息就结束于83 066号扇区,从83 067号扇区往后则是正常的数据。
所以,在该RAID-5逻辑盘的分区3内部,80 325号扇区是RAID信息的起始地址,83 066号扇区则是RAID信息的结束地址。根据这两个数值可以计算出RAID信息一共占用了2742个扇区。根据RAID-5数据分布的结构特点,把2742除以2,结果等于1371,这个数值就是RAID信息在每块RAID-5物理盘内所占的扇区数。
通过上面的分析,我们可以把这3块RAID-5物理盘以及现在重组出来的RAID-5逻辑盘的结构画成一幅图,如图17-189所示。
从图17-189的结构来看,因为在3块物理盘中都有1371个扇区的RAID信息,在这种情况下重组数据后,RAID信息刚好位于RAID-5逻辑盘的第三个分区内,占用了2742个扇区,这就导致了逻辑盘第三个分区的数据错误。
解决这个问题的思路有两个:
第一,分析逻辑盘,找到RAID信息在逻辑盘中的开始位置和结束位置,然后将逻辑盘内RAID信息之前的扇区做成镜像,再将逻辑盘内RAID信息之后的扇区做成镜像,把两部分镜像拼接到一起,就可以完整地恢复出所有数据。
第二,分析物理盘,找到RAID信息在物理盘中的开始位置和结束位置,然后将3块物理盘内RAID信息之前的扇区(即图17-189中的“A1”、“A2”、“A3”部分)分别用R-studio的“Create Region”功能做成3个区域,再把“A1”、“A2”、“A3”这3个区域组成虚拟RAID-5;接下来将3块物理盘内RAID信息之后的扇区(即图17-189中的“B1”、“B2”、“B3”部分)分别用R-studio的“Create Region”功能做成3个区域,再把“B1”、“B2”、“B3”这3个区域组成虚拟RAID-5;最后把两个虚拟RAID-5用R-studio虚拟成JBOD,就可以完整地恢复出所有数据。这种方法完全利用虚拟重组,避免了做镜像的操作。
这个案例我们用第一种思路进行恢复。
之前我们已经分析出在该RAID-5逻辑盘的分区3内部,80 325号扇区是RAID信息的起始地址,83 066号扇区则是RAID信息的结束地址,所以我们就把分区3的0到80 324号扇区做成镜像,再把分区3的83 067号扇区到分区末尾做成镜像,之后把两部分镜像拼接到一起并命名为Partition3.img。这是在利用WinHex的磁盘快照功能浏览该分区的数据,用户需要的数据库文件已经完全正确了,如图17-190所示。
将这一对数据库文件拷贝出来验证,没有出现任何问题,这个RAID-5的数据圆满恢复成功。