数据恢复与软故障处理基本指南(4)

下面举一些数据恢复或者软故障处理的例子，这些事例是从我参与大量的故障处理中选取的一些典型事例。在选取典型事例中，遵循了以下原则。
①、 处理过程能够表现一定思想，而不是纯粹的技术手段。
②、 处理过程本身并不算复杂，基本不出现汇编程序，一般读者能够理解。
③、 处理过程本身并不完美，中间可能犯了一些错误，有的甚至局部失败。可以使大家引为借鉴。
④、 处理过程本身并不仅仅是纯粹的逻辑思维，有人的心理活动对技术的干扰。以使大家能更好的避免这些。

1、 被CIH破坏硬盘恢复一例
委托恢复人：某银行
硬盘情况：CIH发作，蓝屏死机。该单位电脑人员曾用KV300 F10进行修复，但没有成功，又恢复了保存的MBR。

修复工具：
准备好软盘3张：
DISK1 -WIN98启动盘（带DEBUG）
DISK2-DISKEDIT等工具（此盘不要写保护）
DISK3-DOS下杀CIH的工具

基本思想：
1、FAT2没有损坏的情况，用FAT2覆盖FAT1。
2、FAT2也已经损坏的情况，我一般是只期待找回其中某些关键的文件了。
我们最期待的是这些文件是连续的。如果不连续的话，也并非没有可能，但这往往还要知道文件的一些细节，包括对一些文件本身的连接结构有了解。如果FAT2没有完全破坏，是有一定用处的，另外，一般来说，FAT16的硬盘因为FAT表靠前破坏的比较严重，一般两个FAT表都坏了，小硬盘也很难恢复了。

修复过程：
把我的硬盘摘下，挂上待恢复的的硬盘，开机，进入SETUP，检测硬盘，把参数记下——CLY 620 HEAD 128 PRECOMP 0 LANDZ 4959 SECTOR 63 MODE LBA。 用准备好的软盘启动：
A：>C：
显示Invalid drive specification
FDISK/MBR重建主引导记录。（这是个习惯），重新软盘引导：（可能没有必要）。
此时已经看的见C：硬盘。
启动DISKEDIT，启动过程中显示Invalid media type reading DRIVER C,哎呀，算了，还是先用DEBUG清空分区表,，并置80和55aa标志。
重新启动，再运行DISKEDIT，显示设定为READ ONLY，没关系，把TOOLS/CONFIGURATION中的只读选项去掉，存盘，好了，可以编辑了。由于当时接的硬盘有多块，我把这块当成了是一块只有C分区，所以没看别的东西，我们期待FAT2没有损坏，以用FAT2覆盖FAT1，在这个时候DISKEDIT要比DEBUG容易的多，在FIND OBJECT中选择FAT，查一下起始扇区，好的，在CYL 0 SIDE68 SEC 14，0000H，F8 FF FF 0F（FAT32的），好的，FAT2没坏。其实如果不用DISKEDIT的可以用一端小程序查，偏移0000的F8 FF FF。

由于以为只有C分区，所以，上来就在FIND中查找IOSYS（IO和SYS中要有空格）以查找ROOT区。找到后观察，是否有C：\下常见文件。好的，ROOT区没被破坏。记下了该扇区的CYL 0、SIDE 68、SEC 14，备用。FAT1一般前面已经被破坏了，但后面应该还在，这可以作为检查。因为是32位的，FAT1一般在CYL 0 SIDE1 SEC 33。因为有了ROOT区然后应该计算FAT表的长度了，因为FAT2到ROOT前一扇区为止，所以非常简单。

然后可以用FAT2覆盖FAT1，这里用DEBUG还是DISKEDIT都可以，如果用DEBUG一般是用INT 25读绝对扇区，再用INT 26写入，用DISKEDIT则比较简单。程序：（略）

然后可以恢复主引导记录、隐含扇区和BOOT区，可以先用NDD修复分区表，其他可以考虑可以考虑用标准覆盖法，如果你希望下一步由NORTO NUtilities来接手,这些都可以不做。我从另一台FAT32的机器上取来了相应的部分，写了进去。我这时发现好象有一个D盘。先看一下在说吧。

好了，关机串上我的硬盘，用NORTON Utilities 4扫描C盘，文件基本恢复，对C盘杀毒，WHY，没有发现病毒，换了2种杀毒软件还是没有病毒，现在显示C盘是948M，有一个D盘，但是95下无法浏览，DOS下乱码。于是打电话核实当时的情况，原来是26日那天，放进一张光盘，光驱灯亮了一会，就硬盘狂响，蓝屏死机了。应该证实我的推断一样，是光盘的AUTORUN程序有CIH病毒。所以说没有实时防御能力的软件是没有意义的。另外，他们的硬盘确实分两个区，而且重要文件在D区。然后在修复D盘吧，再回到DOS，用DEBUG查找结束标志为55AA的扇区，然后根据后面是否有FAT判定是否为扩展分区。此时可算出大小来返回修订主分区表。当然，许多工具也可以很好的完成这一工作。如果你没有把握，就用他们完成好了。其实我就是用自己的RE做的，否则手工做确实太麻烦。

经验总结：

①、你不要听信或者凭记忆想一块硬盘该是怎么样的，一定要自己去看，我就是犯了这个错误。
②、某些软件的修复功能确实如一些网友所讲可能有一定隐患，如果银行的电脑人员在用KV300 F10处理之前没有备份，可能要给我找些麻烦。

我们应当看到，恢复数据要本着几项原则。
①、 最好先备份，这也是而后我写HD-MIRROR的原因
②、 优先抢救最关键的数据
③、 在稳妥的情况下先把最稳定的鸡蛋捞出来，（理应先修复扩展分区，再修复C），最好修复一部分备份一部分。
④、 要先作好准备，不要忙中出错，此间，由于我的机器没有装过NORTON，先解压，习惯的敲了一个D：\TEMP,这才想起来D盘已经是人家的硬盘，文件险些解在没有完全修好的C盘上。这种错误有时会经常发生。

2、 LINUX错误安装带来问题一例

委托恢复人：某信息港
硬盘情况：4.3G硬盘，分三个区，D、E中有很多重要数据。原来装95系统，做主盘。在试图向从盘上装LINUX的时，误将安装盘符选为C，而后发现终止，此时硬盘无法自举。软盘启动无法看到任何有效分区。
工具准备：
DISK1 - WIN98启动盘（带DEBUG）
DISK2 - DISKEDIT等工具（此盘不要写保护）

修复思想：

修复分区表中的扩展分区，重置主分区的分区类型。

修复过程：

用软盘启动，FDISK/MBR清除LILO，重建代码，用DISKEDIT调入MBR观察，已经没有了扩展逻辑分区的信息。80激活分区的类型已经变成83（LINUX）这时我犯了与前面类似的错误，本应先修复分区信息，但我却依然去先试图C。而且修复C的时是否我又犯了一个致命的错误，那就是我算错了C盘的大小。本来C盘是650M左右的一个分区，应当把分区类型置为06H（大DOS），而我误算C为340M，因此我置为了04H（普通FAT16），这时我想对C做进一步修复，就把硬盘串到我的机器上，开机后C盘可见，文件似乎完好。此时我选择用NU来自动修复它的C盘。最后的结果是，由于我选错了分区类型，修复使C盘彻底崩溃。我重新起机后，再试图用NU检测C时，我的98马上蓝屏，另一个恶果就是我决定从软盘启动，用DISKEDIT查看时，发现可能由于I/O参数表的损坏，DISKEDIT无法启动了。而后，我用RE恢复分区表，但在我的方正上，RE竟然溢出，后来，我找到一台兼容机，在上面运行RE，这才恢复了D、E两个分区。此时，委托我恢复的朋友打来电话，说只找到D、E就可以。我这才放心。

经验总结：分区类型只是一个字节，却会带来如此严重的后果。可见，修复数据必须异常慎重。

3、 NT SERVER硬盘崩溃一例

相应情况：

这是单位里的一台NT服务器。三个NTFS分区，有重要数据在内。硬盘崩溃，不能启动，软盘启动后，用NTFSDOS 不能映射任何逻辑分区。

工具准备：

DISK1 - WIN98启动盘（带DEBUG）
DISK2 - DISKEDIT等工具（此盘不要写保护）

修复过程：

用DEBUG读取主分区表，发现完全混乱。反汇编后发现为一段有逻辑意义的代码，我当时十分紧张，以为硬盘被加密了。只好向一个高手HIT-007求援，不料他用DEBUG看了两下，马上退出来，做了FDISK/MBR。我大惊失色。但重起后，硬盘竟能启动进入NT，当然只剩下C一个分区。而后我很容易的恢复了另外两个分区。他对我说，你一看MBR中的内容就被吓住了，我向后看后面的一些系统扇区情况都是正常的。这就说明只是MBR不正常而已。
经验总结：数据恢复中情绪的因素很重要，无论什么情况不能慌张，因为这可能影响到你 是否能全面冷静的思考。

4、 NOVELL服务器掉电问题一例：

相应情况：

这是两年前处理过的一个问题，我当时在某证券营业部兼职做网管，开市时，一台NOVELL服务器因UPS故障突然掉电重起。当时的交易系统还是DBF数据库，按照规程，应该运行一个全部数据库重建索引例程。但索引中，却有7个库无法重建，检查发现，是库无法打开。

修复情况：

我恍惚记得深圳一个证券界电脑工程师对我说过，DBF文件头在突然死机中可能会损坏。但不知细节如何。我初步判定，由于库写入时，先修改文件头中的记录总数，再写入记录。可能是掉电时文件头已经修改但记录没有成功写入，因此，应该是记录数不符。但文件头中记录数在哪里呢。我于是这样处理，把这些损坏的数据库和一个完好的数据库COPY到本地，用FOXPRO打开看到记录数，换算成16进制。然后查找这个HEX串，判定找到记录数地址，（这个库记录数应当比较多，减少混淆的可能，否则容易找错）。由于我不知道处理DBF的公式，只好把损坏数据库的记录数每次减一，然后再用FOXPRO打开实验。其中5个数据库减一后就可以打开，只有一个数据库直到减4后才正常。全处理过程从掉电开始只有20分钟，基本没有影响交易进行。

经验总结：当出现问题，但你不知道确切的处理方法时，要充分进行分析。

5、 某财务系统数据处理一例：

相应情况：

也是我在证券公司处理的情况，某单机版财务系统，基于Clipper，当时是年初安装，使用正常至6月份底，突然发现该月数据紊乱，与实际出入巨大。出品公司的人来看过后，声称需要1周处理时间和近万元的处理费，我听说后，建议财务部拒绝其“讹诈”，由我来处理。

分析处理过程：

由于我对财务一窍不通，我请财务经理讲明了情况和一些概念，又分析了系统的大致结构。我发现本月每一笔数据都是正常的，只是因为多了上千笔没有发生的收支，才使汇总表发生了变化。那么这些数据是哪里来的，就成了问题的关键。在看了该软件的初始状态后，我似有所悟，问财务软件初装后并没有的上百个“科目”是从哪里建立的。财务经理回忆是上年底从某营业部发来的，我当时就明白了，那个营业部是上一年6月成立的，问题显然出在该营业部提供的初始科目不为空，由于上年1-5月该营业部尚不存在，所以数据为空，而该营业部6月以后的数据则随科目转入了我所在营业部的财务系统。经过对当初转入初始科目的对照，证实了我的判断。于是，我做了一段程序，按照对应关系把相关数据从系统库中摘除。从分析问题到问题的解决，只用了三个小时。

经验总结：

①、 当出现数据紊乱时，很重要一点就是找到干扰源。
②、 数据处理绝非仅仅就是一个技术问题，特别是金融系统，一定要得到这方面的专业人士的配合。我想如果没有那位财务经理的信任鼓励和让我对会计知识的速成，问题处理就不会如此顺利.

这只是一些简单恢复的例子，类似的，大家可以将在完整版的文章中看到更多。想说明一点，有一些朋友建议过我把一些复杂的灾难恢复和数据抢救的细节写出来，但因为这些涉及到相关单位一些系统信息等等，就对不起大家了。最后，如果相关问题的话，大家可以到我们主持的169电脑医院查找更多资料，我们的虚拟域名是usafe.yeah.net