作者：张宇，北亚服务器数据恢复中心，转载请联系作者，如果实在不想联系作者，至少请保留版权，谢谢。
[数据恢复故障描述]
一台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、尽可能选择专业一点的数据恢复公司进行处理，不专业的公司或个人公司部分做事相当无耻，无意或有意的会对故障盘进行破坏(有意的目的是为了提高报价要挟或维持名声)。
订阅：
博文 (Atom)
