一, 服务器数据恢复案例背景:
HP FC MSA2000 服务器空间由 8 块 450GB SAS 硬盘组成 raid5 磁盘阵列, 一块热备盘. 服务器在使用中先后有两块硬盘离线, 导致服务器瘫痪, lun 无法正常使用.
服务器数据恢复工程师分别对服务器中所有磁盘进行物理检测和坏道检测, 均无异常.
二, 服务器数据恢复备份
考虑到数据的安全性以及可还原性, 在做数据恢复之前需要对所有源数据做备份, 以防万一其他原因导致数据无法再次恢复. 使用 dd 命令或 winhex 工具将所有磁盘都镜像成文件.
备份完部分数据如下图:
三, 服务器数据恢复故障原因分析:
目前初步了解的情况为基于 RAID 组的 LUN 有 6 个, 均分配给 HP-Unix 小机使用, 上层做的 LVM 逻辑卷, 重要数据为 Oracle 数据库及 OA 服务端. 由于 HP MSA2000 服务器中一旦某些磁盘性能不稳定, HP MSA2000 控制器将其认为是坏盘的磁盘踢出 RAID 组. 而一旦 RAID 组中掉线的盘到达到 RAID 级别允许掉盘的极限, 那么这个 RAID 组将变的不可用, 导致服务器瘫痪.
四, 分析服务器 RAID 组结构:
服务器的 LUN 都是基于 RAID 组的, 要想恢复服务器数据就需要先分析底层 RAID 组的信息, 然后根据分析的信息重构原始的 RAID 组. 分析每一块数据盘, 发现 4 号盘的数据同其它数据盘不太一样, 初步认为可能是 hot Spare 盘. 接着分析其他数据盘, 分析 Oracle 数据库页在每个磁盘中分布的情况, 并根据数据分布的情况得出 RAID 组的条带大小, 磁盘顺序及数据走向等 RAID 组的重要信息.
五, 分析服务器 RAID 组掉线盘
根据上述分析的 RAID 信息, 尝试通过北亚自主开发的 RAID 虚拟程序将原始的 RAID 组虚拟出来. 但由于整个 RAID 组中一共掉线两块盘, 因此需要分析这两块硬盘掉线的顺序. 仔细分析每一块硬盘中的数据, 发现有一块硬盘在同一个条带上的数据和其他硬盘明显不一样, 因此初步判断此硬盘可能是最先掉线的, 通过北亚自主开发的 RAID 校验程序对这个条带做校验, 发现除掉刚才分析的那块硬盘得出的数据是最好的, 因此可以明确最先掉线的硬盘了.
六, 分析 RAID 组中的 LUN 信息
由于 LUN 是基于 RAID 组的, 因此需要根据上述分析的信息将 RAID 组最新的状态虚拟出来. 然后分析 LUN 在 RAID 组中的分配情况, 以及 LUN 分配的数据块 MAP. 由于底层有 6 个 LUN, 因此只需要将每一个 LUN 的数据块分布 MAP 提取出来. 然后针对这些信息编写相应的程序, 对所有 LUN 的数据 MAP 做解析, 然后根据数据 MAP 并导出所有 LUN 的数据.
导出的数据如下图:
七, 服务器 LVM 逻辑卷及 VXFS 文件系统修复
分析生成出来的所有 LUN, 发现所有 LUN 中均包含 HP-Unix 的 LVM 逻辑卷信息. 尝试解析每个 LUN 中的 LVM 信息, 发现其中一共有三套 LVM, 其中 45G 的 LVM 中划分了一个 LV, 里面存放 OA 服务器端的数据, 190G 的 LVM 中划分了一个 LV, 里面存放临时备份数据. 剩余 4 个 LUN 组成一个 2.1T 左右的 LVM, 也只划分了一个 LV, 里面存放 Oracle 数据库文件. 编写解释 LVM 的程序, 尝试将每套 LVM 中的 LV 卷都解释出来, 但发现解释程序出错.
仔细分析程序报错的原因, 安排开发工程师 debug 程序出错的位置, 并同时安排高级文件系统工程师对恢复的 LUN 做检测, 检测 LVM 信息是否会因存储瘫痪导致 LMV 逻辑卷的信息损坏. 经过仔细检测, 发现确实因为存储瘫痪导致 LVM 信息损坏. 尝试人工对损坏的区域进行修复, 并同步修改程序, 重新解析 LVM 逻辑卷.
搭建 HP-Unix 环境, 将解释出来的 LV 卷映射到 HP-Unix, 并尝试 Mount 文件系统. 结果 Mount 文件系统出错, 尝试使用 "fsck -F vxfs" 命令修复 vxfs 文件系统, 但修复结果还是不能挂载, 怀疑底层 vxfs 文件系统的部分元数据可能破坏, 需要进行手工修复.
仔细分析解析出来的 LV, 并根据 VXFS 文件系统的底层结构校验此文件系统是否完整. 分析发现底层 VXFS 文件系统果然有问题, 原来当时存储瘫痪的同时此文件在系统正在执行 IO 操作, 因此导致部分文件系统元文件没有更新以及损坏. 人工对这些损坏的元文件进行手工修复, 保证 VXFS 文件系统能够正常解析. 再次将修复好的 LV 卷挂载到 HP-Unix 小机上, 尝试 Mount 文件系统, 文件系统没有报错, 成功挂载.
八, 检测 Oracle 数据库文件并启动数据库
在 HP-Unix 机器上 mount 文件系统后, 将所有用户数据均备份至指定磁盘空间. 所有用户数据大小在 1.2TB 左右.
部分文件目录截图如下:
使用 Oracle 数据库文件检测工具 "dbv" 检测每个数据库文件是否完整, 发现并没有错误. 再使用北亚自主研发的 Oracle 数据库检测工具 (检验更严格), 发现有部分数据库文件和日志文件校验不一致, 安排高级数据库工程师对此类文件进行修复, 并在次校验, 直到所有文件校验均完全通过.
由于我们提供的 HP-Unix 环境没有此版本的 Oracle 数据, 因此和用户协调将原始生成环境带至北亚数据恢复中心, 然后将恢复的 Oracle 数据库附加到原始生产环境的 HP-Unix 服务器中, 尝试启动 Oracle 数据库, Oracle 数据库启动成功.
部分截图如下:
九, 服务器数据恢复成功:
启动 Oracle 数据库, 启动 OA 服务端, 在本地笔记本安装 OA 客户端. 通过 OA 客户端对最新的数据记录以及历史数据记录进行验证, 并且有用户安排远程不同部门人员进行远程验证. 最终数据验证无误, 数据完整, 数据恢复成功.
来源: http://blog.51cto.com/sun510/2147735