一台Sun工作站,使用Sparc架构的Solaris系统,由于工作站自身的存储空间不够使用,所以又扩展了一台DAS设备,即“直接附加存储”设备。DAS设备由4块36GB的SCSI硬盘组建为RAID-5,不知什么原因导致DAS设备突然崩溃,文件系统无法挂载。DAS设备的逻辑盘中有两个切片,每个切片大约50GB,现在数据全部丢失。

为了恢复DAS设备中的数据,把设备中的4块SCSI硬盘去RAID化后插入SCSI模组中分别做成文件镜像,镜像文件命名为0.img、1.img、2.img和3.img,在分析时我们称文件0.img为“硬盘0”、文件1.img为“硬盘1”、文件2.img为“硬盘2”、文件3.img为“硬盘3”,但这些文件的编号只是按照硬盘在DAS设备中的物理顺序编排的,并不一定与RAID中各个硬盘的盘序相符。

分析RAID开始扇区

用WinHex同时打开4块物理盘的镜像文件,首先查看每块物理盘的第一个扇区。“硬盘0”的第一个扇区的内容如图19-17所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-17 “硬盘0”的第一个扇区

“硬盘1”的第一个扇区的内容如图19-18所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-18 “硬盘1”的第一个扇区

“硬盘2”的第一个扇区的内容如图19-19所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-19 “硬盘2”的第一个扇区

“硬盘3”的第一个扇区的内容如图19-20所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-20 “硬盘3”的第一个扇区

从4块成员盘的第一个扇区可以看出,“硬盘3”的第一个扇区是磁盘标签。查看该磁盘标签的切片表可以看到,RAID-5的逻辑盘分为两个切片,第一个切片开始于磁盘的0柱面,也即0扇区,大小为106 569 728扇区;第二个切片起始于26 018柱面。从磁盘标签中还能得到该磁盘的磁头数为64,每磁道扇区数也为64,所以26 018柱面换算为LBA地址为:26018×64×64=106569728,这就是第二个切片的起始扇区号了,第二个切片的大小为106 573 824扇区。对这些参数进行分析能够看出该磁盘标签是一个有效的磁盘标签,所以可以推断该RAID-5起始扇区就是物理盘的0扇区。

分析RAID结构

分析条带大小

通过第1步的分析已知“硬盘3”的第一个扇区是磁盘标签,那么其16号扇区应该是超级块。跳转到“硬盘3”的16号扇区,内容如图19-21所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-21 “硬盘3”的16号扇区

从内容来看,“硬盘3”的16号扇区很像超级块的第一个扇区。为了进一步确认,我们再查看“硬盘3”的18号扇区是否有超级块的签名。“硬盘3”的18号扇区的内容如图19-22所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-22 “硬盘3”的18号扇区

“硬盘3”的18号扇区有超级块的签名,这就可以肯定“硬盘3”的16号扇区就是超级块的开始扇区。但我们还需要分析该超级块是原始超级块还是备份超级块。用WinHex的模板查看一下该超级块的参数信息,如图19-23所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-23 超级块的参数模板

从图19-23可以看出,超级块中的“最后写入时间”显示为“2009-01-03”。这正是用户的服务器出故障当天的日期,从这一点可以判断该超级块是原始超级块。

确定了“硬盘3”的16号扇区为文件系统的原始超级块,这就可以说明该RAID-5的条带大小一定大于16个扇区。

另外从超级块的参数中还可以获知“备份超级块的相对偏移”为16,说明备份超级块相对于柱面组参考位置的偏移量是16段,而“每段字节数”为1024,所以0号柱面组的超级块备份起始于32号扇区。我们跳转到“硬盘3”的32号扇区,结果并不是超级块,而是i-节点表的结构,如图19-24所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-24 “硬盘3”的32号扇区

“硬盘3”的32号扇区并不是超级块的备份。从这一点其实就可以说明条带大小一定是32个扇区了,并且超级块的备份一定在其他某个成员盘的0号扇区。

为了进一步验证,我们再分析其他三块成员盘的0号扇区,结果发现“硬盘2”的0号扇区为超级块,其内容可以参看前面的图19-19。

再查看“硬盘2”的2号扇区是否有超级块的签名。“硬盘2”的2号扇区的内容如图19-25所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-25 “硬盘2”的2号扇区

从图19-25可以看到“硬盘2”的2号扇区是有超级块的签名标志的,所以“硬盘2”的0号扇区一定是超级块的起始扇区了。

“硬盘2”的0号扇区所在超级块的参数如图19-26所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-26 “硬盘2”的0号扇区所在超级块的参数

分析发现这个超级块的“最后写入时间”是“2006-07-04”,是很久以前的时间了,说明这是系统的初始时间,并没有随着系统的运行而改变,那么这个超级块就是原始超级块的备份,同时也证明了该RAID条带大小为32扇区。

分析盘序和校验方向

通过上面的分析已经知道“硬盘3”的第一个扇区为磁盘标签,也就是逻辑磁盘数据的开始,所以这块盘在RAID中的顺序要么是“0号盘”,要么是“1号盘”。如果该RAID-5为左结构,“硬盘3”就是“0号盘”;如果该RAID-5为右结构,“硬盘3”就是“1号盘”。

又知道“硬盘2”的第一个扇区为超级块的备份,也就是RAID-5逻辑盘数据的32号扇区,所以“硬盘2”一定跟在硬盘3之后,也就是说它要么是“1号盘”,要么是“2号盘”。

继续分析“硬盘1”和“硬盘0”。查看“硬盘1”的0号扇区,发现是i-节点表的开始,第一个i-节点和第二个i-节点是空的,第三个i-节点是根目录的i-节点,如图19-27所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-27 “硬盘1”的0号扇区

在超级块中描述了“i-节点表相对于柱面组参考位置的偏移”是32段,也就是64号扇区,说明“硬盘1”的0号扇区正是RAID-5逻辑磁盘数据的64号扇区,那么证明“硬盘1”在盘序上是接在“硬盘2”之后的,同时也再一次地验证了条带大小是32扇区。

“硬盘3”、“硬盘2”、“硬盘1”的0号扇区都是正常数据,那么“硬盘0”的0号扇区就一定是校验了,因为RAID-5的一个条带组中必定有一个条带为校验,查看“硬盘0”的0号扇区,果然是校验,其内容如图19-28所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-28 “硬盘0”的0号扇区是校验

“硬盘0”的0号扇区看起来有些像磁盘标签,但数据是错乱的。这是因为这个扇区是被异或出来的。

通过以上分析可知,如果该RAID-5是左结构,那么盘序为:“硬盘3”为“0号盘”,“硬盘2”为“1号盘”,“硬盘1”为“2号盘”,“硬盘0”为“3号盘”,其结构如图19-29所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-29 RAID-5左结构的盘序

如果该RAID-5是右结构,那么盘序为:“硬盘0”为“0号盘”,“硬盘3”为“1号盘”,“硬盘2”为“2号盘”,“硬盘1”为“3号盘”,其结构如图19-30所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-30 RAID-5右结构的盘序

图19-29和图19-30中的两种结构必定只有一种是正确的,那么如何判断哪一种是正确的呢?

从两幅图中可以看出,如果图19-29的结构是正确的,那么“硬盘1”的第二个条带一定是校验;如果图19-30的结构是正确的,那么“硬盘1”的第二个条带一定是数据,所以我们可以把焦点放在“硬盘1”的第二个条带上,看这个条带到底是数据还是校验。

因为该RAID-5条带大小为32个扇区,所以第二个条带就开始于物理盘的32号扇区。跳转到“硬盘1”的32号扇区,其内容如图19-31所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-31 “硬盘1”的32号扇区

从图19-31中可以看出其结构是i-节点表中的空节点,应该是数据而不是校验。为了进一步验证,同时查看一下其他3块成员盘的32号扇区。

因为“硬盘0”的第一个条带是校验,所以其第二个条带一定是数据,如图19-32所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-32 “硬盘0”的32号扇区

“硬盘2”的32号扇区的内容如图19-33所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-33 “硬盘2”的32号扇区

“硬盘3”的32号扇区的内容如图19-34所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-34 “硬盘3”的32号扇区

从其他3块成员盘32号扇区的内容可以发现全都与“硬盘1”的32号扇区结构一模一样。这就无法判断“硬盘1”的32号扇区到底是数据还是校验了。

32号扇区随后的一大部分区域都是i-节点表的区域,并且i-节点表中都是空i-节点,所以根本无法做出判断。这时我们就可以用到本书在第17章中讲解的反推法进行判断。

反推法的具体做法是,到“硬盘2”中任意位置找一个校验扇区,通过这个校验扇区的扇区号,反推出该盘中第一个校验块的所在扇区。

那么如何能够快速找到“硬盘2”中的校验扇区呢?根据超级块中参数的描述,第一个柱面组中数据块的开始位置在832号段,根据这个参数可知数据块开始于逻辑盘的1664扇区,转换到物理盘中的大概位置在550号扇区左右,于是我们可以到每块成员盘的550号扇区附近进行分析。

经过对550号扇区附近的分析,发现544号扇区是一个理想的分析目标。我们先看“硬盘3”的544号扇区,其内容如图19-35所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-35 “硬盘3”的544号扇区

从图19-35中可以看出“硬盘3”的544号扇区是i-节点表中的空i-节点。

再看“硬盘2”的544号扇区,其内容如图19-36所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-36 “硬盘2”的544号扇区

从图19-36中可以看出“硬盘2”的544号扇区是柱面组概要的内容。

再看“硬盘0”的544号扇区,其内容如图19-37所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-37 “硬盘0”的544号扇区

从图19-37中可以看出“硬盘0”的544号扇区是目录区的内容,其中只有两个目录项,即“.”目录和“..”目录的目录项。

最后看“硬盘1”的544号扇区,其内容如图19-38所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-38 “硬盘1”的544号扇区

图19-38中的数据如果不仔细看,会觉得很像柱面组概要的内容,但如果仔细分析一下,就会看出阴影部分的数据完全不合常理,再跟其他三个成员盘的544号扇区对比,就可以确定“硬盘1”的544号扇区是校验信息。

现在判断了“硬盘1”的544号扇区是校验,就可以用反推法判断“硬盘1”的第一个校验块所在扇区了,具体计算方法是

544 MOD(32×4)=32

计算的结果等于32,这个值的含义就是:32号扇区一定是校验信息,而32号扇区正好是第二个条带的开始,所以“硬盘1”的第二个条带是该盘的第一个校验块。

在回过头对比图19-29和图19-30,发现图19-29符合“硬盘1”的第二个条带是校验块的结论,所以该RAID-5的校验方向为左结构,盘序为:“硬盘3”为“0号盘”,“硬盘2”为“1号盘”,“硬盘1”为“2号盘”,“硬盘0”为“3号盘”。

分析数据循环方向

条带大小、盘序、校验方向都确定了,最后就剩下数据的循环方向了,即同步还是异步的问题。

为了分析数据循环方向,我们还是回到每块成员盘的544号扇区附件进行分析。544号扇区附近每块成员盘的结构如图19-39所示。

从图19-39中很明显可以看出,如果“数据块A”的数据跟“数据块B”衔接,那么该RAID-5为异步结构;如果“数据块A”跟“数据块C”衔接,那么该RAID-5为同步结构。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-39 544号扇区附近每块成员盘的结构

为了确定“数据块A”跟谁衔接,我们可以分析“数据块A”最后一个扇区的数据及“数据块B”、“数据块C”的第一个扇区的数据。

“数据块A”最后一个扇区就是“硬盘1”的543号扇区,其内容如图19-40所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-40 “硬盘1”的543号扇区

从图19-40可以看出,这个扇区的内容是i-节点表中的空i-节点。

“数据块B”第一个扇区就是“硬盘3”的544号扇区,其内容如图19-41所示。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-41 “硬盘3”的544号扇区

很明显,图19-41中的内容也是i-节点表中的空i-节点。

“数据块C”第一个扇区就是“硬盘0”的544号扇区,其内容如图19-42所示。

很明显,图19-42中的内容是目录项,所以“数据块A”的数据应该跟“数据块B”衔接,那么该RAID-5的数据循环方向为异步。

Sun Solaris系统服务器RAID-5数据恢复实例分析-数据恢复迷

图19-42 “硬盘0”的544号扇区

数据重组

通过第2步的分析已经得到了RAID-5的具体结构,最后就可以通过数据重组获得数据了。能够支持UFS文件系统的工具包括X-Ways Forensics、R-studio和UFS Explorer,用这三个工具进行重组,都可以直接看到UFS文件系统中的数据。

重组的具体方法在前面章节介绍了很多,为了节约篇幅此处就不再讲述了。