关于数据恢复:服务器数据恢复-Linux系统服务器RAID5数据恢复案例

服务器数据恢复环境:
某品牌服务器中有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失常存在,但属性,大小和最后的调配块都是谬误的。依照所有可能进行剖析,然而没有找到办法找回此损坏节点。只能试图修复此节点或复制一个雷同的文件过去。
11、针对所有可能存在谬误的文件,北亚企安数据恢复工程师通过日志确定原节点块的节点信息,而后做修改。
12、修改后从新dd根分区,执行fsck -fn /dev/sda5仍然报错。

依据报错信息,北亚企安数据恢复工程师在零碎中发现有多个节点共用同样的数据块。按此提醒剖析底层,发现存在节点信息的新旧交加。
13、依照节点所属的文件进行辨别,革除谬误节点后再次执行fsck -fn /dev/sda5,仍然有大量报错。依据报错信息,发现这些节点多位于doc目录下,不影响系统启动,于是间接执行fsck -fy /dev/sda5强行修复。
14、修复实现后重启零碎,胜利进入零碎桌面。
15、启动oracle数据库服务,启动OA,一切正常无报错。
16、由用户方对复原的操作系统和数据(OA和oracle数据库)进行检测,通过用户方多方检测,确认复原数据残缺无效。本次数据恢复工作实现。

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理