关于数据恢复:服务器数据恢复某品牌x3850服务器RAID5数据恢复案例

46次阅读

共计 1717 个字符,预计需要花费 5 分钟才能阅读完成。

服务器故障:
某公司的一台某品牌 x3850 服务器 raid5 中两块磁盘先后掉线,服务器解体。故障服务器的操作系统为 linux redhat,利用为公司 oa,数据库采纳 oracle。因 oracle 曾经不再对此 oa 提供后续反对,管理员分割咱们数据恢复核心要求尽可能复原数据和零碎。
数据恢复工程师对故障服务器进行检测,发现热备盘没有启用,硬盘无显著物理故障,无显著同步体现。

服务器数据恢复计划:
1、爱护原环境,敞开服务器,确保在复原过程中不再开启服务器。
2、将故障硬盘标好序号,确保在拿出槽位后能够齐全还原。
3、将故障硬盘挂载至只读环境,对所有故障硬盘做齐全镜像 (参考 < 如何对磁盘做残缺的全盘镜像备份 >)。备份实现后交回原故障盘,之后的复原操作直到数据确认无误前不再波及原故障盘。
4、对备份盘进行 RAID 构造剖析,失去其原来的 RAID 级别,条带规定,条带大小,校验方向,META 区域等。
5、依据失去的 RAID 信息搭建一组虚构的 RAID5 环境。
6、进行虚构磁盘及文件系统解释。
7、检测虚构构造是否正确,如不正确,反复 4 - 7 过程。
8、确定数据无误后,按用户要求回迁数据。如果依然应用原盘,需确定曾经齐全对原盘做过备份后,重建 RAID,再做回迁。回迁操作系统时,能够应用 linux livecd 或 win pe(通常不反对) 等进行,也能够在故障服务器上用另外硬盘装置一个回迁用的操作系统,再进行扇区级别的回迁。
9、数据移交后,由北亚数据恢复核心缩短保存数据 3 天,以防止可能疏忽的纰漏。

服务器数据恢复过程:
1、对故障服务器中的所有硬盘进行残缺镜像,镜像后数据恢复工程师发现 2 号盘有 10-20 个坏扇区,其余磁盘没有发现坏道。
2、剖析构造:获取到的最佳构造为 0,1,2,3 盘序,缺 3 号盘,块大小为 512 扇区,backward parity(Adaptec),构造如下图:

3、组好后进行数据验证,200M 以上的最新压缩包解压无报错,确定构造正确。
4、间接按此构造生成虚构 RAID 到一块单硬盘上,关上文件系统无显著报错。
5、确定备份包平安的状况下,经管理员批准后,北亚数据恢复工程师对原盘重建 RAID,重建时曾经用全新硬盘更换损坏的 2 号盘。将复原好的单盘用 USB 形式接入故障服务器,再用 linux SystemRescueCd 启动故障服务器,之后通过命令进行全盘回写。
6、回写后,启动操作系统。失常状况下,这时候所有工作应该实现了,不巧的是,问题还没有解决。

上面是后续的数据恢复过程:
1、接前文:回写完所有数据后,启动操作系统报错,报错信息为:/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied。
2、依据错误信息得悉此文件权限有问题,用 SystemRescueCd 重启后查看,发现此文件工夫,权限,大小均有显著谬误,显然节点损坏。
3、从新剖析重组数据中的根分区,定位出错的 /sbin/pidof,发现问题产生起因是 2 号盘的坏道。
4、应用 0,1,3 这 3 块盘,针对 2 号盘的损坏区域进行 xor 补齐。补齐后从新校验文件零碎,仍然有谬误,再次查看 inode 表,发现 2 号盘损坏区域有局部节点体现为下图中的 55 55 55 局部:

5、尽管节点中形容的 uid 还失常存在,但属性,大小,最后的调配块全副是谬误的。依照所有可能进行剖析,数据恢复工程师确定无奈找回此损坏节点,只能心愿修复此节点,或复制一个雷同的文件过去。
6、对所有可能有错的文件通过日志确定原节点块的节点信息,再做修改。
7、修改后从新 dd 根分区,执行 fsck -fn /dev/sda5,进行检测,仍然有报错,如下图:

8、依据提醒,在零碎中发现有多个节点共用同样的数据块。按此提醒进行底层剖析,发现因 3 号盘早掉线,存在节点信息的新旧交加。
9、按节点所属的文件进行区别,革除谬误节点后,再次执行 fsck -fn /dev/sda5,仍然有极少量的报错信息。依据提醒,发现这些节点多位于 doc 目录下,不影响系统启动,于是间接 fsck -fy /dev/sda5 强行修复。
10、修复后,重启零碎胜利进入桌面。
11、启动数据库服务,启动应用软件,一切正常,无报错。数据恢复及零碎回迁工作实现。

正文完
 0