IDC资讯中心
一次”惊险”的数据恢复经历
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.如果有朋友对此文有不同意见,尽请指教。
联系方式owlbird@163.com
