关于数据恢复:服务器数据恢复IBM服务器raid5两块硬盘离线数据恢复案例

28次阅读

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

服务器数据恢复环境:
ibm x3850 系列服务器;
5 块硬盘组成 raid5 磁盘阵列;
linux redhat 5.x 操作系统;
oracle 数据库。

服务器故障:
服务器上两块硬盘因为未知故障离线,服务器数据失落,管理员分割咱们数据恢复核心要求复原故障服务器的数据。通过服务器数据恢复工程师对故障服务器进行初检,发现服务器阵列中有两块硬盘处于离线状态,热备盘未激活。硬盘无物理故障,无显著同步体现。

服务器数据恢复过程:
1、将故障服务器关机,标记好故障盘后取出槽位挂载至筹备好的数据恢复服务器环境进行镜像备份。对原硬盘镜像后发现除了 2 号盘有 10-20 个坏扇区外其余硬盘均失常。实现镜像后将硬盘重新安装到原服务器。
2、服务器数据恢复工程师剖析备份盘中的 raid 构造,获取阵列中的 raid 条带大小、校验方向、条带规定以及 meta 区域等信息。通过剖析发现最佳盘序构造是 0 -1-2-3,缺失 3 号盘,构造如下图:

依据剖析进去的 raid 信息虚构搭建一组 raid5 环境,组好后进行数据验证,200M 以上的最新压缩包解压无报错,依照这一构造将虚构 raid 生成到一块硬盘上,通过 USB 的形式把复原后的单盘接入原服务器,通过软件启动故障服务器后进行全盘回写。

3、数据回写实现后无奈进入操作系统,报错信息为:/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied。数据恢复工程师重启服务器后发现文件的权限、工夫、大小都有显著谬误,对根分区再次剖析定位出错的 /sbin/pidof/,发现问题的起因是 2 号盘坏道。
4、利用其余盘对 2 号盘的损坏区域进行 xor 补齐并从新校验文件零碎,仍然报错,数据恢复工程师再次对 inode 表进行查看,发现 2 号盘损坏区域有局部节点体现为 (图中的 55 55 55 局部):

5、尽管节点中形容的 uid 还失常存在,但大小、属性、最后的调配块全副是谬误的。通过日志确定原节点块的节点信息后进行修改,从新 dd 根分区,执行 fsck -fn /dev/sda5 检测,报错状况如下图:

6、通过剖析发现,原来 3 号盘最先离线,节点信息新旧交加导致有多个节点共用数据块。数据恢复工程师按节点所属的文件进行区别,革除谬误节点后再次执行 fsck -fn /dev/sda5,仍然有局部位于 doc 目录下的节点报错。因为不影响启动所以强行修复后重启零碎,零碎失常,启动数据库失常。

7、由服务器管理员亲自对服务器数据进行验证,验证后果示意数据失常,数据恢复胜利。

正文完
 0