服务器崩溃数据恢复方案及过程.pdf

IBMIBM 服务器服务器 raid5raid5 崩溃数据恢复方案及过程崩溃数据恢复方案及过程 概述： IBM X3850 服务器，5 块 73G SAS 硬盘，其中 4 块组成一个 RAID5，另一块做为热备盘(Hot-Spare)，3 号盘早已经离线，但热备盘未自动激活 rebuild（原因不明），之后 2号盘离线，RAID 崩溃 操作系统为 linux redhat 5.3,应用系统为构架于 oracle 的一个 oa，数据重要，时间很急因 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 启动故障服务器，之后通过 dd 命令进行全盘回写 6、回写后，启动操作系统正常情况下，这时候所有工作应该完成了不巧的是，因帮颇费周折才解决，特意另起一段叙述 系统复原过程：系统复原过程： dd 所有数据后， 启动操作系统， 无法进入， 报错信息为： /etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied 怀疑此文件权限有问题，用 SystemRescueCd 重启后检查，此文件时间，权限，大小均有明显错误，显然节点损坏 重新分析重组数据中的根分区，定位出错的/sbin/pidof/，发现问题因2 号盘坏道引起 使用 0，1，3 这 3 块盘，针对 2 号盘的损坏区域进行 xor 补齐补齐后重新校验文件系统，依然有错误，再次检查 inode 表，发现 2 号盘损坏区域有部分节点表现为(图中的55 55 55 部分)： 很明显，虽然节点中描述的 uid 还正常存在，但属性，大小，以最初的分配块全部是错误的 按照所有可能进行分析， 确定无任何办法找回此损坏节点。

只能希望修复此节点，或复制一个相同的文件过来 对所有可能有错的文件，均通过日志确定原节点块的节点信息，再做修正 修正后重新 dd 根分区，执行 fsck -fn /dev/sda5/，进行检测，依然有报错，如下图： 根据提示，在系统中发现有多个节点共用同样的数据块按此提示进行底层分析，发现，因 3 号盘早掉线，帮存在节点信息的新旧交集 按节点所属的文件进行区别，清除错误节点后，再次执行 fsck -fn /dev/sda5,依然有报错信息， 但已经很少 根据提示， 发现这些节点多位于 doc 目录下， 不影响系统启动，于是直接 fsck -fy /dev/sda5/ 强行修复 修复后，重启系统，成功进入桌面 启动数据库服务，启动应用软件，一切正常，无报错 到此，数据恢复及系统回迁工作完成。