一次"惊险"的数据恢复经历
owlbird         


起因
    前几天笔者被一位当数据库管理员的朋友叫去，他的一台做数据库的服务器无法启动，搞的他焦头烂额，后来请人来一看，人家一开口就要2000，没办法只好找我试试。我朋友的这台数据库的操作系统是win2000 server,选择的数据库是sql2000,他任务单位是个传呼台，这台数据库服务器是专门来存储客户材料的，每半个月将数据文件存入磁带内，而出事那天恰恰正是应备份数据库文件，而我朋友买了一张D版的光盘预备在服务上读一读，光盘一放入就自动运转，马上就自动重启，当系统重新引导时就提示如下:NON-SYSTEM DISK,PLEASE INSERT A SYSTEM DISK(看来D版真是害人又害己啊），显然就无法引导系统.

处理
    若计算机不能从硬盘启动，则我们可以通过软盘启动后，试着访问硬盘。如果不能访问硬盘，则可能是主引导区或者可引导分区的引导区被破坏了这时候，我们可以使用DEBUG命令等工具软件查看硬盘的主引导区能否正常。我用一张Msdos系统软盘来引导，进入dos系统后，由于该服务器的主分区是NTFS格式，如果不用第三方软件是无法查看分区信息的，不过我想先用DEBUG命令去看一下MBR(硬盘主引导记录),操作如下：

a:\>DEBUG
XXXX:XXXX a 100 汇编编辑命令指令
XXXX:0100 mov ax，0201 读取一个扇区
XXXX:0103 mov bx，0200 读至当前段内存0200处
XXXX:0106 mov cx，0001 柱面号＝0，绝对扇区数=1
XXXX:0109 mov dx，80 磁头号＝0，驱动器号＝80
XXXX:010C int 13 磁盘读写中缀
XXXX:010E int 3 断点中缀
XXXX:010F 回车 
XXXX:XXXX g=100 执行上述指令
XXXX:XXXX d 380 显示主分区表内容（Hex:1BEH）


    上述命令的详解可参看清华大学出版的《IBM-PC 汇编言语程序设计》，由沈美明 温冬婵编著。我再简单引见一下主分区表。主分区表位于硬盘主引导记录(0柱面0磁头1扇区)的后部.从1BEH字节开始，共占用64个字节，包含四个分区表项。每个分区表项的长度为16个字节，它包含一个分区的引导标志、系统标志、起始和结尾的柱面号、扇区号、磁头号以及本分区前面的扇区数和本分区所占用的扇区数。其中"引导标志"表明此分区能否可引导，即能否活动分区。当引导标志为"80"时，此分区为活动分区；"系统标志"决定了该分区的类型，如"06"为DOS FAT16分区，"0b"为DOS FAT32分区，"83"为LINUX native分区等；起始和结尾的柱面号、扇区号、磁头号指明了该分区的起始和终止位置。)

   这一看不要紧，一看吓一跳，主分区表内参数被大量的26(HEX)所代替，看来这位病毒制造者是位"38"(26H转化为十进数是38),也真够狠的.而我的朋友又没有对MBR进行备份，这下可麻烦大了。不过，通常硬盘0柱面0磁头2扇区是0柱面0磁头1扇区的备份，每当系统引导成功，系统会将0柱面0磁头1扇区的内容复制到0柱面0磁头2扇区，而如果安装了SC COMMANDER,LILO的引导软件，将会占用0柱面0磁头2扇区，而将0柱面0磁头1扇区的内容复制到0柱面0磁头3扇区，这是大家需求留意的问题。因此在没有对MBR进行备份的情况下，查找0柱面0磁头从2扇区开始的隐含扇区，寻觅备份的MBR，通过未被破坏的分区引导记录信息重新建立MBR将是一个很好的处理办法.于是我又做了如下操作： 

a:\>DEBUG
XXXX:XXXX a 100 汇编编辑命令指令
XXXX:0100 mov ax，0201 读取一个扇区
XXXX:0103 mov bx，0200 读至当前段内存0200处
XXXX:0106 mov cx，0002 柱面号＝0，绝对扇区数=2
XXXX:0109 mov dx，80 磁头号＝0，驱动器号＝80
XXXX:010C int 13 磁盘读写中缀
XXXX:010E int 3 断点中缀
XXXX:010F 回车 
XXXX:XXXX g=100 执行上述指令
XXXX:XXXX d 380 显示备份主分区表内容（Hex:1BEH）


  还好，病毒制造者还算有点良心，并没有破坏备份的主分区表的记录信息，那么我们就可利用备份的MBR的记录信息来重建主分区表，操作如下:(注我并未退出Debug)
XXXX:XXXX a 100
XXXX:0100 mov ax，0301 写一个扇区
XXXX:XXXX a 106
XXXX:0106 mov cx，0001 柱面号＝0，绝对扇区数=1
XXXX:XXXX g=100 执行上述指令
再将主分区表调出来看能否已正常写入： 
XXXX:XXXX a 100
XXXX:0100 mov ax，0201 读取一个扇区
XXXX:XXXX g=100 执行上述指令
XXXX:XXXX d 380 显示主分区表内容（Hex:1BEH）
一切正常。不过为了保险起见，还是将MBR内容备份到软盘上。操作如下:
XXXX:XXXX r bx
:00
XXXX:XXXX r cx
:0200 设定主分区表的大小为512字节，bx记录高位字节，cx记录低位字节
XXXX:XXXX n a:\mbr.dat 文件命名
XXXX:XXXX w 0200 将内存地址0200开始的内容写入软盘
XXXX:XXXX q 退出debug

  以为一切ok,但当重新引导时还是提示如下:NON-SYSTEM DISK,PLEASE INSERT A SYSTEM DISK，看来问题多多。只好将该硬盘取下，接在另一台装有win2000 server，分区为NTFS格式的计算机上作为从盘。但当我双击该分区时，提示如下："不能访问D:\,$volume损坏且无法读取",看来该病毒来头不小，能在win2000 server下直接中缀，还能修正MFT,病毒制造者的功力真是不浅。我用chkdsk命令想试一试能否修复$volume，结果提示我无法修复。看来我要彻底恢复这台服务器是不太可能了，那么如今最关键的问题实际就是恢复数据库文件，这才是我朋友和我真正关怀的，据我朋友讲他有两个重要的用户数据库文件，分别命名为client1,client2,于是我们所有的关注就给了这两个数据库,而这两个数据库又分别由后缀名为mdf的文件(用户数据库的主文件），后缀名为log的文件(用户数据库的日志文件，sql2000的数据库主文件由其对应的日志文件来控制所写的内容）.当然,数据恢复的万王之王Recovery是我的最佳选择，我用的是RecoverNt版。Recovery使用相当简单，所要留意的是用Recovery读出的文件不能恢复到同一个硬盘上，必须恢复到其他硬盘上。但不幸的是，当我用RecoverNt来读取D分区时,由于MFT损坏，万王之王也无法读出一个文件，反复试了几次还是不行，只好占时作罢。一回到家，就下定决心好好专研一下win2000的NTFS格式，我手上有两本书，一本是MCSE制胜宝典WIN2000 Server，还有一本是Inside Microsoft Windows 2000,Third Edition的中文版Windows 2000内部揭密，正是书到用时方恨少。又到网上四处搜索有关信息，经过两天的专研，经过大胆的设想，详细的分析，做出了一个令我至今还不敢置信的方法。

高潮
   我预备将无法读取的D盘高级格式化(留意是高级格式化而不是低格)，然后通过RecoverNt来读取文件。为什么我要这样做，让我慢慢道来。首先我想讲一讲windows的文件系统原理，众所周知windows有FAT12,FAT16,FAT32,NTFS等文件格式，而FAT12,FAT16,FAT32文件格式可看作一类，简称FAT格式，而NTFS文件格式又可看作一类。我简单引见一下FAT格式的文件系统的数据结构，