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