九桥软件

　数据越来越突出地成为社会正常运作的核心。对于一个企业来讲，数据更是影晌其生存和发展的关键，各行业的用户和企业对网络应用和数据信息的依赖日益强烈，使得突发性灾难如火灾，洪水，地震或者恐怖事件对整个企业的数据和业务生产会造成重大影响，所以如何保证在灾难发生时，企业数据不丢失，保证系统服务尽快恢复运行成为人们关注的话题，容灾技术日益成为各个行业关注的焦点。
　　
　　随着信息化建设的不断发展，人们已经越来越意识到数据的重要性。数据的价值体现有两个前提，既数据的安全和可用，这就要求数据信息系统具有高可用性。基于这种认识，各种存储技术被快速发展起来，保证数据的安全性有专业存储系统和备份解决方案。
　　
　　灾难备份是今天的一个重要的课题，如何保证数据中心在经历一定级别的故障和灾难后能够尽快恢复运营，对干此务连续性较为敏感的企业是至关重要的。
　　
　　一、基本概念
　　
　　容灾，就是在灾难发生时，在保证生产系统的数据尽量少丢失的情况下，保持生存系统的业务不间断运行。
　　
　　1、容灾的评价指标
　　
　　现在工业界都以数据丢失量和系统恢复时间作为标准，对某个容灾系统进行评价，公认的评价标准是RPO和RTO。
　　
　　RPO（RecoveryPointObjective）:恢复点目标，以时间为单位，即在灾难发生时，系统和数据必须恢复到的时间点要求。RPO标志系统能够容忍的最大数据丢失量，系统容忍丢失的数据量越小，RPO的值越小。
　　
　　RTO(RecoveryTimeObjective):恢复时间目标，以时间为单位，即在灾难发生后，信息系统或业务功能从停止到必须恢复的时间要求。RTO标志系统能够容忍的服务停止的最长时间。系统服务的紧迫性要求越高，RTO的值越小。
　　
　　RPO针对的是数据丢失，RTO针对的是服务丢失，两者没有必然的联系，并且两者的确必须在进行风险分析和业务影响分析之后根据业务的需求来确定。
　　
　　2、容灾的分类
　　
　　由于容灾包含的内容比较广泛，对容灾的分类也可以从多个方面进行。总的来讲，可以从容灾的范围和容灾的内容来区分。
　　
　　从容灾的范围讲，容灾可以分成本地容灾，近距离容灾和远距离容灾。这三种容灾能容忍的灾难是不相同的，采用的容灾技术也是不同的。
　　
　　从容灾的层次讲，容灾又可以分成数据容灾和应用容灾，本质上讲，这两种容灾是密不可分的。数据容灾是应用容灾的基础，没有数据的一致性，就没有应用的连续性，应用容灾也是无法保证的。数据容灾是指建立一个备用的数据系统，该备用系统对生产系统的关键数据进行备份。
　　应用容灾则是在数据容灾之上，建立一套与生产系统相当的备份应用系统。在灾难发生后，将应用迅速切换到备用系统，备份系统承担生产系统的业务运行。
　　
　　二、容灾技术选择
　　
　　容灾系统的建设需要多种技术相互配合，选择容灾技术的原则和策略是容灾系统建设的关键。
　　
　　1、容灾技术选择要素
　　
　　容灾技术的选择，是一个以业务容灾需求为核心，多种因素综合权衡的过程。容灾技术选择所需考虑的因素如图1：
　　
　　1)业务分析结果
　　
　　容灾系统建设应根据业务分析结果选择合适的容灾技术并确定具体的实现策略，以满足业务恢复时相应的RTO、RPO指标。
　　
　　2)业务关联程度
　　
　　在进行容灾技术选择时，需要考虑到核心业务系统各种业务之间的关联关系。业务关联紧密，数据的藕合程度高，可能会造成所有关联的业务都要采用同一种容灾技术，业务关联松散，数据的藕合程度低，可能会针对不同的业务要求进行区分，分别采用不同的容灾技术。
　　
　　3)系统现状
　　
　　核心业务系统容灾技术必须充分考虑与现有系统的配合。现有核心业务系统的应用分布、应用的实现方式、硬件设备平台的种类、存储数据量的大小、IO吞吐量的大小等，都会对容灾技术的选择产生影响。
　　
　　4)技术成熟度
　　
　　容灾系统必须采用成熟可靠的技术，保证系统特续，稳定的运行。该技术应具有类似于电信业务运营支撑系统容灾建设的成功案例，不能由于技术手段的不成熟或不稳定而增加核心业务系统新的风险。
　　
　　5)容灾系统环境
　　
　　核心业务系统容灾技术必须考虑生产中心与容灾中心之间的距离，网络环境等因素，不同的技术对距离，网络带宽的要求会有所不同。
　　
　　6)管理维护难度
　　
　　不同的容灾技术对管理维护的要求各不相同，在同等条件下，应采用易于管理和维护的容灾技术。
　　
　　7)成本分析
　　
　　不同的容灾技术对软硬件投资，实施维护成本的要求各不相同，在同等条件下，应采用总体成本最小的容灾技术

未来几年容灾市场将保持增长态势（趋势展望）

目前，中国容灾市场的应用呈现出较强的行业特性，其中金融行业包括银行、保险、证券等，此类客户是目前容灾市场最大的收入贡献者，占市场容量的近42.1％，随着金融行业对于风险控制的进一步加强和深化，这一格局还将延续。未来几年内容灾市场仍会保持增长态势，2008至2013年的复合增长率将会达到20.7％。

IDC近日发布调研报告《中国业务连续性与灾难恢复市场2008－2012年预测与分析》，中国容灾市场经过近几年的探索，已经以快速增长的势头正式步入实践和发展阶段。2008年中国容灾解决方案市场（软件及服务）规模达到了4.8亿美元，比2007年增长29.9％。

IDC中国软件[20.95 0.48%]与服务研究部高级分析师杨挺说：“很多政府、金融、电信等行业的企业关键业务系统已经高度信息化，并且应用数据和系统在一定程度上完成了集中，因此保持业务运行的连续性和信息的安全性已成为他们需要考虑的问题；另一方面，中国的IT服务发展受政策的推动作用非常明显，国家相关部门对加强信息安全保障工作十分重视，先后出台了多项有关信息安全保障的措施及规范，对国家重要行业的灾备建设进行了大力支持。政策以及规范化进程的推进无疑对容灾市场起到了推波助澜的作用。”

9.11恐怖袭击以及东南亚海啸和去年发生在中国南方雪灾和汶川地震，这些灾难性事件让更多的受灾企业在系统、信息、业务方面损失惨重，这已经给中国企业敲响了警钟，使他们认识到保证业务连续性的必要。

报告显示，目前中国容灾市场的应用呈现出较强的行业特性，其中金融行业包括银行、保险、证券等，此类客户是目前容灾市场最大的收入贡献者，占市场容量的近42.1％，随着金融行业对于风险控制的进一步加强和深化，这一格局还将延续。另外，随着《信息安全技术信息系统灾难恢复规范》等标准的颁布，电信、政府、交通、能源等行业的容灾需求潜力不可小觑。

虽然不容乐观的国际经济大环境影响到了一些产业的发展前景，但有效的业务连续性及灾难恢复系统往往关系到企业核心业务能否连续运行，甚至关系到企业的正常经营，容灾解决方案需求相对比较刚性。IDC预测，未来几年内容灾市场仍会保持增长态势，2008至2013年的复合增长率将会达到20.7％。

记者了解到，与传统的基础架构解决方案不同，容灾解决方案中服务超过软件产品占据更大的比重，其关键在于容灾与业务的结合更为紧密，融入了更多的管理理念。对于企业的容灾需求，形成DRP（灾难恢复规划）和BCP（业务连续性规划）咨询规划，以及容灾中心高效的运营维护，定期的容灾演练，完善灾难恢复的规范和管理流程，这些都与业务连续性及灾难恢复系统的实际效用息息相关。

IDC调研显示，业务连续性及灾难恢复系统的建设和运营管理一般有自建和外包的模式，外包模式在一定程度上减少了容灾系统建设需要的资金及技术资源的先期投入，对于中小型企业是一个可行的选择。相对来说，大型的企业通常较倾向于自建（或与外部服务商合作建设）容灾系统。“因此企业在业务连续性及容灾系统建设过程中也可以更有针对性，优先选择关键业务系统及数据进行灾备建设，同时对不同优先级别的应用系统可以考虑采用不同的容灾建设模式。整体IT信息产业包括容灾都在向社会化服务的方向发展，在企业政策允许以及风险可控的范围内，选择性的容灾外包不失为一种行之有效的降低初期成本的模式。”杨挺补充道。

　　911恐怖袭击以及东南亚海啸，以及不久前发生在中国的南方雪灾和汶川地震，这些灾难性事件仍然历历在目，人们意识到突发性的安全威胁其实离我们并不遥远。已经完成容灾系统建设的企业不禁庆幸自己的先知先觉与危难意识，而更多的受灾企业则在系统、信息、业务方面损失惨重，这些已经给中国的企业敲响了警钟，使他们认识到保证业务连续性的必要。
　　
　　目前在中国数据中心容灾市场的应用呈现出较强的行业特性，其中金融行业包括银行、保险、证券等，此类客户是目前容灾市场最大的收入贡献者，占市场容量的近42.1％，随着金融行业对于风险控制的进一步加强和深化，这一格局还将延续。另外，随着《信息安全技术信息系统灾难恢复规范》等标准的颁布，电信、政府、交通、能源等行业的容灾需求潜力不可小觑。
　　
　　虽然不容乐观的国际经济大环境影响到了一些产业的发展前景，但有效的业务连续性及灾难恢复系统往往关系到企业核心业务能否连续运行，甚至关系到企业的正常经营，需求相对比较刚性。就好像军队对于国家是“养兵千日，用兵一时”，但其存在的必要性在于保证国家的安全，正所谓是：“兵者，国之大事也，死生之地，存亡之道，不可不察也”。IDC预测，未来几年内容灾市场仍会保持增长态势，2008至2013年的复合增长率将会达到20.7％。

　　
　　与传统的基础架构解决方案不同，容灾解决方案中服务超过软件产品占据更大的比重，其关键在于容灾与业务的结合更为紧密，融入了更多的管理理念。对于企业的容灾需求，形成DRP（灾难恢复规划）和BCP（业务连续性规划）咨询规划，以及容灾中心高效的运维，定期的容灾演练，完善灾难恢复的规范和管理流程，这些都与业务连续性及灾难恢复系统的实际效用息息相关。
　　
　　业务连续性及灾难恢复系统的建设和运营管理一般有自建和外包的模式，外包模式在一定程度上减少了容灾系统建设需要的资金及技术资源的先期投入，对于中小型企业是一个可行的选择。相对来说，大型的企业通常较倾向于自建（或与外部服务商合作建设）容灾系统。因此企业在业务连续性及容灾系统建设过程中也可以更有针对性，优先选择关键业务系统及数据进行灾备建设，同时对不同优先级别的应用系统可以考虑采用不同的容灾建设模式。整体IT信息产业包括容灾都在向社会化服务的方向发展，在企业政策允许以及风险可控的范围内，选择性的容灾外包不失为一种行之有效的降低初期成本的模式。

我国容灾市场经过近几年的探索，已经以快速增长的势头正式步入实践和发展阶段。IDC日前发布的《中国业务连续性与灾难恢复市场2008－2012年预测与分析》报告显示，2008年中国容灾解决方案市场（软件及服务）规模达到了4.8亿美元，比2007年增长了29.9％。
IDC中国软件与服务研究部高级分析师表示，很多政府、金融、电信等行业的企业关键业务系统已经高度信息化，并且应用数据和系统在一定程度上完成了集中，因此保持业务运行的连续性和信息的安全性已成为他们需要考虑的问题；另一方面，中国的IT服务发展受政策的推动作用非常明显，国家相关部门对加强信息安全保障工作十分重视，先后出台了多项有关信息安全保障的措施及规范，对国家重要行业的灾备建设进行了大力支持。政策以及规范化进程的推进无疑对容灾市场的发展起到了推波助澜的作用。
去年发生在我国的南方雪灾和汶川地震，使人们意识到突发性的安全威胁其实离我们并不遥远。已经完成容灾系统建设的企业不禁庆幸自己的先知先觉与危难意识，而更多的受灾企业则在系统、信息、业务方面损失惨重，这些已经给我国的企业敲响了警钟，使他们认识到保证业务连续性的必要。
虽然不容乐观的国际经济大环境影响到了一些产业的发展前景，但有效的业务连续性及灾难恢复系统往往关系到企业核心业务能否连续运行，甚至关系到企业的正常经营，因此容灾市场需求不会减少。就好像军队对于国家是“养兵千日，用兵一时”，但其存在的必要性在于保证国家的安全，正所谓“兵者，国之大事也，死生之地，存亡之道，不可不察也”。IDC预测，未来几年内容灾市场仍会保持增长态势，2008至2013年的复合增长率将会达到20.7％。
目前，业务连续性及灾难恢复系统的建设和运营管理一般有自建和外包两种模式，外包模式在一定程度上减少了容灾系统建设需要的资金及技术资源的先期投入，对于中小型企业是一个可行的选择。相对来说，大型的企业通常较倾向于自建（或与外部服务商合作建设）容灾系统。因此，企业在业务连续性及容灾系统建设过程中也可以更有针对性，优先选择关键业务系统及数据进行灾备建设，同时对不同优先级别的应用系统可以考虑采用不同的容灾建设模式。整体IT信息产业包括容灾都在向社会化服务的方向发展，在企业政策允许以及风险可控的范围内，选择性的容灾外包不失为一种行之有效的降低初期成本的模式。
与传统的基础架构解决方案不同，容灾解决方案中服务软件产品占据更大的比重，其关键在于容灾与业务的结合更为紧密，融入了更多的管理理念。业务连续性及容灾解决方案包括数据管理、存储管理、系统管理、存储复制等软件产品，以及与容灾相联系的咨询、系统集成、管理服务。对于企业的容灾需求，形成DRP（灾难恢复规划）和BCP（业务连续性规划）咨询规划，以及容灾中心高效的运维，定期的容灾演练，完善灾难恢复的规范和管理流程，这些都与业务连续性及灾难恢复系统的实际效用息息相关。
目前，我国容灾市场的应用呈现出较强的行业特性，其中金融行业是目前容灾市场最大的收入贡献者，占市场容量的近42.1％，随着金融行业对于风险控制的进一步加强和深化，这一格局还将延续。另外，随着《信息安全技术信息系统灾难恢复规范》等标准的颁布，电信、政府、交通、能源等行业的容灾需求潜力不可小觑，我国容灾市场的规模将会继续高速增长。

镜像是在两个或多个磁盘或磁盘子系统上生成同一个数据的镜像视图的信息存储过程，一个叫主镜像系统，另一个叫从镜像系统。按主从镜像存储系统所处的位置可分为本地镜像和远程镜像。本地镜像的主从镜像存储系统是处于同一个RAID阵列内，而远程镜像的主从镜像存储系统通常是分布在跨城域网或广域网的不同节点上。
远程镜像又叫远程复制，是容灾备份的核心技术，同时也是保持远程数据同步和实现灾难恢复的基础。它利用物理位置上分离的存储设备所具备的远程数据连接功能，在远程维护一套数据镜像，一旦灾难发生时，分布在异地存储器上的数据备份并不会受到波及。
远程镜像按请求镜像的主机是否需要远程镜像站点的确认信息，又可分为同步远程镜像和异步远程镜像。
当企业的核心流程由于灾难的发生而无法正常进行时，将会给企业造成一定的损失。这种损失可能是可以量化的，例如单据的丢失、计算的错误而导致的直接损失；也可以是无形的损失，例如客户满意度及竞争优势的丢失。通过对可量化和不可量化损失的综合考虑，得出各种核心业务流程由于灾难受损的可容忍程度及损失的决策依据。体现在IT系统上，主要通过以下3个指标来衡量：①数据恢复点目标（RPO）：体现为该流程在灾难发生后恢复运转时数据丢失的可容忍程度；②恢复时间目标（RTO）：体现为该流程在灾难发生后，需要恢复的紧迫性（即：需要多久才能够得到恢复）；③网络恢复目标（NRO）：即营业网点什么时候才能通过备份网络与数据中心重新恢复通信的指标。
如果单单就RPO和RTO而言，同步远程镜像的得分无疑是最高的。同步远程镜像（同步复制技术）是指通过远程镜像软件，将本地数据以完全同步的方式复制到异地，每一个本地的I/O事务均需等待远程复制的完成确认信息，方予以释放。同步镜像使远程拷贝总能与本地机要求复制的内容相匹配。当主站点出现故障时，用户的应用程序切换到备份的替代站点后，被镜像的远程副本可以保证业务继续执行而没有数据的丢失。换言之，同步远程镜像的RPO值为零（即：不丢失任何数据），RTO也是以秒或分为计算单位。不过，由于往返传播会造成延时较长，而且本地系统的性能是与远程备份设备直接挂钩的，所以，同步远程镜像仅限于在相对较近的距离上应用，主从镜像系统之间的间隔一般不能超过160公里（约合100英里）。
同步远程镜像（同步复制技术）是指通过远程镜像软件，将本地数据以完全同步的方式复制到异地，每一本地的I/O事务均需等待远程复制的完成确认信息，方予以释放。同步镜像使远程拷贝总能与本地机要求复制的内容相匹配。当主站点出现故障时，用户的应用程序切换到备份的替代站点后，被镜像的远程副本可以保证业务继续执行而没有数据的丢失。但它存在往返传播造成延时较长的缺点，只限于在相对较近的距离上应用。
异步远程镜像（异步复制技术）则由本地存储系统提供
给请求镜像主机的I/O操作完成确认信息，保证在更新远程存储视图前完成向本地存储系统输出/输入数据的基本操作，也就是说它的RPO值可能是以秒计算的，也可能是以分或小时为计算单位。它采用了“存储转化（store-and-forward）”技术，所有的I/O操作是在后台同步进行的，这使得本地系统性能受到的影响很小，大大缩短了数据处理时的等待时间。异步远程镜像具有“对网络带宽要求小，传输距离长（可达到1000公里以上）”的优点。不过，由于许多远程的从镜像系统“写”操作是没有得到确认的，当由于某种原因导致数据传输失败时，极有可能会破坏主从系统的数据一致性。
同步远程镜像与异步远程镜像最大的优点就在于，将因灾难引发的数据损耗风险降低到最低（异步）甚至为零（同步）；其次，一旦发生灾难，恢复进程所耗费的时间比较短。这是因为建立远程数据镜像，是不需要经由代理服务器的，它可以支持异构服务器和应用程序。
远程镜像软件和相关配套设备的售价普遍偏高，而且，至少得占用两倍以上的主磁盘空间。不过，如果贵公司的业务流程本身对数据的丢失程度（RPO）或恢复时间（RTO）相对要求较高的话，建立远程镜像将是最佳的解决之道。
除了价格昂贵之外，远程镜像技术还有一个致命的缺陷，它无法阻止系统失败（rolling disaster）、数据丢失、损坏和误删除等灾难的发生。如果主站的数据丢失、损坏或被误删除，备份站点上的数据也将出现连锁反应。目前市面上只有极少数的异步远程镜像产品可做到给每一个事务盖上时间戳（timestamp），一旦发生数据损坏或误删除操作，用户可以指定数据恢复到某个时间点的状态，当然，要实现该功能，并不是仅仅安装远程镜像软件就够了，用户还需要采取其它一些必要的保护手段，比如说延迟复制技术（本地数据复制均在后台日志区进行），在确保本地数据完好无损后再进行远程数据更新。另外，远程镜像技术还存在无法支持异构磁盘阵列和内置存储组件、支持软件种类匮乏、无法提供文件信息等诸多缺点。
如果用户对RPO和RTP两项指标要求较高，同时又无力承担远程镜像解决方案那么昂贵的费用，是否存在其它可行的替代方案可供选择呢？当然有，比如说基于持续性数据保护（简称CDP）、基于时间的连续快照复制、自动备份、自动复制更新数据、分布式备份等技术的产品。它们可支持异构存储系统和rollback（回卷当前事务并取消当前事务中的所有更新）功能，只不过它们的整体拥有成本（简称TCO）较远程镜像产品低一些，而且增加了“安装和管理代理服务器”这一环节。

对许多公司来说，包括中小企业，在线数据备份是一个有效的解决方案，和许多大公司一样，它们经常要面对许多同样的数据管理问题。监管报告的要求和快速成长，以及远程或移动的地理位置，意味着中小企业会联合系统和员工与地理上分散的数据和电子查询的要求进行斗争。然而，许多中小企业仍然依赖基于磁带的备份系统，而且往往没有一个专门的IT工作人员来专门从事设计或开发备份和恢复系统。
有时候，软件即服务( SaaS )和按需存储被交替使用，但不是所有的在线备份解决方案适合SaaS模式。SaaS牵涉到与多个占用者共享一个可扩展的应用(和基础架构)，同时保持数据独立。像Hotmail和Salesforce.com这样的应用就是SaaS极好的案例。中小企业可通过很多方式从在线并且按需存储的备份和恢复中获益，包括成本，保护，归档服务和带宽。
对于成长型的公司来说，以服务水平协议(SLA)为基础的定价手段(结合趋势监测报告)意味着更少的出现意外状况。操作级别协议(OLA)被按需供应商用于描述厂商内部支持组的职责。OLA的定义很简单，但很重要。服务合同帮助制订容量限制(在规定的时限内，可以传送多少数据)和保存期限政策。通常会阐明不同类型数据的恢复点目标和恢复时间目标。
另外，按需服务能够提供7×24的监测，许多小企业都负担不起。额外的好处可能包括特定应用的保护和专业技能，或者是一个内置的灾难恢复( DR )计划。也可能提供归档服务和电子数据发现。最后，许多供应商在存储流程和方法论上更有保证，而且在设置存储策略、合规和审计方面，比你自己的IT团队更加胜任。
当然，企业在考虑按需备份和恢复的时候，必须考虑带宽，这决定了有多少数据能被传输。一些中小型企业可能不得不在这方面作出最初的投资，以获得按需投资的好处。并且大多数组织把备份和恢复的性能作为一个主要的问题，那就会引发通过广域网连接传送数据到第三方站点的一些担心。少数几家厂商在这一领域现在有”快速启动”和”快速恢复”程序，全备份可在初始化设置时实际基于磁盘实施并且快速全面的恢复。
最后，在线备份不只是涉及托管的备份应用。你必须考虑厂商背后提供的服务。问问自己，”这个厂商有多少数据中心？”，”厂商在提供管理服务方面有什么经验？”还有，最重要的是，”对于和我类似需求的公司，他们做得怎么样？”
在线数据备份采购清单
在评估一个在线备份厂商或产品的时候，还有其它一些需要考虑的问题。这里提供了一个中小企业采购时可以借鉴的清单。
有效地传输和存储数据。除了增量备份以外，寻找一些容量压缩的方法，特别是在按照数据存储容量定价的情况下。
速度。寻找能够提供替代基于广域网传输的厂商，以加速初始全备份或全恢复。
相匹配的扩展性。有一个在容量、节点、站点等等方面适应你企业成长的供应商或厂商作为合作伙伴，是至关重要的。
灾难计划。调查一下在厂商的灾难恢复战略中，有多少个数据中心，以及它们在地理上是如何分布的。
满足行业法规和法规遵从的要求。确保供应商有能力满足审计准则公告第70号(SAS 70 )和萨班斯法案( SOX)的审计。
明确的服务承诺。理解SLA和OLA是至关重要的。您要确保对服务目标的论述和基准的制订。

相信大家对”灾备演练”一词都不陌生，但是如何进行灾备演练？灾备演练的方法有哪些？很多人都难以做出清晰明确的回答。
通常，灾备系统建设完成后，面临的灾难不外乎数据级别、应用系统级别和灾备中心级别这三种。因此，所有的演练都是基于这三种级别中某一特定的场景而进行的，灾难场景不同，演练的技术过程也不相同。
一般而言，几乎所有的灾备系统的灾难恢复预案的最初版本都是根据建设目标假设的场景提出的，这样的灾难恢复预案的有效性以及流程是否能够符合企业IT部门应对灾难的需求，都需要企业IT部门对人员技术储备、各种资源协调、灾难恢复过程组织等等进行多次多场景的演练验证来确认。
演练的目的决定演练的方法，通常演练方法分为沙盘推演、模拟演练及实际业务接管演练三种。
沙盘推演
沙盘推演也叫”桌面演练”，是在”模拟演练”前进行的，沙盘推演是对初始灾难恢复预案的一个理论验证，所有参加演练的人员和部门以会议方式，按照预先准备的灾难场景的灾难恢复预案，由参加演练的人员描述自己负责的任务模块的响应和处理过程。
沙盘推演可以检验灾难恢复预案和时间安排是否合理、人员组织是否有效、参演人员职责分工，技术储备及处理过程是否达到预案要求。推演的结果与恢复预案的差距，进而完善恢复预案。
模拟演练
模拟演练以沙盘推演结果（优化后的灾难恢复预案）为基础，模拟演练由IT部门与相关业务部门参加。它是对可能发生的灾难的处理过程的虚拟操作，通过模拟演练来验证灾难恢复预案是否可以达到预期的目标。
模拟演练启用实际的灾备系统来实现系统和业务恢复，采用模拟数据和模拟业务系统运行来验证演习预案。目前许多灾备技术可以完全提供不影响现有生产系统和容灾系统的灾备中心启动功能，因此可以在灾备中心随时获得真实的灾备系统启动环境并且可以在这个环境中施加应用系统的各个模块。演练的处理过程是高度接近真实灾难发生时的处理过程，通过演练可以检验灾备系统的可用性、灾难恢复预案的可行性以及增加参演人员对灾难处理过程的感知度，参演人员对整个灾难处理流程的熟悉程度和各自负责任务的熟练程度，增加灾难处理过程中各环节参加人员配合的默契程度。
通过模拟演练来进一步完善沙盘推演阶段形成的灾难恢复预案，发现演练流程中存在的问题，总结演练中指挥，控制，通信等的有效性，时间安排的合理性以及资源调用，调配是否满足演练的需求。
模拟演练是一种对现有生产环境没有影响的演练方式，但是可以实现灾难恢复预案的比较完整的验证。
实际业务接管演练
实际业务接管演练与灾难发生时处理的结果一样，需要灾备中心真正接替生产运行一段时间。实际业务接管演练可以最大限度的检验灾备系统的灾难恢复能力和灾难恢复预案。验证灾备中心在灾难发生时的实际业务处理能力。在实际业务接管演练中，数据回切是一个比较复杂的环节。对于数据回切，有以下两种方式处理：
1） 灾备中心运行阶段验证正确之后，放弃验证的数据，直接启动生产中心系统恢复生产。
2） 将灾备中心运行的数据，以增量方式恢复到生产中心，在生产中心启动生产。这种方式具有较大风险，如果设定的灾难场景是大型灾难（如地震等），数据的回切则可能以全量方式进行。
绝大多数企业的灾备系统演练都需要按照目标和风险度来设计。灾备演练的三种方法，以递进的方式从纸面理论到实际操作，从业务模拟到业务实际参与等不同层面，不同深度来验证已建成灾备系统的可用性，有效性，通过演练结果来修正、补充、完善灾备恢复预案并为灾备系统的升级建设提供理论依据及数据指标，从而使企业在信息系统灾备建设中有据可依，从而保证建成的灾备系统能充分实现建设的目的、达到建设的目标。
达到灾备演练的目标和完善预案是灾备演练的设计宗旨，对企业而言，切忌贪大造成不必要的生产风险和浪费。

过去五年来，我们在数据保护方式的改变上走过了很长的路。在忍耐了备份到磁带和从磁带恢复这样不可靠的方式后，我们进入了基于磁盘的备份的时代。如今，大部分大中型公司通过基于磁盘的备份方式改善了数据保护环境，至少是最任务关键型的环境。他们满足于磁盘上保存数周到数月的数据（用于数据恢复用途）和在磁带上保存更旧的备份以满足监管规制和商业合规的要求。随着基于磁盘案的技术变得更加可靠同时提供比磁带更加可测的结果，RTO（恢复时间目标）和RPO（恢复点目标）有了明显的改善。

但是大部分IT人员所采用的技术仍然是基于PIT（时间点）的。这毫不奇怪：在学会跑之前，你必须先学会走路。例如，虚拟磁带库（VTL）的设计就是在帮助你减少备份时间的同时改善备份可靠性和恢复效率。你可以在不改变备份流程的情况下做这些事情。你可以仍然维持原来每周完全备份和每天增量备份的模式，只是简单地提高备份/恢复速度和可靠性。此外，你可以继续采用以前的方式来进行DR（灾难恢复）。

但是，虽然这些技术有熟悉易用的优点，但是它们仍然无法最终解决PIT备份操作的问题，而这个问题可能会影响到生产应用程序并导致恢复过程中的数据丢失。好消息是已经有几家厂商在开发能够解决这些问题的产品。

PIT备份缺点

过去，数据保护的任务主要是定期创建生产数据的副本，并将其单独于生产服务器进行存储，以便能够在数据丢失、损坏或不可用的情况下恢复数据。24×7（一天24小时，一周7天）营运模式的兴起推动备份操作从离线变为在线操作，但是生产应用程序的性能受到影响，有些时候这种影响是很明显的，尤其是在备份操作过程中。

过去20年来，数据保护技术的进步–包括增量和差异备份、复用、更快的磁带技术、基于磁盘的备份、快照、VTL和重复数据删除–改善了数据保护流程，但是它们没有改变以PIT为导向的备份方式。PIT备份不可避免地导致恢复操作潜在的数据丢失，而数据丢失的数量取决于备份频率。

PIT方式的四大备份问题包括数据窗口、恢复点目标（RPO）、恢复时间目标（RTO）和恢复可靠性。数据保护技术的发展已经减轻了这些问题的影响，但是它们仍然存在。

CDP

连续数据保护（CDP）的概念很简单：在创建了数据集的基准线并存储在磁盘上之后，CDP捕捉应用程序进行的每次写入操作并保存所有与之相关的元数据（时间戳、卷关联等）。通过保存在磁盘目录中的数据，用户可以在任意时间点（APIT）随需创建卷镜像。你可以将CDP想象成数据的TiVo（硬盘数字录像设备）。

CDP技术改变了数据保护技术的格局。由于数据得到连续搜集，数据在创建以后就可以马上恢复–不需要等待备份完成后。它大大降低了即时资源消耗–不仅是生产服务器，还包括网络。CDP不是将所有数据改变打包后一次性地在网络上传输，CDP是在写入操作创建后实时地在网络上传输写入流。

虽然CDP的概念很简单，但是这个技术直到几年前才实现可行性。这主要是因为它有一个很难的问题要克服。一些厂商现在已经在提供CDP产品。CDP技术的潜力很大，一些创新型的厂商已经开发了综合的恢复解决方案，提供比基本CDP产品更为全面的功能。这些厂商将从根本上改变数据保护行业的格局。

精粒度数据捕捉技术的使用和APIT镜像的创建已经被证明是基于磁盘的恢复对相对近期数据的一个有力工具。IT管理员可以为应用程序选择、创建和呈现历史镜像（”恢复镜像”）。它改变了企业对数据保护的认识。

我们已经看到数据库和电子邮件数据保护行业正在快速地采用CDP。关键的突破是CDP可以自动选择应用程序数据的任何子集，精确选择需要的恢复时点，根据时间感知的元数据创建合适的镜像，将零数据丢失镜像提供给应用程序。实际上，已经有人在思考如何利用CDP解决方案建立一个可以适用于所有规模大小企业的先进的恢复管理功能。一些有效的使用情境已经出现，包括：

廉价DR：在许多情况下，CDP解决方案可以从本地客户端将数据捕捉到远程站点上的CDP目标端，也可以连续地在本地客户端和远程目标端之间进行数据的异步复制。对于灾难恢复，甚至对于两个站点环境不同的异质环境而言，CDP可以大大减少复杂性。与CDP相比，基于阵列的复制方式可能需要跨越多个阵列，同时还需要管理员仔细标记和管理单个已知的好的恢复时间点。此外，与没有保存历史数据点的复制解决方案相比，基于CDP的灾难恢复对数据损坏的容忍度更高。

完全DR下的本地备份和恢复：在这种使用情境下，来源端服务器设置成将数据变化捕捉到本地CDP目标端，而数据则同时复制到远程站点的另一个目标端（这个复制可以是主机进行的，也可以是CDP目标端进行的）。这种方式为数据复原或测试提供了站内目录以及作为站点层次恢复或离站测试工具的远程站点，使两个地点都拥有全部的数据集。与远程目录相比，利用CDP进行本地化的备份和DR可以更简单。远程目录可能需要复制全部的PIT备份数据集，这不仅非常消耗带宽，而且还涉及数据保护软件复杂的恢复操作。

合规要求下整合的备份和DR：使用和上述解决方案同样的架构，CDP解决方案可以有效减少前端磁带存储。所有短期恢复操作都直接利用CDP解决方案从磁盘中进行，同时数据定期直接从CDP目录卸载到磁带–不管是重建客户端数据还是作为CDP目录的块层次镜像都可以。在这种方式下，对配置CDP的主机而言，所有磁带互动可以避免，而除了与CDP系统相连的磁带架构以外，磁带支持架构的规模可以大大缩减。这些磁带可以本地存储，也可以远程存储以满足合规要求。

Taneja集团的观点

与我们预计的时间相比，IT人员了解CDP能力的过程显然花了更长的时间。当然，过去几年来，所有主要的厂商都开始进入CDP市场，从而推动CDP成为主流技术。如今，市场上已经有很多CDP厂商，比如Atempo、BakBone、DataCore、EMC、FalconStor、IBM、InMage和赛门铁克。一些厂商是刚刚涉足CDP而且最近才增加复制功能。一些厂商则首先专注于DR方面并且现在已经将解决方案扩展到本地备份和恢复。我们看到，无论知道还是不知道连续数据技术（CDT）（也无论他们是把它叫做CDT还是其他名字），所有这些厂商都在朝着更加复杂的连续数据技术方向前进。

CDT的功能很强大。一旦你创建了模式并拥有可以在任意历史时间点创建镜像的能力，与副本创建有关的一切将极大改变。CDT不需要备份窗口，可以提供快速、可靠和零数据丢失的本地恢复；它可以进行大规模DR，辅助虚拟化服务器，使原来被排除在数据保护大门外的新的应用程序得到数据保护。对于IT管理而言，更重要的是，CDT简化了环境，它可以替代多个产品和流程，通过单一的解决方案来实现多重目的。

零投入解决方案

实现数据备份并不一定都需要资金投入。当数据重要性不高，系统简单，而且没有自动化和长期保存的需求时，完全可以利用现有的资源，搭建一个数据备份系统，而无需任何的资金投入。

例如，对简单办公环境下的个人数据进行备份。在Windows、Linux等桌面*作系统内，大多集成有一些简单的数据备份功能。这些备份功能足以实现对普通文件的自动的定时的备份。还有很多功能不错的小型备份软件可以从Internet上下载，这些软件虽然不能实现对专业级数据库的支持，但对一般桌面办公系统来说，功能也都是足够了。

至于备份数据的保存，可以选择本机磁盘的空闲空间或者网络服务器的空间。一般来讲，选择网络服务器的空间更加安全，因为一旦本机磁盘出现故障，很可能整个磁盘无法访问，那样存放在本机磁盘的备份数据也就失去了意义

总结：单机备份；数据量较小；无长期保存需求，仅仅为了防止数据丢失；无专业数据库应用；系统可随时停机；手工恢复数据。

1~2万元投入解决方案

对于一些需要长期保存数据的系统来说，简单的在网络服务器上保存备份数据，就显得不够经济了，应该采购一台磁带机和一些磁带作为备份数据的长期保存介质。一般一台磁带驱动器的价格就在1~2万元左右。采购了磁带机就没钱买备份软件了，没关系。仍然使用系统自带的备份功能，还是可以解决问题的。事实上很多系统的数据需要长期保存，但是并没有很高的自动化要求，对计划停机的限制也不严格，在这种情况下，如果没有大型数据库应用，一般都可以解决数据备份需求。

例如个人级的网站、小型医疗系统、小型档案系统等。这些系统与个人级桌面系统相比，数据量要大一些，而且要求数据相对较长期的保存。但是数据形式基本都是文件形式，没有复杂的数据库结构，而且停机进行数据备份完全是可以允许的。这样的需求，*作系统集成的备份软件加上一个磁带机，完全可以实现系统的每天自动备份。

总结：单机备份；数据量一般；需要长期保存数据；无专业数据库应用；允许计划内停机；手工恢复数据。

3~5万元投入解决方案

当系统需要通过网络进行数据备份时，*作系统集成的备份功能就无法满足需求了。这时，除了采购磁带机之外，还需要采购较专业的备份软件来实现网络备份。一般Windows平台的备份软件产品价格不高，2~3万元的软件投入应该可以达到设计目标。加上1~2万元的磁带机成本，总体成本可以控制在3~5万元之间。

这样的系统已经可以支持一定的数据库应用，并且可以实现自动化的数据恢复。对中型的办公系统、小型专业网站、小规模的校园网等环境来说，这一系统已经全面达到数据保护的目的。需要注意的是，这个方案只针对Windows、Linux等平台的主机系统，如果主机平台是Unix小型机，这样的投资就无法满足功能需求了。

总结：简单网络备份；Windows*作系统平台；数据量一般；需要长期保存数据；有一定数据库应用；允许计划内停机；自动化恢复数据。

10万元投入解决方案

当系统数据的重要性很高时，数据备份的投资力度相应的也会增大。尤其是当系统要求7×24小时可用，没有给备份工作提供停机备份的时间窗口时，备份系统必须具有能够对打开文件进行备份的能力，即所谓在线备份技术。这就要求备份软件的功能足够强大。同时，随着系统自动化要求的提高，手工管理磁带介质的方式难以满足系统的需求，在数据量不是很大的情况下，可以考虑采购自动加载机（AutoLoader）进行准自动化的磁带管理。

在这样的要求下，投入在软件和硬件方面的资金都需求有所增加。一般Windows平台上能够进行在线备份的软件，投资应该在6~8万元，而自动加载机的价格也在3万元左右，这样整体的系统投资基本在10万元左右。

以此投资力度建立的备份系统可以支撑一个相当规模的Windows网络环境，对其中的文件、数据库应用、邮件系统、用户信息等数据都可以进行集中统一的备份保护。备份过程完全是自动化的，无需人工干预。而且，当系统中某节点出现故障时，数据恢复工作也完全是自动化和智能化的，只要提供备份介质和可引导的系统启动盘，备份软件就可以恢复出系统故障前的状态。

这种备份系统的应用环境也十分广泛。中小学校园网、证券交易营业部、政府机关办公网络系统、中型企业网了系统、电子商务网站等待，都基本处在这一需求层次上。从一定意思讲，这个层次的系统应用是最为广泛的。基本上由Windows平台构成的较复杂的网络环境中，这种数据备份方式都可以适用。从另外一个方面讲，这个层次的用户也是备份市场需求构成的主要力量。

总结：中型网络备份；Windows*作系统平台；数据量较大；需要长期保存数据；典型数据库应用；邮件系统等其他专业数据；基本无停机备份；智能化恢复数据。

30万元以上的投入

当数据量达到TB级时，单台磁带机和自动加载机已经无法满足自动化管理的需求，而需求配置自动化程度更高的磁带库设备。一般这种环境下*作系统平台也会以Unix为主，或者是更为复杂的多种*作系统平台混和系统。这种环境下，数据保护工作的复杂程度进一步增加。一个典型的混和平台环境，数据备份系统投资额基本都在30万元以上。

如果以30万元投入计算，其中软件部分所占的投入约为30~40%，用来采购支持Unix平台的高端备份软件服务器端和客户端代理，以及一些数据库接口程序和磁带库支持程序等部分。其他60~70%的资金是用来采购磁带库设备以及一定数量的磁带。如果需要实现SAN架构下的LAN Free的数据备份，则还需要增加10万元左右的资金投入，用以搭建SAN的光纤交换部分。

这种解决方案不仅可以全面的实现混和系统平台的全自动化数据备份工作，支持各种大型数据库应用，实现7×24小时的不停机数据在线备份，而且可以实现不需要占用网络资源的LAN Free的数据备份。同时，在这样的解决方案中，数据的傻瓜化恢复功能已经不再重要，由于系统结构的复杂和数据关系的复杂，完全无需人工干预的傻瓜化智能灾难恢复往往会造成系统状态的不一致，从而丧失了数据恢复的意义。在这种级别的应用环境中，系统需要对数据恢复的方式和内容更加灵活的控制。系统应该可以提供选择性的恢复数据，以及指定时间的状态恢复。

这种级别的数据备份系统一般应用在大型的海量存储系统中。例如大型企业中心数据系统、省市级国家机关专用信息系统、科研院所专业信息系统、一般资料检索系统等。这些系统基本上完全排除了系统故障，极高的要求业务系统的连续性、稳定性和可用性，完全不允许任何情况下的计划内和计划外停机。对备份任务对系统资源的占用一般也有严格而明确的限制，一般不允许备份数据流大量占用网络带宽资源。总之，在这一应用层次上，备份系统已经被作为一个独立的系统来看待，备份工作已经是整个系统正常运行不可缺少的一个组成部分。所谓的高端备份市场就是指这一领域的市场需求。

总结：大型网络备份；Unix或多种*作系统平台；数据量达到TB级；需要长期保存数据；大型数据库应用；邮件系统等其他专业数据；完全无停机备份；灵活的恢复数据；不占用网络带宽资源。

100万元以上的投入

对于数据中心级的存储系统，数据备份系统的建设也大大增加。这主要源于两方面的原因：数据量的庞大和安全性要求的提高。事实上，在数据中心级的超大型存储系统中，对备份系统的功能要求，并不比前一个层次更多。但是其动辄数十甚至上百TB的数据量，却使磁带库设备的硬件成本翻倍的增加。另外，由于这些数据一旦丢失或损坏，后果将十分严重，所以其在线存储系统也大多采用了远程容灾等手段，这进一步增加了与之配合的备份系统的软硬件成本投入。一般一个配合远程容灾系统的数据备份系统，其投资额度都不会小于100万元。

在这种超大型的系统中，备份系统的软件投入比例一般为20~30%，而硬件投入占绝大部分，有70~80%之多。采购内容基本没有什么变化，软件部分基本还是备份服务器端、备份客户端、数据库接口模块、磁带库支持模块等部分，对容灾系统而言，有时候也会有特殊的在线存储设备接口模块。而对硬件设备部分，基本还是磁带库及其连接设备。当然，在如此大容量的环境中，采购磁带也是一笔不可忽视的资金投入。

有趣的是，在如此大资金的投入下，建成的数据备份系统，其真正面临系统故障的机会是少之又少。因为这种数据中心级的存储系统，其数据可用性要求已经达到了顶峰，所以在线存储系统大多采用目前最为稳定的产品，并配合最为先进的技术来保证数据不丢失。那么是不是说这样的备份系统就没有意义了呢？当然不是！事实上，在这种大型的数据中心里，备份系统的另一个意义凸现了出来，那就是文件的归档保存。我们知道在线存储系统的技术再先进，也只能保证当前的数据不丢失不损坏，而无法帮系统记录下从前的历史数据，而备份系统的功能正在于此。那些需要保留下来，以便进行统一分析的数据和状态，都完整的保留在备份系统中。

例如国家气象中心的气象数据存储系统、电信计费中心的计费数据、银行数据中心的储户交易数据等等。这些存储系统都具有非常强大的在线存储系统，其数据保护力度之大，即使在发生火灾地震这样的灾难时，也可以保证数据不会丢失。但这些系统都建立了投资巨大的备份系统，其作用主要就是为了保存重要的历史信息和状态，以便进行统一的数据分析和数据挖掘。

当然，在数据中心级的存储系统中，极偶尔的也会出现意外事件。也许大家对不久前，发生在首都机场的网络系统意外故障还记忆犹新，这说明，再坚固的意外防范措施，也难免有百密一疏的时候。在这个时候，备份系统的作用灵光一现，已经足以抵付当初的巨额投资了。实际上，如果没有备份系统的存在，发生在首都机场的意外，造成的可就不仅仅是几十分钟的延误了。

REDO LOG是Oracle为确保已经提交的事务不会丢失而建立的一个机制。实际上REDO LOG的存在是为两种场景准备的，一种我们称之为实例恢复（INSTANCE RECOVERY），一种我们称之为介质恢复（MEDIA RECOVERY）。实例恢复的目的是在数据库发生故障时，确保BUFFER CACHE中的数据不会丢失，不会造成数据库的不一致。介质恢复的目的是当数据文件发生故障时，能够恢复数据。虽然这两种恢复使用的机制类似的，但是这两种恢复也有着十分本质的不同，这一点也是很多DBA经常会混淆的。
REDO LOG的数据是按照THREAD来组织的，对于单实例系统来说，只有一个THREAD，对于RAC系统来说，可能存在多个THREAD，每个数据库实例拥有一组独立的REDO LOG文件，拥有独立的LOG BUFFER，某个实例的变化会被独立的记录到一个THREAD的REDO LOG文件中。
对于介质恢复和实例恢复来说，第一个步骤都是通过REDO LOG的信息进行前滚，在做前滚的时候，通过REDO LOG文件里记录的数据库变化矢量（稍后我们会详细的介绍数据库变化矢量CV），根据SCN的比对，提交到相关的数据文件上，从而使数据文件的状态向前滚动。大家要注意的是，UNDO表空间的变化也被记录到REDO LOG里了，因此UNDO表空间相关的数据文件也会被前滚。当前滚到最后一个可用的REDO LOG或者归档日志的时候，所有的数据库恢复层面的工作就全部完成了。这个时候，数据库包含了所有的被记录的变化，这些变化中有些是已经提交，有些是尚未提交的。在最新状态的UNDO表空间中，我们也可以看到一些尚未提交的事务。
因此数据库下一步需要做的事情是事务层面的处理，回滚那些尚未提交的事务，以确保数据库的一致性。
对于单实例的系统，实例恢复一般是在数据库实例异常故障后数据库重启时进行，当数据库执行了SHUTDOWN ABORT或者由于操作系统、主机等原因宕机重启后，在ALTER DATABASE OPEN的时候，就会自动做实例恢复。而在RAC环境中，如果某个实例宕了，或者的实例将会接管，替宕掉的实例做实例恢复。除非是所有的实例都宕了，这样的话，第一个执行ALTER DATABASE OPEN的实例将会做实例恢复。这也是REDO LOG是实例私有的组件，但是REDO LOG文件必须存放在共享存储上的原因。
Oracle数据库的CACHE机制是以性能为导向的，CACHE机制应该最大限度的提高数据库的性能，因此CACHE被写入数据文件总是尽可能的推迟。这种机制大大提高了数据库的性能，但是当实例出现故障时，可能出现一些问题。
首先是在实例故障时，可能某些事物对数据文件的修改并没有完全写入磁盘，可能磁盘文件中丢失了某些已经提交事务对数据文件的修改信息。其次是可能某些还没有提交的事务对数据文件的修改已经被写入磁盘文件了。也有可能某个原子变更的部分数据已经被写入文件，而部分数据还没有被写入磁盘文件。实例恢复就是要通过ONLINE REDO LOG文件中记录的信息，自动的完成上述数据的修复工作。这个过程是完全自动的，不需要人工干预。
在这个机制里，有两个问题需要解决，第一个是如何确保已经提交的事务不会丢失，第二个是如何在数据库性能和实例恢复所需要的时间上做出平衡，既确保数据库性能不会下降，又保证实例恢复的快速。
解决第一个问题比较简单，Oracle有一个机制，叫做Log-Force-at-Commit，就是说，在事务提交的时候，和这个事务相关的REDO LOG数据，包括COMMIT记录，都必须从LOG BUFFER中写入REDO LOG文件，此时事务提交成功的信号才能发送给用户进程。通过这个机制，可以确保哪怕这个已经提交的事务中的部分BUFFER CACHE还没有被写入数据文件，就发生了实例故障，在做实例恢复的时候，也可以通过REDO LOG的信息，将不一致的数据前滚。
解决第二个问题，oracle是通过checkpoint机制来实现的。Oracle数据库中，对BUFFER CAHCE的修改操作是前台进程完成的，但是前台进程只负责将数据块从数据文件中读到BUFFER CACHE中，不负责BUFFER CACHE写入数据文件。BUFFER CACHE写入数据文件的操作是由后台进程DBWR来完成的。DBWR可以根据系统的负载情况以及数据块是否被其他进程使用来将一部分数据块回写到数据文件中。这种机制下，某个数据块被写回文件的时间可能具有一定的随机性的，有些先修改的数据块可能比较晚才被写入数据文件。而CHECKPOINT机制就是对这个机制的一个有效的补充，CHECKPOINT发生的时候，CKPT进程会要求DBWR进程将某个SCN以前的所有被修改的块都被写回数据文件。这样一旦这次CHECKPOINT完成后，这个SCN前的所有数据变更都已经存盘，如果之后发生了实例故障，那么做实例恢复的时候，只需要冲这次CHECKPOINT已经完成后的变化量开始就行了，CHECKPOINT之前的变化就不需要再去考虑了。
到目前为止，我们了解了实例恢复机制的一些基本的原理，我们也可以大体上理解REDO LOG的工作机制了。不过我想我们还需要再更加深入一些。了解一些更为深入的内幕。实际上通过上面老白的介绍，大家也许已经觉得对实例恢复了解的很透彻了，而实际上，有很多问题我们还没有解决。有些爱动脑筋的读者可能要问了，有没有可能数据文件中的变化已经写盘，但是REDO LOG信息还在LOG BUFFER中，没有写入REDO LOG呢，这种情况如何恢复呢？
这里我们又要引入一个名词：Write-Ahead-Log，就是日志写入优先。日志写入优先包含两方面的算法，第一个方面是，当某个BUFFER CACHE的修改的变化矢量还没有写入REDO LOG文件之前，这个修改后的BUFFER CACHE的数据不允许被写入数据文件，这样就确保了再数据文件中不可能包含未在REDO LOG文件中记录的变化；第二个方面是，当对某个数据的UNDO信息的变化矢量没有被写入REDO LOG之前，这个BUFFER CACHE的修改不能被写入数据文件。
介质恢复和实例恢复的机制是类似的，所不同的是，介质恢复是当存储的数据文件出现故障的时候进行的，介质恢复无法自动进行，必须手工执行recover Database或者recover datafile命令来实施。一般来说，介质恢复是从一个恢复的数据文件为起点进行恢复，因此在做介质恢复的时候，需要使用归档日志。