一次"惊险"的数据恢复经历
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格式的文件系统的数据结构，根据其不同的特点和作用大致可分为
1.引导扇区.
2.DBR区(DOS BOOT RECORD)即操作系统引导记录区的意思.
3.FAT表（File Alloction Table)位于DBR之后，一般应有两个，其中一个为另一个的备份,它的重要作用是存储了指向文件所在簇的指针(有关概念我将在讨论NTFS文件格式时介绍).
4.DIR区(Directory)即文件根目录区。
5.DATA区,顾名思义这个区是用户存放数据的地方，占磁盘空间的绝大部分，它才是最关键的地方。
现在我们来谈一谈有关NTFS文件格式的基础知识。在NTFS中，所有存储在卷上的数据都包含在文件中，包括用来定位和获取文件的数据结构，引导程序和记录这个卷的（NTFS元数据）的记录的位图，这体现了NTFS的原则：磁盘上的任何事物都为文件。在文件中存储一切使得文件系统很容易定位和维护数据，而在NTFS中，卷中所有存放的数据均在一个叫MFT的文件记录数组中，叫主文件表(Master File Table)，MFT是由高级格式化产生的。而MFT则由文件记录(File Record)数组构成。File Record的大小一般是固定的，不管簇的大小是多少，均为1KB，这个概念相当于Linux中的inode。File Record在MFT文件记录数组中物理上是连续的，且从0开始编号。MFT仅供系统本身组织、架构文件系统使用，这在NTFS中称为元数据(Metadata)。以下列出Windows2000的NTFS主文件表的重要的元数据文件
0 $MFT
1 $MFTMirr
2 $LogFile
3 $Volume
4 $AttrDef
5 $Directory
6 $Bitmap
7 $Boot
8 $BadClus
9 $Secure
10 $UpCase
11 $Extend
这些NTFS主文件表的重要的元数据文件都以$(美元符号)开始的名字，但符号是被隐藏的，在Windows2000中不能使用dir命令(甚至加上/a参数)像普通文件一样列出这些元数据文件。实际上File System Driver(ntfs.sys)维护了一个系统变量NtfsProtectSystemFiles用于隐藏这些元数据。但是微软公司提供了一个OEM TOOL,叫NFI.EXE,用此工具可以转储NTFS主文件表的重要的元数据文件（元数据：是存储在卷上支持文件系统格式管理的数据。它不能被应用程序来访问，它只能为系统提供服务），以下是我给出的一个例子：
C:\>nfi d:
File 0
Master File Table ($Mft)
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident) logical sectors 32-21151 (0x20-0x529f)
$BITMAP (nonresident) logical sectors 16-19 (0x10-0x13)
File 1
Master File Table Mirror ($MftMirr)
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 2048284-2048291 (0x1f411c-0x1f4123)
(由于篇幅限制，其余省略）
而这些元数据文件文件是系统驱动程序装配卷所必需的，win2000给每个分区赋盘符并不表示该分区包含有win2000可以识别的文件系统格式，如果一旦主文件表损坏，那么该分区在win2000下是无法读取得，那么为了能使该分区能够在win2000能被识别，也就必须首先重建win2000可以识别的文件系统格式即主文件表，这可通过高级格式化来该分区来完成。这是你可能会想，如果格式化了分区，那么分区的内容不是全没有了吗？似乎是这样，当笔者打开已格式化了的D盘，空空如也.众所周知，Windows以簇号来定位文件在磁盘存储的位置，在FAT格式的文件系统有关簇号的指针是包含在FAT表中，而在NTFS中有关簇号的指针是包含$MFT及$MFTMirr文件中（ 注：$MFTMirr为$MFT的备份，如果$MFT记录被破坏，NTFS就读取$MFTMirr文件，$MFT及$MFTMirr的数据段位置都存储在引导扇区中，引导扇区的副本位于分区的末端）。那么$MFT及$MFTMirr文件已经被重建，所以我们的文件也就看不见了，但是实际上这些文件并没有真正的消失，他们还藏在磁盘介质中,而recoverNt不是以文件的簇号来定位文件，它用的是低阶的办法，是通过文件控制块(FCB)的磁盘存取方式来读出文件的，这是他高明的地方，而不是以文件代号式磁盘存取（这需要扩充功能调用），因此当我用recoverNt读取D盘上的文件时，花了1个多小时，所需的四个文件都找到了，我将之保存到了c:\mdf文件家下。
最后
打开sql2000企业管理器，选中一个实例，右建点击数据库，选择附加数据库，给出数据文件相应的磁盘位置(注意最好主数据文件和相应的日志文件放在同一目录下)，一切ok,朋友的客户数据又找回来了。
后记:
1.作为一个数据库管理员要经常备份，时时小心，切忌不要想我的朋友一样大意，不然后果不堪设想。
2.我这篇文章并不是想给出什么具体的方法，只是想讨论一下关于数据恢复的思维方式。
3.如果病毒的制造者能多为别人想一想，而不是图一时之痛快就好了，把自己的聪明才智用在正道上。
4.如果有朋友对此文有不同意见,尽请指教。
本文地址：http://com.8s8s.com/it/it21381.htm