第四章、恢复实例

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

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月以后的数据则随科目转入了我所在营业部的财务系统。经过对当初转入初始科目的对照，证实了我的判断。于是，我做了一段程序，按照对应关系把相关数据从系统库中摘除。从分析问题到问题的解决，只用了三个小时。

经验总结：

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