作者：张宇，北亚服务器数据恢复中心，转载请联系作者，如果实在不想联系作者，至少请保留版权，谢谢。
[数据恢复故障描述]
一台HP DL380 G4服务器，使用hp smart array控制器挂载了一台国产磁盘阵列，磁盘阵列由14块146G SCSI硬盘组成一组RAID5。
操作系统为LINUX，构建了NFS+FTP，作为公司内部文件服务器使用。
因机房搬迁时，管理员顺便打扫了一下机器，到新机房后接好线后，无法识别RAID，未做初始化。
[数据恢复分析]
HP smart array系列控制器源自康柏，RAID中的冗余采用双循环的校验方式。
此例中实际上是RAID信息丢失导致。
[数据恢复过程]
1、将SCSI硬盘柜直接接到不含RAID功能的SCSI扩展卡上。
2、在专用(windows2003改装后)修复平台上以单盘方式连接所有硬盘。
3、对所有硬盘以只读方式做完整镜像，同时镜像亦存储于带冗余保护的设备上。
4、从镜像中分析原RAID的双循环校验参数。
5、在虚拟RAID平台去掉早离线的盘，解释文件系统，已经可以导出数据了。
6、在客户原HP 服务器上连接盘阵，重新配置RAID。
7、通过网络dd、NFS、SAMBA、FTP、SSH等方式将数据传回新建好的磁盘阵列。
[数据恢复结果]
全部工作历时2 天，100%数据恢复成功。
2009年5月12日星期二
2009年5月9日星期六
分析案例：哪些操作导致IBM X225上无法成功恢复数据
作者：张宇，北亚服务器数据恢复中心，转载请联系作者，如果实在不想联系作者，至少请保留版权，谢谢。
[数据恢复故障描述]
新疆某政府机构，MS SQL SERVER服务器，硬件环境为：IBM X225，由4块73G SCSI硬盘组成RAID5，RAID中只划分了一个逻辑卷。操作系统为WINDOWS 2003。
A、之前未发现故障，直至服务器瘫痪，再查服务器时，发现有3块硬盘离线。
B、随便强制上线2块硬盘后，无法启动操作系统。
C、使用WINPE光盘启动操作系统后，可以看到数据，将备份好的ZIP数据库文件拷贝到移动硬盘上。
D、ZIP文件在另外的机器上测试，无法正确解压。
E、请对应维保公司帮助恢复。
F、其维保公司更换了一块新的RAID卡，直接重建成了一组RAID5。
G、客户认为ZIP文件大小、名称都正确，应该可以修好，所以直接先在RAID上重装了系统并正常工作，同时试图修复ZIP文件，尝试了1天后，没有结果。这时，向数据恢复公司寻求帮助。
[数据恢复结论]
与以往我叙述的数据恢复安全不同，我直接说数据恢复的最后结论：
因数据破坏严重，数据最终无法按客户要求恢复。
[案例分析]
针对上面的故障描述作如下分析：
故障描述A中，在使用RAID5做存储时，一定要及时维护RAID的正常状态，当RAID5一块硬盘掉线后，要及时备份数据到另外的存储体上，再及时REBUILD故障RAID。
故障描述B中，RAID5存在2块以上硬盘离线时，一定要可以随意选择硬盘上线，如果选择错了，有些情况下，一启动系统，整个RAID的状态就会改变，有可能会破坏重要数据。参考《RAID损坏后，我们该如何紧急应对？》
故障描述C中，用PE可以看到目录是因为目录区正常或部分正常，并不见得数据区正常，其实系统无法启动就意味着强制上线的操作是错误的，不应该继续下去。在PE里读到目录，实际上已经对文件系统进行了载入，已经破坏了正常文件系统的元数据区(只是有可能破坏的不影响要恢复的数据)
故障描述D中，ZIP文件无法解压即意味着RAID结构是错误的，实际上强制上线了2块盘(这时候有3块盘在线，仅有一块盘离线)，但这3块盘里有一块是早就离线了的，所以合起来的数据是新鲜与陈旧的混合在一起的，虽然目录是正确的，但数据区是混乱的。这时候并未对这3块硬盘有全面的数据同步，基本还是可以完整恢复的。
故障描述E中，如果和维保公司签订协议中确定有数据恢复的项目，可以让其代为处理(但最好还是咨询几家专业的数据恢复公司，确定一下处理方式)。如果维保公司并无数据恢复的服务范围，最好直接选择数据恢复公司。大多数情况下，如果客户直接找维保公司，维保公司再找数据恢复公司，可能会导致费用增加(有时候大得可怕)，同时对数据安全、数据恢复流程的规范方面无法直接控制。
故障描述F中，重建RAID5是此例中最致命的操作。IBM X225使用SERVER RAID SUPPORT CD重建RAID时，默认会清0所有数据。即使是其它服务器，重建RAID时一般也会重新同步校验，也会打乱原来的数据结构。但这个过程全部完成需要一段时间，如果没完成，可能剩余部分数据还有机会恢复。
故障描述G中，经过了一天，73G的RAID成员盘都已经同步完成了。数据完全毁掉了。
[数据恢复故障描述]
新疆某政府机构，MS SQL SERVER服务器，硬件环境为：IBM X225，由4块73G SCSI硬盘组成RAID5，RAID中只划分了一个逻辑卷。操作系统为WINDOWS 2003。
A、之前未发现故障，直至服务器瘫痪，再查服务器时，发现有3块硬盘离线。
B、随便强制上线2块硬盘后，无法启动操作系统。
C、使用WINPE光盘启动操作系统后，可以看到数据，将备份好的ZIP数据库文件拷贝到移动硬盘上。
D、ZIP文件在另外的机器上测试，无法正确解压。
E、请对应维保公司帮助恢复。
F、其维保公司更换了一块新的RAID卡，直接重建成了一组RAID5。
G、客户认为ZIP文件大小、名称都正确，应该可以修好，所以直接先在RAID上重装了系统并正常工作，同时试图修复ZIP文件，尝试了1天后，没有结果。这时，向数据恢复公司寻求帮助。
[数据恢复结论]
与以往我叙述的数据恢复安全不同，我直接说数据恢复的最后结论：
因数据破坏严重，数据最终无法按客户要求恢复。
[案例分析]
针对上面的故障描述作如下分析：
故障描述A中，在使用RAID5做存储时，一定要及时维护RAID的正常状态，当RAID5一块硬盘掉线后，要及时备份数据到另外的存储体上，再及时REBUILD故障RAID。
故障描述B中，RAID5存在2块以上硬盘离线时，一定要可以随意选择硬盘上线，如果选择错了，有些情况下，一启动系统，整个RAID的状态就会改变，有可能会破坏重要数据。参考《RAID损坏后，我们该如何紧急应对？》
故障描述C中，用PE可以看到目录是因为目录区正常或部分正常，并不见得数据区正常，其实系统无法启动就意味着强制上线的操作是错误的，不应该继续下去。在PE里读到目录，实际上已经对文件系统进行了载入，已经破坏了正常文件系统的元数据区(只是有可能破坏的不影响要恢复的数据)
故障描述D中，ZIP文件无法解压即意味着RAID结构是错误的，实际上强制上线了2块盘(这时候有3块盘在线，仅有一块盘离线)，但这3块盘里有一块是早就离线了的，所以合起来的数据是新鲜与陈旧的混合在一起的，虽然目录是正确的，但数据区是混乱的。这时候并未对这3块硬盘有全面的数据同步，基本还是可以完整恢复的。
故障描述E中，如果和维保公司签订协议中确定有数据恢复的项目，可以让其代为处理(但最好还是咨询几家专业的数据恢复公司，确定一下处理方式)。如果维保公司并无数据恢复的服务范围，最好直接选择数据恢复公司。大多数情况下，如果客户直接找维保公司，维保公司再找数据恢复公司，可能会导致费用增加(有时候大得可怕)，同时对数据安全、数据恢复流程的规范方面无法直接控制。
故障描述F中，重建RAID5是此例中最致命的操作。IBM X225使用SERVER RAID SUPPORT CD重建RAID时，默认会清0所有数据。即使是其它服务器，重建RAID时一般也会重新同步校验，也会打乱原来的数据结构。但这个过程全部完成需要一段时间，如果没完成，可能剩余部分数据还有机会恢复。
故障描述G中，经过了一天，73G的RAID成员盘都已经同步完成了。数据完全毁掉了。
2009年5月7日星期四
solaris ufs文件系统故障后恢复oracle数据库过程记录
作者：张宇，北亚服务器数据恢复中心，转载请联系作者，如果实在不想联系作者，至少请保留版权，谢谢。
[数据恢复故障描述]
1台sun sparc solaris系统，安装有oracle数据库，未知原因(有人为操作可能，但限于多方原因，无法得知)，装载数据库的文件系统无法挂载，需要恢复oracle数据库。
[数据恢复过程]
首先对故障硬盘进行全面的完整备份，使用dd命令备份成nfs上的一个镜像文件。
对镜像文件进行完整分析，发现超级块存在故障。
抛开超级块，进行文件系统分析：
1、查找及分析根目录记录，找到。
2、根据根目录查找第一个节点区，找到，并以此分析块大小。
3、根据根据节点区特点，确定节点区大小。
4、查找第二个节点区，随之确定整个文件系统结构。
5、发现/lost+found文件夹里有大量以数字命名的目录及文件，通常就是由于fsck造成的。
6、按用户提供的目录信息从底层进入分析，找到数据库所在目录，再返回分析需恢复文件的节点区，发现节点区有错误，部分节点的索引位置清0。
通过文件系统的分析，无法全部重组数据库文件。
按sparc solaris上的oracle数据文件组织结构，对全盘进行分析处理。
根据重组好的数据库结构加上部分文件系统信息，成功导出所有数据库。
100%数据库恢复成功。
[后记]
１、此例的故障原因无从考评，但明显的，fsck是不应该执行的。当UFS文件系统出现故障后，如果条件允许，尽可能先对故障盘做备份操作，如果无法做备份，至少应该先以只读的方式测试fsck修复，或选择向导式修复，同时在发现导演时尽快停下操作。
２、UFS文件系统是个不太健壮的文件系统，推荐条件允许的话，使用Vxfs（ZFS本人没测试，不敢妄言，按理应该不错）
３、做好备份策略，也不要把备份放在同一存储体上。
[数据恢复故障描述]
1台sun sparc solaris系统，安装有oracle数据库，未知原因(有人为操作可能，但限于多方原因，无法得知)，装载数据库的文件系统无法挂载，需要恢复oracle数据库。
[数据恢复过程]
首先对故障硬盘进行全面的完整备份，使用dd命令备份成nfs上的一个镜像文件。
对镜像文件进行完整分析，发现超级块存在故障。
抛开超级块，进行文件系统分析：
1、查找及分析根目录记录，找到。
2、根据根目录查找第一个节点区，找到，并以此分析块大小。
3、根据根据节点区特点，确定节点区大小。
4、查找第二个节点区，随之确定整个文件系统结构。
5、发现/lost+found文件夹里有大量以数字命名的目录及文件，通常就是由于fsck造成的。
6、按用户提供的目录信息从底层进入分析，找到数据库所在目录，再返回分析需恢复文件的节点区，发现节点区有错误，部分节点的索引位置清0。
通过文件系统的分析，无法全部重组数据库文件。
按sparc solaris上的oracle数据文件组织结构，对全盘进行分析处理。
根据重组好的数据库结构加上部分文件系统信息，成功导出所有数据库。
100%数据库恢复成功。
[后记]
１、此例的故障原因无从考评，但明显的，fsck是不应该执行的。当UFS文件系统出现故障后，如果条件允许，尽可能先对故障盘做备份操作，如果无法做备份，至少应该先以只读的方式测试fsck修复，或选择向导式修复，同时在发现导演时尽快停下操作。
２、UFS文件系统是个不太健壮的文件系统，推荐条件允许的话，使用Vxfs（ZFS本人没测试，不敢妄言，按理应该不错）
３、做好备份策略，也不要把备份放在同一存储体上。
2009年5月5日星期二
硬盘坏道引起的LINUX ext3故障的数据恢复过程记录
作者：张宇，北亚服务器数据恢复中心，转载请联系作者，如果实在不想联系作者，至少请保留版权，谢谢。
[数据恢复故障描述]
一台linux网站服务器，管理约50个左右网站，使用一块SATA 160GB硬盘。正常使用中突然宕机，尝试再次启动失败，将硬盘拆下检测时发现存在约100个坏扇区。
某数据恢复公司修复坏道后，尝试了约3天时间，未恢复成功。
[数据恢复过程]
接到盘后，首先通过PC3K with DE对故障盘进行完整镜像操作，在镜像中进行数据分析。
整块硬盘由两个分区组成：100M的boot分区及剩余空间的/分区(通过LVM管理)，文件系统均为EXT3。
根分区超级块正常，根据超级块查看第一块组描述表正常，但节点区全为0。
根据块组描述表分析其他块组，发现前27个块组全部为0，但块组前后的数据区明显有用户数据存在。
中间块组区元数据正常(描述表、节点、BITMAP等)
最后部分块组的元数据区全部为0。
试图查找根目录，找到。
以根目录为线索，恢复根目录节点区，成功。
以生成的根目录节点区与根目录记录生成文件系统树，成功后已经可以看到大量数据，文件系统结构正常。但部分文件或文件夹的节点为0，通过节点跟踪，发现节点区位于文件系统前部分及后部分。
试图恢复节点区为0的文件与文件夹，文件夹大部分恢复成功，但文件大部分无法恢复。
试图恢复用户曾做过的.TAR.GZ备份包，恢复成功，但打开时提示出错，中间数据被破坏，只能有限导出部分网站。
最终评估约70%的数据恢复成功。
[数据恢复故障原因推断]
数据恢复的故障原因往往无法明确得知，此例中仅仅推断如下：
1、出现坏道后，用户可能试图进行自动或手工的fsck操作，导致进一步的灾难。
2、以部分块组全为0看，有可能做过未完成的mkfs。
3、送修的数据恢复公司并不专业，有破坏数据的可能性。
[给用户的建议]
1、重要的数据一定不要用单盘做存储环境，目前构架一套简单的RAID并不需要很大的投入。
2、一定要做好备份工作，最起码，备份包不要放到同一存储体上，退而求其次，也一定不要放到同一分区下。
3、硬盘出现故障后，一定不要反复尝试处理，应尽快做完整备份操作。
4、尽可能选择专业一点的数据恢复公司进行处理，不专业的公司或个人公司部分做事相当无耻，无意或有意的会对故障盘进行破坏(有意的目的是为了提高报价要挟或维持名声)。
[数据恢复故障描述]
一台linux网站服务器，管理约50个左右网站，使用一块SATA 160GB硬盘。正常使用中突然宕机，尝试再次启动失败，将硬盘拆下检测时发现存在约100个坏扇区。
某数据恢复公司修复坏道后，尝试了约3天时间，未恢复成功。
[数据恢复过程]
接到盘后，首先通过PC3K with DE对故障盘进行完整镜像操作，在镜像中进行数据分析。
整块硬盘由两个分区组成：100M的boot分区及剩余空间的/分区(通过LVM管理)，文件系统均为EXT3。
根分区超级块正常，根据超级块查看第一块组描述表正常，但节点区全为0。
根据块组描述表分析其他块组，发现前27个块组全部为0，但块组前后的数据区明显有用户数据存在。
中间块组区元数据正常(描述表、节点、BITMAP等)
最后部分块组的元数据区全部为0。
试图查找根目录，找到。
以根目录为线索，恢复根目录节点区，成功。
以生成的根目录节点区与根目录记录生成文件系统树，成功后已经可以看到大量数据，文件系统结构正常。但部分文件或文件夹的节点为0，通过节点跟踪，发现节点区位于文件系统前部分及后部分。
试图恢复节点区为0的文件与文件夹，文件夹大部分恢复成功，但文件大部分无法恢复。
试图恢复用户曾做过的.TAR.GZ备份包，恢复成功，但打开时提示出错，中间数据被破坏，只能有限导出部分网站。
最终评估约70%的数据恢复成功。
[数据恢复故障原因推断]
数据恢复的故障原因往往无法明确得知，此例中仅仅推断如下：
1、出现坏道后，用户可能试图进行自动或手工的fsck操作，导致进一步的灾难。
2、以部分块组全为0看，有可能做过未完成的mkfs。
3、送修的数据恢复公司并不专业，有破坏数据的可能性。
[给用户的建议]
1、重要的数据一定不要用单盘做存储环境，目前构架一套简单的RAID并不需要很大的投入。
2、一定要做好备份工作，最起码，备份包不要放到同一存储体上，退而求其次，也一定不要放到同一分区下。
3、硬盘出现故障后，一定不要反复尝试处理，应尽快做完整备份操作。
4、尽可能选择专业一点的数据恢复公司进行处理，不专业的公司或个人公司部分做事相当无耻，无意或有意的会对故障盘进行破坏(有意的目的是为了提高报价要挟或维持名声)。
2009年4月30日星期四
某网站服务器4*136G RAID数据恢复过程
作者：张宇，北亚服务器数据恢复中心，转载请联系作者，如果实在不想联系作者，至少请保留版权，谢谢。
[数据恢复故障描述]
某网站服务器，品牌为组装，使用tyan(泰安)主板，AMD CPU*４,由4块68针SCSI硬盘 RAID0组成存储体系(听说2007年花了5万元买的，而且采用RAID0，这个专业程度真是不敢恭维)。
操作系统为LINUX，重要数据为MYSQL数据库及网站数据文件。
由于电源损坏(5万元买的设备竟然没有冗余电源)，重新更换了电源测试，硬件销售商竟然怕数据损坏，留下RAID卡把硬盘全部拔掉启系统(真是无语了)，再次连接启动系统时，RAID信息已经损坏。
之后做了一些操作。(此部分操作可能涉及责任问题，无法询问清楚)
最后的现象是：启动操作系统时提示无效的引导记录。
需要恢复服务器数据，同时重新激活修复服务器系统。
[数据恢复分析]
更换电源后，因硬盘全部拔掉，但RAID卡依然留在主机系统里，这样，加电检测RAID控制器时，就会认为所有硬盘已经存在故障，导致RAID逻辑卷下线。
重新加电后，虽然硬盘可能还是好的，但RAID控制器作为安全考虑，不会试图重新加载所有硬盘，重建RAID卷。这时候如果有一些正确有方式还有可能恢复数据(但数据重要的话不建议，可以参考我的其它文章)，但估计用户采用的错误的方式进行了重建等操作，导致所有数据不可用。
RAID0本身不会涉及同步操作，故而除非重建时清0数据，其余情况应该不会有致命性损坏，但需要分析原RAID的结构，并进行虚拟重组。
[数据恢复过程]
１、对所有硬盘按单盘方式完整镜像。
２、在镜像中分析原RAID的结构参数。
３、搭建虚拟RAID环境，组织RAID逻辑卷。
４、为保证完整性，将数据打包为TAR.GZ。
５、重新配置RAID，安装系统，将恢复后的数据迁移回原系统。
[数据恢复故障描述]
某网站服务器，品牌为组装，使用tyan(泰安)主板，AMD CPU*４,由4块68针SCSI硬盘 RAID0组成存储体系(听说2007年花了5万元买的，而且采用RAID0，这个专业程度真是不敢恭维)。
操作系统为LINUX，重要数据为MYSQL数据库及网站数据文件。
由于电源损坏(5万元买的设备竟然没有冗余电源)，重新更换了电源测试，硬件销售商竟然怕数据损坏，留下RAID卡把硬盘全部拔掉启系统(真是无语了)，再次连接启动系统时，RAID信息已经损坏。
之后做了一些操作。(此部分操作可能涉及责任问题，无法询问清楚)
最后的现象是：启动操作系统时提示无效的引导记录。
需要恢复服务器数据，同时重新激活修复服务器系统。
[数据恢复分析]
更换电源后，因硬盘全部拔掉，但RAID卡依然留在主机系统里，这样，加电检测RAID控制器时，就会认为所有硬盘已经存在故障，导致RAID逻辑卷下线。
重新加电后，虽然硬盘可能还是好的，但RAID控制器作为安全考虑，不会试图重新加载所有硬盘，重建RAID卷。这时候如果有一些正确有方式还有可能恢复数据(但数据重要的话不建议，可以参考我的其它文章)，但估计用户采用的错误的方式进行了重建等操作，导致所有数据不可用。
RAID0本身不会涉及同步操作，故而除非重建时清0数据，其余情况应该不会有致命性损坏，但需要分析原RAID的结构，并进行虚拟重组。
[数据恢复过程]
１、对所有硬盘按单盘方式完整镜像。
２、在镜像中分析原RAID的结构参数。
３、搭建虚拟RAID环境，组织RAID逻辑卷。
４、为保证完整性，将数据打包为TAR.GZ。
５、重新配置RAID，安装系统，将恢复后的数据迁移回原系统。
2009年4月28日星期二
找回在线写博因断网丢失的已编数据
在线写博偶尔会遇到这样的问题：花了好长时间码了好多字，一按提交，发现网断了，又没有保存在草稿里，如果不想重新写(会很痛苦的)，可以参考一下以下办法。
恢复这些数据的原理是：当我们按下提交按钮时，浏览器会生成POST表单数据，以HTTP（或HTTPS）协议进行发送。这些POST表单数据会首先读入内存，再进行发送，读入内存的过程与网络是否畅通无关，所以在断网后，实际的POST数据还存在于内存当中，可以从内存中取回这些数据（当然要很快，因为内存空间已经释放，如果有别的进程申请内存空间，就有可能重写数据了）
用到一个工具，WINHEX。
出现问题后，尽可能保持当前状态，千万不要关闭浏览器窗口。只打开WINHEX－>TOOLS－>OPEN RAM
然后在弹出的窗口，选择我们编辑文件所用的浏览器进程(如果开了多个浏览器进程，可以依次尝试)，再选中"Entrie Memory"，单击"OK"
在打开的编辑窗口，按下CTRL+A，在编辑区点击右键，EDIT－>COPY BLOCK－>INTO NEW FILE。选择一下目标文件，导出。这一过程的目的是尽快地把内存的东西保存在磁盘上，就不用担心有变化了。
但如果开的浏览器进程很多，就最好不要先保存了，可以直接查找，以尽可能少得用到内存，避免因WINHEX操作太多重写需恢复数据区。
可以直接在打开的编辑窗口或在保存下来的文件中查特征字符串，可以是我们之前编辑内容中的一段特有数字、英文或中文(涉及字符集问题，不建议查中文)，也可以是博客页面的一些POST特征。查找的内容出现的次数越少越好。
以本文为例，我可以查找“INTO NEW FILE”这个字符串：
查到后。将前后一片文本保存为一个文本文件，用记事本打开。
找到已经编辑的数据，复制。
在博客上重写一文章，标题、TAG等重写一下或者从恢复出来的文本中提取，内容区切换到源码状态，把复制的内容粘贴下来。
再切换过来看看，是不是以前编辑的数据又回来了?
注意：为了尽可能避免内存变更，如果之前没有安装过WINHEX，最好使用绿色版的WINHEX。
2009年4月27日星期一
linux ext3下删除mysql数据库的数据恢复案例
作者：张宇，北亚MYSQL数据恢复中心，转载请联系作者，如果实在不想联系作者，至少请保留版权，谢谢。
[数据恢复故障描述]
一台重要的MYSQL数据库服务器，146GB*2，RAID1，约130GB DATA卷，存储了大约200~300个数据库。平时管理员对每个数据库dump出以后，直接压缩成.gz包，再将所有重要的.gz 包合起来压缩成一个总的.tar.gz包，这些文件每日产生一次，覆盖原来的备份。数据文件及备份文件全部存储于data卷上。
一次系统维护中，管理员不小心将data卷下的所有文件全部rm，删除后，马上停止系统，再未做其它操作，但删除时仍有大量终端在访问此服务器。
要求恢复mysql数据库文件，即myd、frm、myi(可重建)文件，或每个数据库的.gz包，或所有重要数据库总的.tar.gz备份包。
[数据恢复分析]
ext3下的数据删除，理论上，会清除inode中除节点类型、日期外的其他属性，诸如文件大小、数据存储地址等属性会全部清0，同时目录表中会以目录条目长度的方式屏蔽掉已删除文件，但会保留节点编号，最后会改变BITMAP中的空间占用标志。
即使是目录表中存在删除文件的节点编号，但因节点内容已经没有需要的东西，与数据区也是脱钩的。
从数据角度，大多数文件类型都会有特定的文件头标志，按头标志是有可能找到删除文件的起始位置的，但EXT3以块组为单位进行存储，同时数据与索引是混合存储于数据区的，所以数据连续存储的可能性非常之小，这样，按文件格式进行处理也是很困难的。
唯一的算法是结合上述几个特征，加上对日志的分析，加上对存储过程的模拟分析，尽可能地逼近真实存储结构。
[数据恢复过程]
１、对故障卷做完整备份。
２、对总.tar.gz进行恢复分析，但恢复出来的文件解压到50%左右会报错，后续文件列表也无法列出。经分析，最大的原因是删除时仍有数据写入破坏文件导致。
３、对分包的.gz文件进行恢复分析，大多数恢复成功。
４、对于未恢复成功的.gz数据库。直接恢复其myd\frm数据文件，所有数据恢复成功。
[其他]
１、LINUX EXT3数据删除后应尽快断掉文件系统IO，通常umount文件系统即可。
２、对故障卷做dd备份，确保数据恢复过程不会导致更严重的故障。
[数据恢复故障描述]
一台重要的MYSQL数据库服务器，146GB*2，RAID1，约130GB DATA卷，存储了大约200~300个数据库。平时管理员对每个数据库dump出以后，直接压缩成.gz包，再将所有重要的.gz 包合起来压缩成一个总的.tar.gz包，这些文件每日产生一次，覆盖原来的备份。数据文件及备份文件全部存储于data卷上。
一次系统维护中，管理员不小心将data卷下的所有文件全部rm，删除后，马上停止系统，再未做其它操作，但删除时仍有大量终端在访问此服务器。
要求恢复mysql数据库文件，即myd、frm、myi(可重建)文件，或每个数据库的.gz包，或所有重要数据库总的.tar.gz备份包。
[数据恢复分析]
ext3下的数据删除，理论上，会清除inode中除节点类型、日期外的其他属性，诸如文件大小、数据存储地址等属性会全部清0，同时目录表中会以目录条目长度的方式屏蔽掉已删除文件，但会保留节点编号，最后会改变BITMAP中的空间占用标志。
即使是目录表中存在删除文件的节点编号，但因节点内容已经没有需要的东西，与数据区也是脱钩的。
从数据角度，大多数文件类型都会有特定的文件头标志，按头标志是有可能找到删除文件的起始位置的，但EXT3以块组为单位进行存储，同时数据与索引是混合存储于数据区的，所以数据连续存储的可能性非常之小，这样，按文件格式进行处理也是很困难的。
唯一的算法是结合上述几个特征，加上对日志的分析，加上对存储过程的模拟分析，尽可能地逼近真实存储结构。
[数据恢复过程]
１、对故障卷做完整备份。
２、对总.tar.gz进行恢复分析，但恢复出来的文件解压到50%左右会报错，后续文件列表也无法列出。经分析，最大的原因是删除时仍有数据写入破坏文件导致。
３、对分包的.gz文件进行恢复分析，大多数恢复成功。
４、对于未恢复成功的.gz数据库。直接恢复其myd\frm数据文件，所有数据恢复成功。
[其他]
１、LINUX EXT3数据删除后应尽快断掉文件系统IO，通常umount文件系统即可。
２、对故障卷做dd备份，确保数据恢复过程不会导致更严重的故障。
订阅：
博文 (Atom)
