黑客的聪明并不只是在于他们知道如何去入侵服务器，还在于他们知道如何去伪装自己的攻击。恶意的攻击者会使用多种逃避的手段来让自己不会被检测到，所以作为系统管理员，也应当了解这些手段以应付可能发生的攻击。 

    这篇文章的主要目的不是揭示黑客新的攻击手法，而是对那些黑客所用到的逃避检测的手法以及他们可能留下的证据做描述。这些手段的欺骗性很大，所以想检测到它们也更加的困难。 

网络服务器 

    我们的实验环境使用两种最常用的网络服务器，Apache和微软的InternetInformationServer(IIS)。我们在RedHatLinux上运行Apache1.3.9,在WindowsNT4.0上运行IIS4.0。并且两种都采用普通和允许SSL的版本，所以我们可以对加密和未加密的服务器的攻击做测试。 

16进制编码 

    一种最简单的将攻击伪装的手段就是修改URL请求。作为管理员,我们一般会在日志文件中查找某些字符串，或是一些普通文本的字符集。例如我们在请求中查找匹配已知漏洞的字符串。例如，我们在我们的IIS服务器中发现了如下的字符串，我们就知道有人正在查找是否有IIS中可以远程利用的MDAC漏洞： 

06:45:2510.0.2.79GET/msadc/302  

[root@localhost/root]#nc-n10.0.2.5580  
GET/msadcHTTP/1.0  

[root@localhost]#nc-n10.0.2.5580  
GET/%6D%73%61%64%63HTTP/1.0  

IIS的日志文件显示： 

07:10:3910.0.2.31GET/msadc/302  

[root@localhost]#nc-n10.0.0.280  
HEAD/cgi-bin/test-cgiHTTP/1.0  
[root@localhost]#nc-n10.0.0.280  
HEAD/%63%67%69-bin/test-%63%67%69HTTP/1.0  

10.10.10.10--[18/Oct/2000:08:22:47-0700]"HEAD/cgi-bin/test-cgiHTTP/1.0"2000  
10.10.10.10--[18/Oct/2000:08:23:47-0700]"HEAD/%63%67%69-bin/test-%63%67%69HTTP/1.0"2000  

    首先应注意到的是在这两个例子中都是200代码说明命令完成成功。但是在第二中情况中，日志中出现的是十六进制的值而不是明文的。如果我们是依赖于形式来对这种攻击进行检测的话，那么我们是不可能检测到所发生的攻击的。许多的入侵检测系统使用的格式匹配技术智能化都不高，并且有些产品不会将十六进制的URL转换过后进行匹配。但是不论所使用的入侵检测软件是否能够对十六进制的代码进行转换，所有的网络管理员都应当对这种伎俩有所了解。

*** 

    因为对攻击者而言完全隐藏攻击行为是很难做到的，所以掩盖攻击的真实来源也就成为相当重要的课题了。如果黑客可以隐藏他的源IP地址的话，那么他就可以在不用担心被抓住的情况下进行攻击。而黑客用来隐藏他们的源IP地址的一种手段就是使用***。 

    ***是被合法的用来从一个单一的访问点转发多种协议的。一般来说，内部用户必须通过***才能访问Internet，因此管理员就可以在***指定外部访问以及内部访问的限制策略。用户首先是和***建立连接，然后***就将连接请求转发到真正的目的地址。目的地址会记录下***的IP地址以作为请求的源地址，而不是最初发出请求的系统的IP地址。 

    但是不幸的是***在Internet上的放置太随意了。(可以查看Proxys-4-All来获得这些错误配置机器的列表。)这些服务器经常会存在配置错误使得Internet用户可以连接到这些***上。一旦某个Internet用户通过***连接到某个服务器上，该服务器就会将***的IP地址作为发出请求的源地址记录在日志中。而在被攻击服务器的日志中对攻击者的记录其IP地址是属于一个没有任何攻击行为的“无辜”主机的，而不是攻击者的真正地址。我们来看以下的例子。 

    下面的例子显示了黑客的攻击和攻击在日志中产生的相关信息。 

攻击者  
[root@10.1.1.1/]#nc-v10.8.8.880  
HEAD/HTTP/1.0  
日志文件  
10.1.1.1--[18/Oct/2000:03:31:58-0700]"HEAD/HTTP/1.0"2000  
    在下面这种情况中，我们看到攻击者达到了同样的目的，但是这次他使用了***。  
攻击者  
[root@10.1.1.1/]#nc-v216.234.161.8380  
HEAD 

黑客的聪明并不只是在于他们知道如何去入侵服务器，还在于他们知道如何去伪装自己的攻击。恶意的攻击者会使用多种逃避的手段来让自己不会被检测到，所以作为系统管理员，也应当了解这些手段以应付可能发生的攻击。 

    这篇文章的主要目的不是揭示黑客新的攻击手法，而是对那些黑客所用到的逃避检测的手法以及他们可能留下的证据做描述。这些手段的欺骗性很大，所以想检测到它们也更加的困难。 

网络服务器 

    我们的实验环境使用两种最常用的网络服务器，Apache和微软的InternetInformationServer(IIS)。我们在RedHatLinux上运行Apache1.3.9,在WindowsNT4.0上运行IIS4.0。并且两种都采用普通和允许SSL的版本，所以我们可以对加密和未加密的服务器的攻击做测试。 

16进制编码 

    一种最简单的将攻击伪装的手段就是修改URL请求。作为管理员,我们一般会在日志文件中查找某些字符串，或是一些普通文本的字符集。例如我们在请求中查找匹配已知漏洞的字符串。例如，我们在我们的IIS服务器中发现了如下的字符串，我们就知道有人正在查找是否有IIS中可以远程利用的MDAC漏洞： 

06:45:2510.0.2.79GET/msadc/302  

[root@localhost/root]#nc-n10.0.2.5580  
GET/msadcHTTP/1.0  

[root@localhost]#nc-n10.0.2.5580  
GET/%6D%73%61%64%63HTTP/1.0  

IIS的日志文件显示： 

07:10:3910.0.2.31GET/msadc/302  

[root@localhost]#nc-n10.0.0.280  
HEAD/cgi-bin/test-cgiHTTP/1.0  
[root@localhost]#nc-n10.0.0.280  
HEAD/%63%67%69-bin/test-%63%67%69HTTP/1.0  

10.10.10.10--[18/Oct/2000:08:22:47-0700]"HEAD/cgi-bin/test-cgiHTTP/1.0"2000  
10.10.10.10--[18/Oct/2000:08:23:47-0700]"HEAD/%63%67%69-bin/test-%63%67%69HTTP/1.0"2000  

    首先应注意到的是在这两个例子中都是200代码说明命令完成成功。但是在第二中情况中，日志中出现的是十六进制的值而不是明文的。如果我们是依赖于形式来对这种攻击进行检测的话，那么我们是不可能检测到所发生的攻击的。许多的入侵检测系统使用的格式匹配技术智能化都不高，并且有些产品不会将十六进制的URL转换过后进行匹配。但是不论所使用的入侵检测软件是否能够对十六进制的代码进行转换，所有的网络管理员都应当对这种伎俩有所了解。

*** 

    因为对攻击者而言完全隐藏攻击行为是很难做到的，所以掩盖攻击的真实来源也就成为相当重要的课题了。如果黑客可以隐藏他的源IP地址的话，那么他就可以在不用担心被抓住的情况下进行攻击。而黑客用来隐藏他们的源IP地址的一种手段就是使用***。 

    ***是被合法的用来从一个单一的访问点转发多种协议的。一般来说，内部用户必须通过***才能访问Internet，因此管理员就可以在***指定外部访问以及内部访问的限制策略。用户首先是和***建立连接，然后***就将连接请求转发到真正的目的地址。目的地址会记录下***的IP地址以作为请求的源地址，而不是最初发出请求的系统的IP地址。 

    但是不幸的是***在Internet上的放置太随意了。(可以查看Proxys-4-All来获得这些错误配置机器的列表。)这些服务器经常会存在配置错误使得Internet用户可以连接到这些***上。一旦某个Internet用户通过***连接到某个服务器上，该服务器就会将***的IP地址作为发出请求的源地址记录在日志中。而在被攻击服务器的日志中对攻击者的记录其IP地址是属于一个没有任何攻击行为的“无辜”主机的，而不是攻击者的真正地址。我们来看以下的例子。 

    下面的例子显示了黑客的攻击和攻击在日志中产生的相关信息。 

攻击者  
[root@10.1.1.1/]#nc-v10.8.8.880  
HEAD/HTTP/1.0  
日志文件  
10.1.1.1--[18/Oct/2000:03:31:58-0700]"HEAD/HTTP/1.0"2000  
    在下面这种情况中，我们看到攻击者达到了同样的目的，但是这次他使用了***。  
攻击者  
[root@10.1.1.1/]#nc-v216.234.161.8380  
HEAD 

　　因为NTFS文件系统与FAT和FAT32文件系统完全不同，数据恢复必须采用不同的方法。然而，也有例外，这篇教程的最后一部分将讨论无论任何系统格式下都能运行的最终(last ditch)恢复技术，但是现在我们要讨论的是NTFS文件系统从一个数据恢复点是如何工作的。

　　如果你用Google搜索一下NTFS数据恢复技术，你可能得到最多的链接是关于卖数据恢复产品的网站。这是因为NTFS被设计可以自己执行数据恢复，而不需要使用第三方数据恢复软件或者操作。在这个工作中有两个主要技术来实现这个功能:簇重映射(cluster remapping)和事务日志(transaction logging)。

簇重映射

　　簇重映射是通过自动方式把数据从硬盘包含坏的分区的簇上自动移动到良好的簇的技术。簇重映射的结构不用，取决于包含这个坏的扇区的卷是否是容错的，而且坏的扇区在读写过程中是否被发现。

　　让我们讨论一下在没有容错的卷上写入的操作，当数据被写入NTFS卷，操作系统在写的操作时把检查扇区做为确认进程的一部分，如果操作系统检测到一个扇区是损坏的。Windows标记整个簇都是损坏的，这样它在将来就不往这个簇上存储数据。(这是因为簇不能被再细分)数据将被存储到良好的簇内，这样不会有数据损失。

　　但是如果这个坏的扇区在读取时候被检测到，情况就不一样了。操作系统将返回一个读取错误的消息来响应被数据请求。这里有几种不同的理论关于接下来如何解决这个问题。一些资料表示，一旦这个读取错误发生，Windows把这个扇区和其中的簇标记为损坏，所以簇其中的数据将完全丢失。另外一些资料说，如果这个数据的一部分能读出来，Windows在标记这个扇区为损坏之前，把这些数据移到另一个簇。如果有读者知道关于权威地描述这个问题的微软资料，麻烦告知我(http://www.sitit.com)。

　　手动重建主引导扇区和I/O表

　　有一块容量为8.4G，分了C，D，E三个分区，安装的是WINDOWS98第二版的操作系统的硬盘，在使用过程中出现了如下现象：

　　1.硬盘无法自引导，开机即显示“DISK BOOT FAILURE,INSERT SYSTEM DISK AND PRESS ENTER",在BIOS中可以检测到该硬盘为8.4G;

　　2.用软盘可引导至A提示符下，键入C：，D：，E：回车后均显示“Invalid drive specification",之后仍在A提示符下。

　　根据以上情况分析出现的问题：上述的错误提示，初步可以判断为硬盘的分区表或是主引导扇区0扇区——MBR出现错误所至(如果BIOS检测不到硬盘，则说明硬盘的电路板有问题)。现在用KV3000的F6(硬盘急救箱)功能查看该硬盘扇区。接下来用软盘启动计算机并运行KV3000.EXE,进入KV3000主画面，按下F6键，发现0面0磁道1扇区即通常所说的0扇区已经被清零了，再按下F6，启动搜索硬盘分区的功能，再按下F2可以搜索出硬盘各个分区，如下显示：

　　Hard Disk Total sector Total Bytes Partition Table Sector

　　Disk D:3.150G 6152832 003150249984 in 000004192965

　　Disk E:3.150G 6152832 003150249984 in 000010345860

　　注意：

　　1.因为F2只是搜索硬盘扩展分区表，所以此时不显示主分区C；

　　2.以上显示不一定是绝对正确的，要进一步判断其正确性。

　　下面回到0扇区，按F3键，再输入4192965，即D区分区表所在扇区，直接翻到该扇区，发现确有一个分区表为：

　　0001 41050BFE BF833F00

　　000080E2 5D000000 818405FE 3F02BFE2 5D00BFE2 5D000000

　　从这个表上看，第5个字节的位置是“0B”，表示该分区为FAT32格式。再向后翻63个扇区发现其I/O表也正常，后面的FAT(文件分配表)表及DIR(目录区)区也均在，可以初步认为该分区正确。用同样方法再检查10345860扇区即E盘分区表及以后扇区，判断基本正常，说明搜索到的应为正确分区表。

　　接下来按F2查看C盘BOOT区，如果这时C盘BOOT区也就是63扇区正常，则可以用KV3000的F10功能键自动重建C盘主引导扇区，但此时发现该扇区也被清零，当然也必须手动重建，因为位于0磁道1柱面1扇区即63扇区的应该是DBR(Dos Boot Record)表，是操作系统引导记录区也叫做I/O表，如果DBR表被破坏，则会使操作系统在读写磁盘时无法进行磁盘定位，导致不能读取硬盘上的数据。

　　现在该硬盘不能引导和读取数据的原因基本上已经找到，主要是0扇区和63扇区被清零，下面开始手动重建这两个扇区，恢复数据。

　　一.重建硬盘主引导区(0扇区)：

　　该扇区由“主引导记录+分区表+55AA有效标志”组成，通常也可以分别称作第一关键字，第二关键字和第三关键字。主引导记录即第一关键字中包含了一段引导程序，其主要作用是检查分区表是否正确，并且在系统硬件完成自检后引导具有激活标志的分区上的操作系统，并将控制权交给启动程序。它是由分区程序(如Fdisk等)所产生的。KV3000在此方面具有强大的功能，第一关键字完全可以用KV3000/K来自动重建。

　　下面只需将第二关键字(分区表)及第三关键字55AA标志手动重建。

　　(1)第二关键字是从0扇区的第446字节处开始的，首先在这里建立“80”，该字节是一个分区的激活标志，表示系统可以引导，该字节为“80”表示此分区为活动分区；为“00"表示此分区不可自举，是非活动分区；

　　(2)后面再填入一个字节“01”，表示该分区起始磁头号；

　　(3)后面是“0100”，是一个字，表示该分区起始扇区号及起始柱面号，需要说明的是对于此硬盘，因为C区是小于8G的，所以这里的起始扇区号只用到了低六位，而其高两位给了起始柱面号作为起始柱面号的高两位，也就是说起始柱面号应为十位。

　　(4)下面一个字节处应填写C盘文件格式标志，如果是FAT32格式且容量小于8G，此处应为“0B”，大于8G应为“0C”；FAT16格式为“06”，NTFS为“07”。对于此硬盘，从63扇区向后翻一个扇区即64扇区就发现有FAT表的标志(通常FAT表扇区的前四个字节处为“F8FFFF7F”)，再往后翻可分析出是正确的FAT表，所以该分区为FAT16格式(一般FAT32的FAT表是从95扇区开始的)，所以在此处填上“06”。

　　(5)在(后面)结论一的第6个字节处填入“FE”，它表示该分区结束磁头号。从硬盘救护箱的顶部可查看到Head=255，表示该硬盘有255个磁头或说是255个面，因为磁头编号是从0开始，所以结束磁头号应为255-1=254，转化成十六进制即为“FE”。

　　(6)再往后应为一个字，写入“7F04”，它表示该分区的结束扇区号和结束柱面号，依然如起始扇区和柱面号一样，结束扇区号只占低六位，结束号占十位。

　　(7)后面的一个双字填写“3F000000”是绝对引导扇区，即63个隐含扇区。硬盘中涉及一种低位在前高位在后的存储数字方式，读出时应对其进行调整。即实际十六进制值为“0000003F”，转换后成为十进制值是63。

　　(8)在结论一的A处也是一个双字，它表示C盘绝对扇区数，具体计算方法可用D区的分区表所在扇区位置减去63扇区，即4192965-63=4192902。再将其转换成十六进制，按低位在前高位在后的存储方式交换得“86FA3F00”。

　　(9)在结论一中的A以后是指向以后分区的链表。“00”这个字节表示下一个分区是不可自举的非活动分区。

　　(10)再往后1个字节也是“00”，它表示下一个分区的起始磁头号。

　　(11)在结论一中的B处是一个字，是指向下一个分区的起始扇区号和柱面号，即把D区分区表的起始扇区和柱面号写过来即可，所以应填入“4105”。

　　(12)在结论一中的C处，“0F”这个字节表示分区类型，通常“0F”代表主DOS分区，“05”代表扩展DOS分区，所以此处应填“0F”。

　　(13)在结论一的D字节处表示下一个分区的结束磁头号，可以从D区的分区表中得出并照抄，即“FE”。

　　(14)在结论一中的E处是一个字，代表下一个分区的结束扇区号和结束柱面号，同样可以从D区的分区表中得出并照抄，即“BF83”。

　　(15)在结论一中的F处为一个双字，是下一个分区的起始扇区位置，按照搜索到的D区分区表所在位置应为4192965，把它转换成十六进制为“003FFAC5”，再按按低位在前高位在后存储格式调整成为“C5FA 3F00”。

　　(16)在结论一中的G处也是一个双字，代表扩展分区的总扇区数，即应将搜索到的D区和E区的扇区数相加，再加上两个63(因每个分区都有63个隐含扇区，也应算在内)，也就是说6152832+63+6152832+63=12305800，再转换成十六进制并按低位在前高位在后排列成为“7EC5 BB00”。

　　以上为0扇区分区表的所有内容，已经推出，现只需按F1键翻到0扇区，再按F5功能键进入编辑状态，把上面推算出来的数字从446字节开始按顺序输入：

　　8001 010006FE 7F043F00

　　000086FA 3F000000 4105 0F FE BF83 C5FA 3F00 7EC5 BB000000

　　A B C D E F G

　　(结论一)

　　然后再在该扇区最后两个字节处写入“55AA”，然后按Ctrl+F10功能键保存后，发现“80"和“55AA”处开始变红并闪烁。现在重新用软盘启动计算机，键入C：回车后已经可以进入，但DIR列表却显示：

　　Invalid media type reading drive C

　　Abort, Retry, Fail?

　　这是63扇区仍为零的原因，再查看D，E分区，均已正常，说明最初的判断和刚刚填写的分区表均为正确的。现在还需使用KV3000/K命令重建0扇区的第一关键字MBR区，把0扇区补充完整，否则即使63扇区正确，硬盘也将无法自启动。方法是将KV3000的A号盘插入软驱，在A:>提示符下键入KV3000/K回车，出现界面后按下C，再按两次“Y”确认即可。现在重新启动，用KV3000的F6功能进入0扇区可以看出已基本正常。

　　二.下面开始重建63扇区：

　　因为前面已经判断出该分区应为FAT16格式，故此处需按FAT16的I/O表格式写入。

　　(1)该扇区的前数3个字节处是一个跳转指令，它可以使启动程序跳转到引导代码，每个硬盘的这几个字节不尽相同，可先写入“EB3C90”。

　　(2)从第4个字节到第11个字节处是一些厂商标识和操作系统的版本号，可暂时不填。

　　(3)(参照结论二)在A的位置是一个字，它表示该硬盘每个扇区包含多少个字节，通常每个扇区都是512字节，把此数转换并调整后即成“00 02”。

　　(4)后面的一个字节处为每个簇的扇区数，簇是数据文件在磁盘上存储的一个基本单位，因硬盘大小不一，所以簇所包含的扇区数也不同(它一定是2的整数倍)，一般来说，此数可通过查看目录区扇区数的方法来确定，这里应填写“40”。(查找目录区的方法下会提到，此数为十六进制数)。

　　(5)结论二中的B处为一个字，表示保留扇区(用于引导DOS等)数，此数可以理解为是从I/O表到FAT表1的相隔扇区数。因为该分区的I/O表向后翻1个扇区即64扇区就是FAT1表的头，故此处是“0001”，按低位在前高位在后写入应为“0100”。

　　(6)再往后的一个字节处是文件分配表的份数，因为FAT表比较重要，且一旦被破坏将很难恢复，所以一般都有两份FAT表，FAT表2为FAT表1的备份，所以填写“02”。

　　(7)结论二中的C处代表该硬盘根目录的项数(即所允许的最大目录项数)，此处占两个字节，一般填入“0200”。

　　(8)结论二中的D处是磁介质类型说明符，硬盘多为“F8”。

　　(9)结论二中的E处表示每个FAT表所占用的扇区数。该数算法是先用KV3000硬盘救护箱的F4搜索字符串功能，查找“BOOTLOG.TXT"文件，这是C盘根目录下的一个文件(也可以搜索其它文件)，即可找到目录区了，然后把这个扇区数记下，为576扇区，因为有两份FAT表，所以该FAT表的扇区数应为(576-64)/2=256，转换成十六进制为“0100h"再交换位以后此处应填入“0001”。

　　(10)结论二中的F处是一个字，表示每磁道(柱面)的扇区数，查看顶部即知Sector=63，也就是说每磁道63个扇区，转换调整为“3F00”。

　　(11)再往后的一个字处为该硬盘磁头数，依然查看顶部显示Head=255，转换成十六进制是“00FFh"，按低位在前高位在后应写为“FF00”。

　　(12)结论二中的G处是双字，表示当前分区前面的隐含扇区数，共有63扇区，故此处应写入“3F000000”。

　　(13)结论二中的H处的双字表示该分区的总扇区数，此数不包含63个隐含扇区，它应该与结论一中的A标志位置处的数字相同，所以照抄过来即“86FA3F00”。

　　现在依然用F5编辑功能将上述数字写入63扇区，并用Ctrl+F10键确认保存：

　　EB3C9000 00000000 00000000 02400100 02000200 00F8 0001

　　A B C D E

　　3F00 FF00 3F000000 86FA3F00

　　F G H

　　(结论二)

　　现在再用引导盘重新启动计算机，引导至DOS操作系统，查看各分区情况，发现均已正常，而且数据都在。此时我们还需用相同版本的WINDOWS98启动盘启动并执行SYS A：C：回车来传入系统文件，使WINDOWS98系统可以正常启动。(这样I/O表即可补充完整)。

　　以上把主引导扇区0扇区及I/O表63扇区已重建完毕，重新启动计算机后发现硬盘已可以自引导并进入WINDOWS98系统，一切数据文件恢复正常。

　　注：以上是以一个C区为FAT16分区格式的硬盘为例的修复过程，有一定的局限性，仅供参考，而且因为硬盘出现的问题是多种多样的，应对具体问题具体分析。

在当今商业环境下，网络宕机就意味着公司将遭受巨大经济损失，而客户也会难以接受。做好灾难恢复准备的公司能够更好地维持运营、保住客户并避免长期损害。要在紧要关头进行灾难恢复，必须具备三个条件：人员、数据（包括数据处理所需的硬件和软件）和转移位置。最近Dynamic Markets公司为VERITAS所做的、对全球850多个IT 专业人员的独立调查显示：47%的公司把与潜在灾难相关的金融风险作为计算灾难恢复成本的主要标准。被调查的IT专业人员估计，恐怖主义袭击（他们认为这是公司的最大成本支出）所造成的损失和恢复的平均成本为1.15亿美元。

    日前，维尔软件公司（VERITAS）宣布推出IT公司灾难恢复五步操作法。

    1.联系相关人员。每个公司都需要有一种方法来迅速召集相关人员到灾难恢复现场。无需电话线或移动服务设备的通信方法，如卫星电话就是一个很好的选择。这种方法可以为不直接参与数据恢复的员工提供一条热线，使之能够获得最新信息，而您则可以集中精力完成手头的任务。

    2.快速找到您的灾难恢复计划 。在远离办公地点的地方（如车上、家里甚至公文包）保存灾难恢复计划副本，并将副本提供一份给您的非现场存储供应商。此次调查显示，60%以上的公司仅在某个位置保存灾难恢复计划?D?D即主要数据中心，一旦主要数据中心不能用，就会遇到麻烦。

    3.联系您的供应商，寻求他们的帮助。许多公司从来没有实际施行过灾难恢复计划。事实上，此次调查显示，只有三分之一的公司实际进行过此类实施。如果您面临实际灾难恢复计划施行，请致电专家寻求援助。如果您要从磁带上恢复数据，您的非现场灾难恢复存储供应商应当把磁带送到恢复现场，以便您的备份软件供应商能够帮助恢复存档数据。

    4.调用您的次级站点。许多公司订购了一种次级灾难恢复“热站点”，可以在业务中断时与其他用户共同使用。重大事故发生时，如美国东北部最近发生的大停电，热站点可以迅速替补，确保尽快电话通告灾难的发生。为了确保备用站点的可用性，许多公司配备了他们自己的次级灾难恢复数据中心。采用VERITAS公司提供的高可用性灾难恢复软件，可以将业务从受灾站点切换到次级站点，而不会中断业务，这有助于将灾难对员工、客户和合作伙伴的影响降至最低。

    5.确定紧急次级站点。如果次级站点无法使用或者出现故障，就立刻想别的办法，即使其他所有措施都不能用，宾馆舞厅或会议中心配备的高带宽连接和空调设备也能够为灾难恢复提供足够的资源。

　　一、恢复的意义
　　当我们使用一个数据库时，总希望数据库的内容是可靠的、正确的，但由于计算机系统的
故障（硬件故障、网络故障、进程故障和系统故障）影响数据库系统的操作，影响数据库中数
据的正确性，甚至破坏数据库，使数据库中全部或部分数据丢失。因此当发生上述故障后，希
望能重新建立一个完整的数据库，该处理称为数据库恢复。恢复子系统是数据库管理系统的一
个重要组成部分。恢复处理随所发生的故障类型所影响的结构而变化。
　　二、恢复的方法
　　IMPORT方法：
　　利用IMPORT，将最后一次EXPORT出来的数据文件IMPORT到新的数据库中，这种方式可以将
任何数据库对象恢复到它被导出时的状态，此后的变化将无法挽回。IMPORT的命令可以交互式
进行，各参数的具体含义见ORACLE EXP/IMP参数详解。这种方式适用于没有采用archive 模式
　　安全的恢复方法：
　　如果数据库运行在archive 模式下，那么一旦数据库损坏则可以通过冷备份(热备份)和归
　　数据库控制文件恢复（假设所有控制文件均被破坏）：
　　数据库基于文件系统： 利用操作系统的tar、cp等命令即可。
　　数据库基于裸设备：dd if=$ORACLE_BASE/con.bak of=/dev/rdrd/drd1 seek=12
　　数据库数据文件恢复
　　数据及索引表空间、系统表空间的恢复：
　　回拷相关的数据库文件和该数据文件备份以来所有生成的所有逻辑日志文件并执行如下命
令：

　　数据库临时文件和回滚表空间的恢复：简单地offline drop 并重建即可
　　注意：如果数据库不运行在archive 模式下，则恢复只能恢复到上次备份时的状态。 关
于archive 模式的设定，以及备份的相关技术，参见ORACLE数据库备份技术
　　三、ORACLE表空间恢复方案
　　（一）、户表空间
　　错误现象：
　　在启动数据库时出现ORA-01157，ORA-01110或操作系统级错误例如ORA-07360，在关闭数
据库（使用shutdown normal或shutdown immediate） 时将导致错误ORA-01116，ORA-01110以
　　解决：
　　以下有两种解决方案：
　　方案一、用户的表空间可以被轻易地重建
　　即最近导出的对象是可用的或表空间中的对象可以被轻易地重建等。在这种情况下，最简
单的方法是offline并删除该数据文件，删除表空间并重建表空间以及所有的对象。

　　重建表空间及所有对象。
　　方案二、用户的表空间不能够被轻易地重建
　　在大多数情况下,重建表空间是不可能及太辛苦的工作.方法是倒备份及做介质恢复.如果
您的系统运行在NOARCHIVELOG模式下，则只有丢失的数据，在online redo log中方可被恢复
　　步骤如下：
　　1)Restore the lost datafile from a backup

　　如果 CHANGE# 大于最小的FIRST_CHANGE#则数据文件可以被恢复。
　　如果 CHANGE# 小于最小的FIRST_CHANGE#则数据文件不可恢复。恢复最近一次的全备份或
采用方案一。
　　5)svrmgrl> recover datafile filename;
　　6)确认恢复成功 　　7)svrmgrl> alter database open resetlogs;
　　只读表空间无需做介质恢复，只要将备份恢复即可。唯一的例外是：
　　表空间在最后一次备份后被改为read-write 模式
　　表空间在最后一次备份后被改为read-only 模式
　　在这种情况下，均需进行介质恢复。
　　（二）、临时表空间
　　临时表空间并不包含真正的数据，恢复的方法是删除临时表空间并重建即可。
　　（三）、系统表空间
　　如果备份不可用，则只能采用重建数据库的方法
　　（四）、回滚表空间
　　有两种情况：
　　1、数据库已经完全关闭（使用shutdown immediate或shutdown命令）
　　1) 确认数据库完全关闭
　　2) 修改init.ora文件,注释"rollback-segment" 　　3) svrmgrl> startup restrict mount
　　4) svrmgrl> alter database datafile filename offline drop;
　　5) svrmgrl> alter database open;
　　基于出现的结果："statement processed" 转(7)；"ORA-00604,ORA-00376,ORA-01110"转
(6)
　　6) svrmgrl> shutdown immediate
　　8) 重建表空间及回滚段 　　9) svrmgrl> alter system disable restricted session;
　　10) 修改init.ora文件
　　2、数据库未完全关闭（数据库崩溃或使用shutdown abort命令关闭数据库）
　　1) 恢复备份 　　2) svrmgrl> startup mount
　　3) svrmgrl> select file#,name,status from v$datafile;
　　svrmgrl> alter database datafile filename online;
　　4) svrmgrl> select v1.group#,member,sequence#,first_change# from v$log v1,v$logfile v2 where v1.group#=v2.group#;
　　5) svrmgrl> select file#,change# from v$recover_file; #参见方案2-4
　　6) svrmgrl> recover datafile filename;
　　7) svrmgrl> alter database open;
　　3、数据库处于打开状态
　　1) 删除回滚段和表空间
　　2) 重建表空间和回滚段
　　（五）、控制文件恢复
　　1．所有的控制文件均被破坏
　　将备份的控制文件拷贝至原目录下，对于RAW DEVICE（裸设备），则：dd if='con.bak'
　　2．并非所有的控制文件均被破坏，用其他的控制文件启动数据库
　　（六）、数据块及其中数据的挽救
　　现象：执行ORACLE操作时出现ORA-01578错误
　　分析：ORA-1578错误是当ORACLE认为一个数据块可能被破坏而发生的，通常引起该错误的
　　I/O的硬件或firmware损坏
　　操作系统I/O或cache故障
　　内存或页交换出错
　　部分数据文件被覆盖
　　试图访问未格式化块
　　磁盘修复
　　其他原因
　　解决步骤：
　　查看log以及trace文件，检查是否有其他错误发生
　　定位错误： 　　sql>select * from v$datafile where file#=;
　　sql>select owner,segment_name,segment_type from dba_extents where file_id= and between block_id and block_id+blocks-1;
　　基于返回的segment_type：
　　segment类型为temporary或cache或无返回值，检查SQL语句是否正确。
　　segment类型为rollback segment，则数据块需要恢复。
　　segment类型为index，检查其所在的表。重建索引即可。 　　sql> select owner,table_name from dba_tables where cluster_name = name_of_segment
　　仍然出现1578错误，数据库需要恢复。
　　segment类型为表，拯救表中的数据。
　　分析一个实体是否有永久性数据破坏 　　sql> analyze table table.name validate structure cascade;
　　sql> analyze table clustername validate structure cascade;
　　硬件错误的恢复
　　数据库运行在ARCHIVE模式下
　　OFFLINE相应的数据文件
　　拷贝备份的数据文件
　　rename the datafile to new location
　　recover the datafile using archive log
　　online数据文件
　　数据库运行在非ARCHIVE模式下
　　OFFLINE相应数据文件
　　拷贝备份的数据文件，rename the datafile and online it
　　拯救表中数据 　　例如：sql>select * from bigemp;
　　ERROR：ORA-01578: ORACLE DATA block corrupted (file#8,block#8147) ORA-00110:
data file 8: ‘/oracle/usr714.dbf’ … … corrupt file id : 8=8(hex) corrupt
block id : 8147=1fd3(hex) first rowid in the corrupt block: 0000.1fd3.0000.0008
last rowid in the corrupt block: 0000.1fd2.7fff.0008 first rowid affer this
block: 0000.1fd4.0000.0008
　　sql > create table temp as select * from bigemp where 1=2;
　　在ORACLE 7.1以前版本，rowid range scan不存在时，可以通过索引达到以上相同的目的
　　四、后记
　　ORACLE的备份恢复技术可以说是博大精深，我所了解的只是很少的一部分，而且还不是很
透彻，希望这几篇文章对大家能有所帮助，也欢迎大家将自己遇到的备份和恢复的问题告诉我
，我将它整理起来，发表在这里，供所有有兴趣做的DBA朋友和数据管理员参考，也许您的举
　　同时，我还要提醒所有的朋友，备份是非常、非常、非常、非常、非常、非常、非常、非
常、非常。。。重要的，有条件的话一定要采用ARCHIVE模式，否则，可能出了问题，哭都哭
　　最后祝福大家永远不会用到这篇文章的内容。

      现在选择IDE磁盘阵列卡(IDE RAID卡)来确保数据安全的人越来越多，如何正确使用IDE RAID卡也是个学问。下面我们就以采用HPT370A/372控制芯片的Rocket100 RAID卡为例来给大家做些讲解常见故障与技巧。

　　安装需知

　　先找一个空闲的PCI插槽将该卡插进去并将硬盘用硬盘线和该卡安装连接好，安装完适配卡后，在启动计算机的过程中，你会看到该适配卡已成功安装并被系统识别。而在系统开机时，其控制器的BIOS会显示硬盘状态的信息，按CTRL+H即可进入结构非常清楚的设置菜单，在这里你可以设定磁盘阵列:两个硬盘可以选择条带模式(RAID 0)和镜像模式(RAID 1)，有三块硬盘的话只能选跨越扩充或条带模式，而四块就可以选跨越模式、条带模式或条带结合镜像模式(RAID 0+1)，而选用RAID 1的话硬盘必须进行同步化。

　　常见安装故障排除

　　当Rocket100 RAID卡被识别后，板上BIOS开始检测连接设备。请注意屏幕上出现的设备，如果所连接设备全部被正确扫描出，则说明设备已正确连接并被系统识别，再安装好驱动之后你即可使用RAID功能了。而如果其中有的设备没有被识别出，你可打开机箱，将所连接设备的电源线是否插牢，必要时换一个电源插头试一试;所连接设备的数据线是否正确连接并已插牢，必要时换一根数据线试一试;如果一根数据线上接有两个设备，请确认这两个设备的主从跳线是否设置冲突(一根数据线上的两个设备必须为一主一从)。

　　硬盘容量的选择

　　考虑到系统的操作性能及磁盘的利用率，我们建议你最好使同样容量的硬盘。但你如果一定要用不同容量的磁盘，需要注意的是整个阵列的容量要由该阵列中最小容量的硬盘决定，例如在由3个磁盘组成的RAID 0阵列中，总容量等于最小磁盘的容量的3倍。在RAID 1阵列中，目标盘的容量不能小于源盘的容量。该阵列的总容量就等于最小磁盘的容量。但是JBOD是个例外，两个或更多的不同容量的硬盘可以组合起来，形成一个逻辑单盘。

　　BIOS设置须知

　　IDE RAID卡是即插即用设备，所以，你不必改变系统CMOS。系统会自动指出中断及端口的地址。而在CMOS设置中将所有设备处于none或unstalled状态时，即可将IDE RAID卡设为启动卡;或将SCSI设备调为启动序列的第1位，也可将RAID卡设为启动卡。

　　RAID损坏了怎么办

　　如果一个RAID级别被破坏了，可以按以下操作进行检查:先关闭计算机的电源，检查硬盘电源的连接，以及数据线是否与硬盘和RAID控制卡连接正常再重新开机;如果以上操作仍不能解决问题，可能是硬盘的问题，对于RAID 1和RAID 0+1，可以用一个新的硬盘将已经被破坏的硬盘上的数据进行备份，所有的数据都不会丢失的。对于RAID 0和JBOD，必须先删除原有的RAID级别，再进行RAID创建，但要注意，此动作会使硬盘的所有数据丢失，所以，对RAID 0和JBOD，请务必经常对数据进行备份。

　　因为NTFS文件系统与FAT和FAT32文件系统完全不同，数据恢复必须采用不同的方法。然而，也有例外，这篇教程的最后一部分将讨论无论任何系统格式下都能运行的最终(last ditch)恢复技术，但是现在我们要讨论的是NTFS文件系统从一个数据恢复点是如何工作的。

　　如果你用Google搜索一下NTFS数据恢复技术，你可能得到最多的链接是关于卖数据恢复产品的网站。这是因为NTFS被设计可以自己执行数据恢复，而不需要使用第三方数据恢复软件或者操作。在这个工作中有两个主要技术来实现这个功能:簇重映射(cluster remapping)和事务日志(transaction logging)。

簇重映射

　　簇重映射是通过自动方式把数据从硬盘包含坏的分区的簇上自动移动到良好的簇的技术。簇重映射的结构不用，取决于包含这个坏的扇区的卷是否是容错的，而且坏的扇区在读写过程中是否被发现。

　　让我们讨论一下在没有容错的卷上写入的操作，当数据被写入NTFS卷，操作系统在写的操作时把检查扇区做为确认进程的一部分，如果操作系统检测到一个扇区是损坏的。Windows标记整个簇都是损坏的，这样它在将来就不往这个簇上存储数据。(这是因为簇不能被再细分)数据将被存储到良好的簇内，这样不会有数据损失。

　　但是如果这个坏的扇区在读取时候被检测到，情况就不一样了。操作系统将返回一个读取错误的消息来响应被数据请求。这里有几种不同的理论关于接下来如何解决这个问题。一些资料表示，一旦这个读取错误发生，Windows把这个扇区和其中的簇标记为损坏，所以簇其中的数据将完全丢失。另外一些资料说，如果这个数据的一部分能读出来，Windows在标记这个扇区为损坏之前，把这些数据移到另一个簇。如果有读者知道关于权威地描述这个问题的微软资料，麻烦告知我(tt.harte@gmail.com)。

• 电子仓库可以支持企业将每天的备份通过电子方式传送到恢复设施上，在灾难发生时就可以缩短传送的时间。通常，生产服务器是通过网络与恢复设施上的磁带连接的，但有时也需要中间主机。此外，根据备份数据的数量，可能还需要按需网络服务(短期内的高带宽)或直接网络连接。电子仓库能缩短RTO，但它不影响RPO。
• 电子日志通过电子方式持续或按预定间隔时间传送自上次备份以来出现的数据库或文件系统变化。这通常是通过专用网络实现的。该网络将日志传送至恢复设施上的一个专用服务器，然后再传送至磁带。电子日志能缩短RPO，因为数据在中断事故发生以后很快就能恢复。它还能缩短将日志传送到恢复设施上所需的时间，从而缩短了RTO。
• 影化能创建数据库或文件系统的复制品，通常采取的手段是持续捕捉变化并将这些变化应用于恢复站点。影化是一个异步流程，因此需要的网络带宽比同步镜像的少，而且比日志所需的带宽大或者与之持平，但它需要的硬件容量要大一些，因为它需要不断地应用功能。RTO被大幅缩短了(通常在1～8小时内，取决于适用日志的滞后时间)，而RPO则与最后一次接收和应用日志的时间接近。
• 镜像能创建数据库或文件系统的复制品，采取的手段是将灾难恢复设施上的变化与主站点上的变化前后应用或同步应用。因此，RTO将被缩短，从20分钟到几个小时不等。而RPO也被缩短到只有未完成的工作丢失。带宽太小或延误过长将削弱生产系统的性能。备份站点上还需要使用专用硬件(如服务器或磁盘子系统，或者两种都需要)。
• 几个物理站点之间的负载平衡对于非事务型应用而言很常见。通常，事务型应用都放置在一个站点上，而热备份则放置在其它地方，这降低了恢复的复杂性，而且为冲突的解决提供了机会。
• 热备份系统，如广域群集器，能提供时间最快的可恢复性，通常从几分钟到一小时不等，因为恢复系统配备了影化或镜像功能以及热备份应用环境，由运行应用所需的能力构成。此外，自动化灾难检测和应用恢复能力是减少宕机时间的必要条件。如果发生了灾难性故障或站点灾难，那么热备份系统将自动检测故障并开始恢复流程，包括重新启动应用和驱动网络接入。

    根据使用的应用、平台和高可用性方法的不同，企业在24小时以内成功恢复运行需要支出高额要想选择正确的技术和支出水平，企业必需了解业务流程宕机带来的直接和间接费用，这通常是通过业务影响分析计算得出的。了解每个业务流程的可以接受的技术支持限制有助于企业缩小恢复方案的选择范围。
  　　
    行动方案
  　　
    虽然快速RTE 恢复费用昂贵，但其它方案?D在3或4天内恢复?D?D可能会威胁到企业的生存。企业应利用商务影响分析来帮助评估恢复投资回报。
  　　
    对于1类应用服务和2类应用服务(RTO 和RPO 较短)，可以使用多站点结构。通常，新的RTE应用服务开始时采用的是单一站点结构，并随着风险的加大而转向多个站点。多站点的应用结构设计较为复杂(例如设计中必须包含负载平衡、数据库分区、数据库复制和站点同步化等内容)。对于非事务处理型应用而言，多个站点可同时运行，将用户与最近的站点或使用量最小的站点连接。
  　　
    为了简化复杂性，大多数事务处理型应用都将数据库或磁盘复制在另一个站点上，但在灾难没有发生时，备用数据库是空闲的。转换至备用站点通常需要15～30分钟。有些企业倾向于将数据库分区，在站点之间分摊事务处理负载，并且将用于决策支持和报告的数据综合在一起。这将降低站点中断造成的影响，使它只能影响到一部分用户。其他企业则比较倾向于更加复杂的结构，在这些结构中，站点之间具有双向复制能力，能保持单一数据库影像。
  　　
    所有应用服务都需要在灾难恢复战略中包含端-端数据备份和脱机存储。通常，灾难恢复结构将实施指定时间复制，以驱动同步备份和恢复(涉及许多系统)。3类应用服务和4类应用服务通常通过备用站点上的磁带进行恢复。
  　　
    外包决策
  　　
    在定义了灾难恢复服务级以后，企业应评估灾难恢复战略：

• 1 类服务面向关键的应用，其RTO和RPO从几分钟到1小时或2小时不等。
• 2 类服务提供的RPO为4小时，RTO为1天以内?D?D能满足那些希望将数据影化到恢复设施上的企业的要求。
• 3 类服务提供标准磁带恢复――这些服务通常是外包的。
• 4 类服务提供的恢复时间较长，可以使企业通过签订快速装运服务合同来降低费用。

    业务连贯性流程中的很多功都不能外包，但许多设备和劳动力可以外包。