服务器数据恢复环境:
某品牌X系列服务器,4块SAS硬盘组建了一组RAID5阵列,还有1块磁盘作为热备盘使用。服务器上层安装的linux操作系统,操作系统上部署了一个基于oracle数据库的OA(oracle已经不再为该OA系统提供后续服务支持)。
服务器故障:
raid5中一块磁盘离线,热备盘未自动激活rebuild(原因不明)。服务器在运行一段时间后,另一块磁盘离线,RAID5阵列崩溃。用户方要求尽可能恢复服务器操作系统和服务器中的数据。
将故障服务器中所有磁盘编号后取出,硬件工程师检测后没有发现有磁盘(包括离线的2块磁盘和热备盘)存在明显的物理故障。热备盘完全没有启用,无明显同步表现。
服务器数据恢复方案:
1、将所有磁盘以只读方式进行扇区级的全盘镜像,镜像完成后将所有磁盘按照编号还原到原服务器中,后续的数据分析和数据恢复操作都基于镜像文件进行,避免对原始磁盘数据造成二次破坏。
2、基于镜像文件分析RAID5结构,获取到RAID5条带规则、条带大小、校验方向、META区域等raid结构相关信息。
3、根据获取到的RAID结构信息虚拟重构RAID5。
4、解释虚拟磁盘及文件系统。
5、检测重构的raid5结构是否正确,如不正确,重复2-4过程。
6、检测raid5结构没有问题以及数据无误后,按用户要求回迁数据。
服务器数据恢复过程:
1、在对故障服务器中磁盘做镜像时,发现后离线的那块磁盘有十几个坏扇区,其余磁盘没有发现有坏道。
2、基于镜像文件分析获取raid5结构相关信息。
3、根据获取到的raid结构信息虚拟重组raid5,重组完成后验证数据,发现200M以上的压缩包解压没有报错,由此可以确定分析出来的raid5结构正确。
4、按照该raid5结构生成虚拟RAID到一块单硬盘上,打开文件系统没有出现报错。
5、确定备份包没有问题和经过用户方的同意后,用新硬盘更换存在坏扇区的那块磁盘,然后对原盘重建RAID。
6、将恢复好的单盘用USB方式接入故障服务器,用linux SystemRescueCd启动故障服务器,然后使用dd命令进行全盘回写。
7、dd所有数据后,启动操作系统,无法进入操作系统桌面并出现报错,报错信息为:“/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied”,北亚企安数据恢复工程师初步判断此文件权限有问题。用SystemRescueCd重启后检查,发现此文件时间、权限、大小均有明显错误,很显然节点损坏。
8、重新分析重组数据中的根分区,定位出错的/sbin/pidof/,发现出错是由磁盘坏道导致的。
9、北亚企安数据恢复工程师使用3块完好的磁盘对后离线、存在坏道的那块磁盘的损坏区域进行xor补齐。补齐后重新校验文件系统依然有错误。再次检查inode表,发现后离线、存在坏道的磁盘的损坏区域有部分节点表现为(55 55 55部分):
很明显,虽然节点中描述的uid正常存在,但属性、大小、最初的分配块全部是错误的。北亚企安数据恢复工程师按照所有可能性进行分析,确定无法找回此损坏节点。只能修复此节点或者复制一个相同的文件过来。
10、针对所有可能有错的文件,通过日志确定原节点块的节点信息,再做修正。
11、修正后重新dd根分区,执行fsck -fn /dev/sda5/进行检测,依然报错。
12、根据报错提示,在系统中发现有多个节点共用同样的数据块。按照提示分析底层,发现存在节点信息的新旧交集。
13、按节点所属的文件进行区别,清除错误节点后,再次执行fsck -fn /dev/sda5进行检测,依然有极少量的报错信息。根据报错提示,发现这些节点多位于doc目录下,不影响系统启动。直接执行fsck -fy /dev/sda5/强行修复。
14、修复完成后重启系统,成功进入操作系统桌面。
15、启动oracle数据库服务,启动应用软件,一切正常,无报错。
16、用户方对操作系统,oracle数据库以及OA数据进行检测,经过多部门的反复检测,确认恢复数据完整可用。本次数据恢复工作完成。