标签:一模一样 部分 通过 研究 校正 没有 子目录 型号 MF
服务器数据恢复硬件状态:客户的服务器型号是华为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%。
?
标签:一模一样 部分 通过 研究 校正 没有 子目录 型号 MF
原文地址:http://blog.51cto.com/sun510/2133289