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