服务器数据恢复-Linux服务器RAID5数据恢复案例

电子说

1.3w人已加入

描述

服务器数据恢复环境:
一台Linux Redhat操作系统服务器上有一组由5块硬盘组建的raid5阵列,包含一块热备盘。上层部署一个OA系统和Oracle数据库。

服务器故障:
raid5阵列中的1块磁盘离线,硬盘离线却没有激活热备盘,直到另外一块磁盘离线导致阵列崩溃。
用户要求恢复raid5的数据和尽可能还原操作系统。经过北亚企安数据恢复工程师初步检测,故障服务器中所有硬盘均没有发现明显物理故障,也没有发现有明显的同步迹象。

服务器数据恢复过程:
1、将故障服务器关机后,把服务器中的磁盘编号后取出槽位,经过硬件工程师检测,没有发现有硬盘存在物理故障。以只读方式将所有磁盘进行完整镜像备份。备份完成后根据编号将磁盘还原至原服务器中,后期的数据分析和数据恢复操作基于镜像进行,避免对原始磁盘数据造成二次破坏。
2、基于镜像文件进行分析,北亚企安数据恢复工程师在后掉线的那块硬盘红发现了十几个坏扇区,其他硬盘发现都没有坏道。继续分析raid5结构相关信息。

服务器

北亚企安数据恢复——RAID5数据恢复



3、使用分析获取到的raid结构相关信息尝试重组raid5阵列。经过验证确定分析出来的raid结构是正确的。按照这个结构在一块单盘上生成虚拟raid并尝试打开,没有明显报错。
4、和用户方沟通后,用户方要求我们对原盘重建raid(有坏道的那块盘已经替换)。把步骤2中恢复好的单盘用USB接到故障服务器上,再用linux SystemRescueCd启动,通过dd命令进行全盘回写,回写完成后启动操作系统。
5、操作系统启动过程中报错:/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied,北亚企安数据恢复工程师推测报错原因是文件权限有问题。用SystemRescueCd进行重启后进行检查,发现文件的权限、大小、时间都有明显的错误,节点损坏。
6、找到报错原因后对重组数据中的根分区进行重新分析,定位出错的/sbin/pidof,发现发生故障的原因还是由于那块后掉线硬盘的坏道。我们只好使用raid阵列中完好的磁盘对那块有坏道的磁盘的损坏区域进行xor补齐。
7、补齐之后对文件系统进行检验依然报错。再一次检查iNode表发现那块有坏道磁盘的损坏区域有部分节点表现为下图中55 55 55部分。

服务器

北亚企安数据恢复——RAID5数据恢复



通过上图可以看到,虽然节点中描述的uid看起来是正常的,但是大小、属性、最初的分配块都是错误的。北亚企安数据恢复工程师团队对所有可以想到的数据恢复方案进行分析后,没有找到好的办法将这个损坏的节点找回来,只能尝试修复或者以相同文件进行代替。
8、通过日志把一切可能有错的文件原节点块的节点信息确定出来,然后再进行修正。修正之后重新dd了根分区,但是执行fsck -fn /dev/sda5仍然报错。

服务器

北亚企安数据恢复——RAID5数据恢复


9、根据报错提示继续查看分析,发现系统中有多个节点共用同样的数据块,应该是磁盘早掉线而导致出现了节点信息新旧交集的情况。将错误节点清除后再次执行fsck -fn /dev/sda5依然报错。但是这些节点大多是在doc目录下,并不影响系统启动,于是强行修复并重启系统,进入系统后启动数据库和应用软件,没有
出现报错,一切正常。
10、由用户方工程师对恢复数据进行检测,经过用户方检测,确认恢复数据有效,认可数据恢复结果。本次数据恢复工作完成。

审核编辑 黄宇

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分