某公司数据恢复报告书

1、某公司数据恢复报告书一、故障描述1、设备清单设备名称设备型号数量HP FC存储HP MSA20001450G SAS硬盘82、故障描述整个存储空间由 8 块 450GBSAS的硬盘组成，其中 7 块硬盘组成一个 RAID5 的阵列，剩余 1 块做成热备盘使用。由于 RAID5阵列中出现 2 块硬盘损坏，而此时只有一块热备盘成功激活，因此导致 RAID5阵列瘫痪，上层 LUN无常使用。二、检测磁盘由于存储是因为 RAID阵列中某些磁盘掉线，从而导致整个存储不可用。因此接收到磁盘后先对所有磁盘做物理检测，检测完后发现没有物理故障。接着使用坏道检测工具检测磁盘坏道，发现也没有坏道。磁盘坏道检测日志如

2、下图：三、备份数据考虑到数据的安全性以及可还原性，在做数据恢复之前需要对所有源数据做备份，以防其他原因导致数据无法再次恢复。使用 dd 命令或 winhex 工具将所有磁盘都镜像成文件。备份完部分数据如下图：四、故障分析1、分析故障原因由于前两个步骤并没有检测到磁盘有物理故障或者是坏道，由此推断可能是由于某些磁盘读写不稳定导致故障发生。因为HP MSA2000控制器检查磁盘的策略很严格，一旦某些磁盘性能不稳定，HPMSA2000控制器就认为是坏盘，就将认为是坏盘的磁盘踢出 RAID组。而一旦 RAID组中掉线的盘到达到 RAID级别允许掉盘的极限，那么这个 RAID组将变的不可用，上层基于 R

3、AID组的 LUN也将变的不可用。目前初步了解的情况为RAID组的 LUN有 6 个，均分配给 HP-Unix 小机使用，上层做的 LVM逻辑卷，重要数据为 Oracle 数据库及 OA服务端。2、分析 RAID组结构HP MSA2000存储的 LUN都是基于 RAID组的，因此需要先分析底层RAID组的信息，然后根据分析的信息重构原始的RAID组。分析每一块数据盘，发现 4 号盘的数据同其它数据盘不太一样，初步认为可能是hot Spare盘。接着分析其他数据盘，分析Oracle 数据库页在每个磁盘中分布的情况，并根据数据分布的情况得出RAID组的条带大小，磁盘顺序及数据走向等RAID组的重要

4、信息。3、分析 RAID组掉线盘根据上述分析的 RAID信息，尝试通过北亚自主开发的 RAID虚拟程序将原始的 RAID组虚拟出来。但由于整个 RAID组中一共掉线两块盘，因此需要分析这两块硬盘掉线的顺序。仔细分析每一块硬盘中的数据，发现有一块硬盘在同一个条带上的数据和其他硬盘明显不一样， 因此初步判断此硬盘可能是最先掉线的，通过北亚自主开发的 RAID校验程序对这个条带做校验，发现除掉刚才分析的那块硬盘得出的数据是最好的， 因此可以明确最先掉线的硬盘了。4、分析 RAID组中的 LUN信息由于 LUN是基于 RAID组的，因此需要根据上述分析的信息将 RAID组最新的状态虚拟出来。然后分析

5、LUN在 RAID组中的分配情况，以及 LUN分配的数据块 MAP。底层有 6 个 LUN，因此只需要将每一个 LUN的数据块分布 MAP 提取出来。然后针对这些信息编写相应的程序，对所有 LUN的数据 MAP做解析，然后根据数据 MAP并导出所有 LUN的数据。五、 LVM逻辑卷及VXFS文件系统修复1、解析 LVM逻辑卷分析生成出来的所有 LUN，发现所有 LUN中均包含 HP-Unix 的 LVM逻辑卷信息。尝试解析每个 LUN中的 LVM信息，发现其中一共有三套 LVM，其中45G的 LVM中划分了一个 LV，里面存放 OA服务器端的数据， 190G的 LVM中划分了一个 LV，里面存

6、放临时备份数据。剩余 4 个 LUN组成一个 2.1T 左右的 LVM，也只划分了一个 LV，里面存放 Oracle 数据库文件。编写解释 LVM 的程序，尝试将每套 LVM中的 LV 卷都解释出来，但发现解释程序出错。2、修复 LVM逻辑卷仔细分析程序报错的原因，安排开发工程师 debug 程序出错的位置，并同时安排高级文件系统工程师对恢复的 LUN做检测，检测 LVM信息是否会因存储瘫痪导致 LVM逻辑卷的信息损坏。经过仔细检测，发现确实因为存储瘫痪导致LVM信息损坏。尝试人工对损坏的区域进行修复，并同步修改程序，重新解析 LVM 逻辑卷。3、解析 VXFS文件系统搭建 HP-Unix 环

7、境，将解释出来的 LV 卷映射到 HP-Unix，并尝试 Mount 文件系统。结果 Mount 文件系统出错，尝试使用“ fsck F vxfs ” 命令修复 vxfs 文件系统，但修复结果还是不能挂载，怀疑底层 vxfs 文件系统的部分源数据可能被破坏，需要进行手工修复。4、修复 VXFS文件系统仔细分析解析出来的 LV，并根据 VXFS文件系统的底层结构校验此文件系统是否完整。分析发现底层 VXFS文件系统果然有问题，原来当时存储瘫痪的同时此文件在系统正在执行 IO 操作，因此导致部分文件系统源文件没有更新以及损坏。人工对这些损坏的源文件进行手工修复， 保证 VXFS文件系统能够正常解析

8、。再次将修复好的 LV 卷挂载到 HP-Unix 小机上，尝试 Mount 文件系统，文件系统没有报错，成功挂载。六、检测Oracle 数据库文件并启动数据库1、恢复所有用户文件在 HP-Unix 机器上 mount 文件系统后，将所有用户数据均备份至指定磁盘空间。所有用户数据大小在 1.2TB 左右。部分文件目录截图如下：2、检测数据库文件是否完整使用 Oracle 数据库文件检测工具“ dbv”检测每个数据库文件是否完整， 发现并没有错误。再使用北亚自主研发的 Oracle 数据库检测工具 （检验更严格） ，发现有部分数据库文件和日志文件校验不一致， 安排高级数据库工程师对此类文件进行修复

9、， 并再次校验， 直到所有文件校验均完全通过。3、启动 Oracle 数据库由于我们提供的HP-Unix 环境没有此版本的Oracle 数据，因此和用户协调将原始生成环境带至北亚数据恢复中心，然后将恢复的 Oracle 数据库附加到原始生产环境的 HP-Unix 服务器中，尝试启动 Oracle 数据库， Oracle 数据库启动成功。部分截图如下：七、数据验证由用户方配合， 启动 Oracle 数据库，启动 OA服务端，在本地笔记本安装 OA 客户端。通过 OA客户端对最新的数据记录以及历史数据记录进行验证，并且有用户安排远程不同部门人员进行远程验证。 最终数据验证无误， 数据完整，数据恢复

10、成功。八、移交数据用户方重新购买了 8 块 HP-MSA2000原厂硬盘，由北亚工程师配合重新对HP-MSA2000存储进行配置。创建和原始一样的 Volume，并将恢复的数据全部复制到重新配置好的存储中， 并验证所有服务能够正常启动， 包括 Oracle 数据库服务， OA服务端等。九、数据恢复结论由于故障发生后保存现场环境良好，没做相关危险的操作，对后期的数据恢复有很大的帮助。整个数据恢复过程中虽然遇到好多技术瓶颈，但也都一一解决。最终在预期的时间完成整个数据恢复，恢复的数据用户方也相当满意。十、项目成员列表工程师商务晓娜185，1528，3863zxn#frombyte.项目主管邓奇185，1528，3878dq#frombyte.存储工程师邓奇185，1528，3878dq#frombyte.RAID工程宋国建185，1528，3861songguojia