杭州服务器数据恢复之余杭临平Linux Ext3数据恢复成功手记
[ 2009-12-16 13:12:32 | 作者: Admin ]
Linux EXT3服务器数据恢复：接到杭州余杭临平某外资服装有限公司网管李先生电话，描述他们一台刚创建不久的网络文件服务器重新启动之后无法加载系统，从而无法加载centos5.1的创建的软RAID5的EXT3文件系统，数据无法正常读出。里面有最近用户更新的数据，如果没有的话，最近的走货单号无法查到，数据非常重要。杭州迪特斯数据恢复专家接到电话之后，明确表示数据完全可以恢复，但是不要通过EXT3日志方式修复数据，保证节点不被破坏。
文件服务器配置如下：Centos5.1系统下创建的RAID 5,其中三个硬盘中两个硬盘前面6G是做软RAID1镜像能够保证Centos5.1启动加载软RAID5，硬盘的其余剩余容量是做软RAID5。\dev节点分区是Semba配置区,分区大小为10G，文件系统为EXT3日志文件系统；\home节点分区是用户数据区，分区大小是167G 文件系统EXT3日志文件系统，数据主要在这个分区上。
故障现象：由于服务器重启之后导致centos5.1无法加载原来用在SEMBA服务下的用户数据，导致丢失，用户表示数据全部在\home的节点下面，有两部分数据一部分是共享数据，一部分是用户保密数据。据用户分析来看，应该是RAID5的超级块（SuperBlok）出错引起的，所以用户一段时间是在修复超级块，最后也是无功而返。我方（杭州迪特斯数据恢复专家）接到硬盘检测之后，通过对三个一硬盘的分区表检测，发现硬盘的分区表正常，第一、二硬盘的前面6G分区是EXT3的，第三个硬盘的前面6G分区是SWAP分区，对剩分区软RAID5分析发现，该物理卷是有逻辑管理卷管理(LVM)的，也就是用户看到的超级块（SuperBlock）是逻辑管理卷（LVM），所以有可能\HOME分区的EXT3的超级块没有损坏，需要后续检测。
恢复步骤：根据以往RAID5恢复的话，首先要分析该RAID5的条带大小和采用是什么数据条带旋转方式什么的，但是询问用户创建RAID5的条带大小，结果都是不知道，只能是对数据进行枯燥的分析（需要了解LINUX EXT3文件系统原理）才能找到特殊数据，经过的数据的分析发现该RAID5的条带大小是256K。该RAID5由于是格式和一般的硬RAID不一样，所以不同的方式分析，通过对RAID5数据整合，在对软RAID5进行数据分析，发现后续的EXT3超级块（SuperBlock）损坏，需要修复，但是庆幸的是下面的文件节点（inode）没有完全损坏，于是修复超级块，读取数据，但是数据的文件夹和文件名显示乱码，根据以往的经验得知，该LINUX采用的是UTF-8国际通用文字编码，不是一般的国标GB2312，需要重新编码。编码之后数据乱码全部变成中文了。但是恢复出来有些数据是损坏的，有些数据根本就没有恢复出来，令我感到很郁闷！但是大部分数据还是正常的。郁闷了一天，想想该3个硬盘是刚刚创建的硬盘，硬盘应该不会有问题吧。可是最后是实事难预料，就是该硬盘的其中有个硬盘数据没有更新引起的。
最后，客户软RAID5服务器全部数据恢复成功！！
数据恢复咨询热线：0571－56892709 15314676921
文件服务器配置如下：Centos5.1系统下创建的RAID 5,其中三个硬盘中两个硬盘前面6G是做软RAID1镜像能够保证Centos5.1启动加载软RAID5，硬盘的其余剩余容量是做软RAID5。\dev节点分区是Semba配置区,分区大小为10G，文件系统为EXT3日志文件系统；\home节点分区是用户数据区，分区大小是167G 文件系统EXT3日志文件系统，数据主要在这个分区上。
故障现象：由于服务器重启之后导致centos5.1无法加载原来用在SEMBA服务下的用户数据，导致丢失，用户表示数据全部在\home的节点下面，有两部分数据一部分是共享数据，一部分是用户保密数据。据用户分析来看，应该是RAID5的超级块（SuperBlok）出错引起的，所以用户一段时间是在修复超级块，最后也是无功而返。我方（杭州迪特斯数据恢复专家）接到硬盘检测之后，通过对三个一硬盘的分区表检测，发现硬盘的分区表正常，第一、二硬盘的前面6G分区是EXT3的，第三个硬盘的前面6G分区是SWAP分区，对剩分区软RAID5分析发现，该物理卷是有逻辑管理卷管理(LVM)的，也就是用户看到的超级块（SuperBlock）是逻辑管理卷（LVM），所以有可能\HOME分区的EXT3的超级块没有损坏，需要后续检测。
恢复步骤：根据以往RAID5恢复的话，首先要分析该RAID5的条带大小和采用是什么数据条带旋转方式什么的，但是询问用户创建RAID5的条带大小，结果都是不知道，只能是对数据进行枯燥的分析（需要了解LINUX EXT3文件系统原理）才能找到特殊数据，经过的数据的分析发现该RAID5的条带大小是256K。该RAID5由于是格式和一般的硬RAID不一样，所以不同的方式分析，通过对RAID5数据整合，在对软RAID5进行数据分析，发现后续的EXT3超级块（SuperBlock）损坏，需要修复，但是庆幸的是下面的文件节点（inode）没有完全损坏，于是修复超级块，读取数据，但是数据的文件夹和文件名显示乱码，根据以往的经验得知，该LINUX采用的是UTF-8国际通用文字编码，不是一般的国标GB2312，需要重新编码。编码之后数据乱码全部变成中文了。但是恢复出来有些数据是损坏的，有些数据根本就没有恢复出来，令我感到很郁闷！但是大部分数据还是正常的。郁闷了一天，想想该3个硬盘是刚刚创建的硬盘，硬盘应该不会有问题吧。可是最后是实事难预料，就是该硬盘的其中有个硬盘数据没有更新引起的。
最后，客户软RAID5服务器全部数据恢复成功！！
[最后修改由 Admin， 于 2010-03-10 11:29:13]
评论Feed: http://www.dstsos.com/feed.asp?q=comment&id=51
引用链接: 这篇日志没有评论。
