服务器数据恢复硬件状态:
客户的服务器型号是华为 5800, 该服务器中共有 10 块硬盘组成 raid6 磁盘阵列用于企业内部使用, 服务器采用 EXT3 文件系统; 划分为 2 个 lun; 每个 lun8TB 大小.
服务器数据恢复故障分析:
服务器在使用过程中管理员发现 raid 失效, 于是对失效的服务器进行了重新分配 raid 的操作, 同时初始化 raid, 初始化进行到 40% 左右时强行停止初始化, 但部分数据已经造成不可逆的破坏. 数据恢复难度增大.
服务器数据恢复成功率预估:
导致服务器数据丢失的原因是 raid 失效, 管理员随后对 raid6 阵列中的 9 块硬盘重新分配为 riad5 阵列并进行了长时间初始化操作, 这对原始数据是不可逆的损坏. 在后来对服务器数据恢复操作中也证明了仅第二个 LUN 可用普通 RAID6 数据恢复方法恢复出数据, 但客户所需要的重要数据集中在第一个 lun 中. 数据恢复可能性极低, 在接到客户服务器之前已经有多家数据恢复公司介入, 均未能成功恢复出有效数据.
服务器数据恢复过程:
1.快速分析服务器中原始磁盘 RAID6 的 RAID 和磁盘的组织结构. 再分析服务器重新分配 RAID5 时的 RAID 和磁盘的组织结构. 在进行实际操作时由于重新分配导致的底层 RAID6 和 RAID5 的信息大量重合, 对这些数据进行分析, 区别非常困难, 服务数据恢复工程师花费了一天时间进行分析.
3.判断可恢复性, 设计实现恢复程序的算法并测试. 工程师分析出了服务器中原始 raid6 阵列和重新分配后的 raid5 阵列信息后进行数据恢复算法的研究发现可以通过其他方式将服务器原有数据进行恢复. 于是投入编写程序和校正算法工作, 将服务器中原 raid6 阵列中的. 第一和第二个 LUN 分别镜像到搭好的两个 7TB 的存储上.
4. 恢复服务器数据.
服务器数据恢复工程师验证第二个 LUN 数据完全正常, 但最重要的第一个 LUN 前有大约有 10MB 数据的破坏, 这前 10MB 数据极其重要, EXT3 的根目录和第一个块组的 I 节点全在这前 10MB 里面, 工程师尝试借助几款数据恢复常用的软件进行扫描恢复但恢复效果都相当不理想, 想必之前几家数据恢复公司没有成功的原因就在于此.
在这种情况下只得对损坏的 EXT3 文件系统进行修复. 首先编一个小程序对 EXT3 文件系统进行孤目录查找, 在本目录下发现子目录 3 个. 重建根目录和 I 节点, 用 文件系统解析程序打开已完全正常, 但为了保证原始数据的一些权限和属性, 在 LINUX 简单修复, LINUX 已能正常挂载, 然后在 LINUX 把文件用 cp 命令进行拷贝格式化好的 EXT3 的单块磁盘的分区上. 这样客户使用数据时, 不再需要别的任何设置, 直接 cp 后, 文件目录结构和属性都和原来一模一样. 本次数据恢复成功, 可用数据为 100%.
来源: http://blog.51cto.com/sun510/2133289