Linux服务器数据恢复分析与过程案例

　　是软件就一定有BUG，LINUX也一样，不管有多少人维护它，不管它有多么透明，至少很多情况是程序员无法设想的，测试无法模拟的。

　　下面是北亚数据恢复中心(官方网站:)最近接手的两起典型LINUX文件系统BUG引发的数据灾难案例，这两起均不是人为原因，应该是来自EXT系列文件系统的BUG。

　　案例1：

　　单位：北京某IT企业

　　数据恢复故障描述：Linux 服务器在高负荷时突然死机，重启后无法进入系统。

　　数据恢复故障分析：此LINUX服务器底层是由两块73GB SCSI磁盘组成，做成RAID0，OS为 RHEL 5.3，分为两个卷，一个/boot，一个 LVM，LVM中又划分了两个区，一个根分区一个交换分区，重要数据是MYSQL数据库，均存储在根分区中。

　　从底层分析出原始RAID0结构后，使用虚拟RAID重组方法，得到了完整的数据，但 “/” 分区无法打开，底层上一层层分析发现分区表和LVM均无任何问题，而“/” 分区前部出现严重的损坏，“/”分区文件系统为 EXT3。分析发现文件系统部分字节全被0填充，需要修复文件系统才能恢复。

　　数据恢复过程：此种情况出现较多，北亚数据恢复中心已接手过多起，问题的现象和原因都大同小异，也不是人为原因造成，估计是EXT3文件系统的BUG，后EXT3的升级版EXT4也有类似的BUG，问题的现象和原因也大同小异。

　　由于北亚数据恢复中心已处理过多起此类数据灾难，凭着对LINUX文件系统的完全了解和多年积累的诸多经验，轻易就修复好损坏的EXT3文件系统，导出MYSQL数据库，验证数据库，一却正常。

　　数据恢复结论：用时4小时，数据完美恢复成功。

　　负责工程师：北亚数据恢复中心-尹修建

　　联系方式:010-82488636-804

　　邮箱：yxj@datahf.net

　　案例2：

　　单位：北京某高校

　　数据恢复故障描述：Linux 服务器在高负荷时突然死机，重启后无法进入系统，运维人员检查底层RAID，无问题，问题来自文件系统。

　　数据恢复故障分析和恢复过程：此LINUX服务器底层是由4块500GB SAS磁盘组成，做成RAID5，OS为 CentOS 6.0，分为两个卷，一个/boot，一个 LVM，LVM中又划分了两个区，一个根分区一个交换分区，重要数据是MYSQL数据库和网站文件备份的tar.gz文件，均存储于根分区中，文件系统均为EXT4。

　　由于底层RAID没任何问题，客户将此HP服务器搬到北京北亚数据恢复中心后，北亚数据恢复中心工程师将此服务器数据完整 dd 到北亚数据恢复中心内部的安全存储中，然后分析故障原因和制定数据恢复方案。

　　分析发现EXT4文件系统超级块、块组描述符、块位图和大部分I节点都正常，但部分负荷重的MYSQL表的文件的I节点所在的块全被FF填充，EXT4一个I节点占256 byte，此EXT4文件系统块长度为4KB，一个块可存储16个I节点，一个文件或一个目录都会使用一个I节点，所以一个文件I节点出现问题，会额外影响其它的15个文件。至于I节点块被FF填充的故障，北亚数据恢复也处理过多起，估计是EXT3/4 系列文件系统的BUG。

　　此种情况出现较多，北亚数据恢复中心已接手过多起，问题的现象和原因都大同小异，也不是人为原因造成。北亚数据恢复中心凭着对LINUX文件系统的完全了解和多年积累的诸多经验，轻易就修复好损坏的EXT4文件系统，导出MYSQL数据库和需要的tar.gz 文件，验证数据库和tar.gz文件，一却正常。

　　数据恢复结论：用时1天，数据完美恢复成功。

　　负责工程师：北亚数据恢复中心-尹修建

　　联系方式:010-82488636-804

　　邮箱：yxj@datahf.net