一种数据灾备装置、系统及方法与流程

本发明涉及数据处理技术，具体的讲是一种数据灾备装置、系统及方法。

背景技术：

数据库系统是当前大多数企业级信息化系统的核心组成部分，维护着对于企业生产经营至关重要的数据信息。可能发生的系统故障、存储故障和网络故障等引起的数据库系统中断，如果缺少完善的保护方案，将会造成业务运行中断和数据丢失，对企业经营和声誉等将会造成重大损失。尤其是金融、通讯、国防等行业，对于数据库系统有着很高的可用性、可靠性和连续性运行等要求，往往需要建立数据库的灾难备份和恢复系统，以尽量减少生产故障所带来的运行中断和数据丢失。

灾备系统主要采用主备系统的形式，即部署主、备两个节点，在主节点发生故障时快速切换至备用节点；目前，一些灾备系统也有采用双活的形式，即两个节点同时提供服务，互为备份，在其中某一节点发生故障时可以快速切换至另一节点。由于多节点之间数据同步的需求，一般企业往往采用同城灾备的形式。而对于金融等行业来说，为了进一步提高系统抵御灾难事件的能力，在地震、核打击等极端灾难条件下仍能对外提供连续服务，则要求系统实施异地灾备。以银行业为例，目前基于国内银行业监管机构制定的系统灾难备份相关标准的要求，“两地多中心”已逐步成为国内银行广泛采用的灾备建设模式。在生产环境失效时，优先进行同城中心的切换；而在极端灾难导致的同城多中心同时失效时，可以切换至异地的灾备中心重新开展业务。异地灾备的存在，可以最大程序的保障业务的连续运行。

对于灾备恢复中重要的RPO(Recovery Point Objective，复原点目标)指标来说，同城灾备很容易达到RPO＝0的目标。而目前的异地灾备，面临的主要问题就是在灾难恢复时很难做到数据的零丢失恢复。在灾难发生时，由于物理距离和网络延时的存在，主生产节点最新的数据很难及时地同步到异地灾备环境中，从而导致这部分数据在灾备环境恢复后被丢失。

技术实现要素：

为了实现异地灾备数据恢复零丢失，克服现有大型数据库系统异地灾备和恢复技术上的不足，本发明实施例提供了一种数据灾备装置包括：

应用操作日志生成模块，用于根据应用服务器对数据库服务器的操作同步生成应用操作日志；

日志存储器，用于存储所述应用操作日志；

备数据库模块，用于对数据库服务器的数据库数据进行备份。

本发明实施例中，数据灾备装置还包括：

恢复模块，用于根据所述应用操作日志和备份的数据库数据生成恢复数据。

同时，本发明还提供一种数据灾备系统，包括：应用服务器，应用日志服务器以及备数据库服务器，所述应用日志服务器和备数据库设置于灾备中心；其中，

所述的应用服务器包括：

应用操作日志生成模块，用于根据应用服务器对数据库服务器的操作同步生成应用操作日志；

所述的应用日志服务器，用于存储所述应用操作日志；

备数据库服务器，用于对数据库服务器的数据库数据进行备份。

本发明实施例中，数据灾备系统还包括：

备应用服务器，用于根据所述应用操作日志和备份的数据库数据生成恢复数据。

进一步，本发明还提供一种数据灾备方法，包括：

根据应用服务器对数据库服务器的操作同步生成应用操作日志；

将所述应用操作日志传输至灾备中心并存储所述应用操作日志；

对数据库服务器的数据库数据进行备份。

本发明实施例中，数据灾备方法还包括：

根据所述应用操作日志和备份的数据库数据生成恢复数据。

本发明实施例中，所述的应用服务器对数据库的操作包括：应用服务器对数据库服务器进行的包括增加、删除、修改的DML操作指令。

本发明实施例中，所述的数据库服务器通过远程异步复制将所述数据库数据备份到备数据库模块。

本发明实施例中，所述的应用操作日志为纯文本数据。

本发明实施例中，所述的应用操作日志其内容包括：应用服务器对数据库服务器操作的指令、参数以及执行结果。

本发明充分利用了底层磁盘级数据同步和应用级日志恢复的优点，将消耗资源的计算和处理等工作放在灾备服务器上来进行，最大程度地减少了网络传输和延迟，减轻了对主服务器生产的负担，并且相比较现有技术中数据库日志级的传输，本发明中应用级日志传输数据量要小一个数量级，因此，带来网络传输数据量少，延时短。

为让本发明的上述和其他目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附图式，作详细说明如下。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为基于磁盘级的数据同步和恢复架构；

图2为数据库级的数据同步和恢复架构；

图3为基于数据库日志的同步架构；

图4为本发明公开的一种数据灾备装置的框图；

图5为本发明公开的数据灾备系统的示意图；

图6为本发明公开的一种数据灾备方法的流程图；

图7为本发明实施例中的灾备系统的总体架构；

图8为本发明实施例中应用日志的功能模块框图；

图9为本发明实施例中公开的数据备份和恢复流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

现有技术的数据库灾备恢复技术有两类：基于磁盘级的数据恢复和基于数据库级的数据恢复。

其中，基于磁盘级的数据恢复技术，从存储层提供数据保护，其部署架构如图1所示。通过在主、备站点分别部署数据库服务器和磁盘阵列，主、备的磁盘阵列通过光纤相连，并通过磁盘复制进行数据同步。当发生主站点故障时，可以通过启动备站点的数据库服务器来提供业务系统访问，从而保证系统的高可用性。磁盘级同步基于底层的磁盘扫描，技术实现简单，稳定可靠。但其缺点也是显而易见的：磁盘复制量大，占用大量服务器资源，对主站点的性能产生较大影响；数据传输量大，占用较大的网络资源，带来不可避免的网络延迟。

而基于数据库级的数据恢复技术，其主要架构如图2所示。该技术主要通过将数据库级的日志文件从主数据库传送至备数据库，备数据库的接收进程将日志流写入备日志文件或归档日志文件，备数据库服务器进程再通过加载日志来更新数据文件，从而实现主、备数据库的数据同步。该方法主要有同步和异步两种模式。同步是确认日志传送备数据库成功后才返回事务完成标示，从而确保主备数据一致，但此种模式对主数据库交易影响严重。异步模式主数据库交易不等待日志文件同步，避免了对主数据库的影响，但同步时点是在主数据库联机日志切换至归档时发生，延迟较大。

与磁盘级同步相比，数据库级同步磁盘复制量和数据传输量都有所减少，但仍存在较大的服务器和网络压力，以数据库级同步的典型技术，Oracle DataGuard而言，建议的实施场景仍然在百公里级以内的同城灾备，网络延时在3毫秒以内，可以实现RPO＝0的目标；而对于千公里级的异地灾备，如果强制设定RPO＝0的目标，则会对主生产系统和网络带来严重的影响。

现有技术中，也有基于数据库级同步，独立于数据库系统之外，单独搭建用于实时同步数据库联机日志的服务器。其部署架构如图3所示。这种方法避免归档日志的延迟和对数据库本身的资源占用，可以很好地应用于同城备份。但数据库级日志传输量仍然偏大，用于异地灾备环境时资源消耗压力较大。同时，数据库级日志同步将所有数据变动进行同步，无法从业务级别进行控制。实践中，数据库日志中有很大部分是临时表或日志表的操作，而无法在业务级别上对核心流程上的数据进行优先保证。

综上所述，目前的数据灾备恢复技术存在以下问题：

数据复制量大，对原有主系统带来较大的资源消耗；

数据传输量大，占用较大的网络资源，加大了网络负担和延时。

在同城灾备环境下可以实现RPO＝0的目标，但在异地灾备环境下RPO较大，有数据丢失。如果强制要求RPO＝0，则会对主系统和网络带来严重影响。

在整个磁盘级或数据库级实现，无法做到应用级业务的灵活控制，无法实现在灾备的特殊场景下对指定核心业务的优先保证。

针对目前在异地灾备恢复的场景下非常常见的数据丢失(RPO>0)问题，迫切需要一种能实现RPO＝0，同时对主系统影响小、主系统资源和网络占用少的技术，同时满足易实现，可操作性高，灵活可配置等要求。鉴于目前单单从磁盘级或数据库级入手已很难满足所有指标，因此有必要从应用层面入手，应用层与底层相结合，充分利用各自优点，来解决在远程异地灾备条件下的数据恢复问题。

本发明提供一种数据灾备装置，如图4所示，该装置包括：

应用操作日志生成模块401，用于根据应用服务器对数据库服务器的操作同步生成应用操作日志；

日志存储器402，用于存储所述应用操作日志；

备数据库模块403，用于对数据库服务器的数据库数据进行备份。

本发明实施例中，数据灾备装置还包括：

恢复模块404，用于根据所述应用操作日志和备份的数据库数据生成恢复数据。

同时，本发明还提供一种数据灾备系统，如图5所示，该系统包括：应用服务器501，应用日志服务器502以及备数据库服务器503，所述应用日志服务器502和备数据库503设置于灾备中心；其中，

所述的应用服务器包括：

应用操作日志生成模块，用于根据应用服务器501对数据库服务器504的操作同步生成应用操作日志；

所述的应用日志服务器，用于存储所述应用操作日志；

备数据库服务器，用于对数据库服务器的数据库数据进行备份。

本发明实施例中，数据灾备系统还包括：

备应用服务器，用于根据所述应用操作日志和备份的数据库数据生成恢复数据。

进一步，本发明还提供一种数据灾备方法，如图6所示，该方法包括：

步骤S601，根据应用服务器对数据库服务器的操作同步生成应用操作日志；

步骤S602，将所述应用操作日志传输至灾备中心并存储所述应用操作日志；

步骤S603，对数据库服务器的数据库数据进行备份。

本发明实施例中，数据灾备方法还包括：

根据所述应用操作日志和备份的数据库数据生成恢复数据。

本发明实施例中，所述的应用服务器对数据库的操作包括：应用服务器对数据库服务器进行的包括增加、删除、修改的DML操作指令。

本发明实施例中，所述的数据库服务器通过远程异步复制将所述数据库数据备份到备数据库模块。

本发明实施例中，所述的应用操作日志为纯文本数据。

本发明提出了基于应用级日志的数据恢复系统及方法。结合了底层磁盘级数据恢复和应用级日志的优点，克服了现有大型数据库系统异地灾备和恢复技术上不足，提出了一种能支持数据库跨千公里级的异地灾备恢复过程中数据零丢失目标的新技术。该技术在实现异地灾备系统RPO＝0的同时，对主系统和网络资源并不会带来明显的额外负担。该技术所提出的底层磁盘级复制加顶层应用级日志相结合的思路，也可用于其他大型信息化系统灾难备份和恢复机制设计时的参考。

本发明实施例以现有磁盘级的HUR等异步远程复制技术为基础，增加使用应用级的数据库操作日志，用来恢复磁盘复制技术所造成的分钟级别的数据差。通过磁盘级别的数据同步和应用日志相结合，充分利用两种方式的优点，在恢复过程中把主要的数据处理、计算资源消耗等，放在灾备服务器端进行，最大程度减少了主系统资源消耗和网络带宽占用，同时，由于应用日志恢复机制的存在，对磁盘级复制的实时性依赖降低，可以有效降低磁盘级复制的实时级别，以减轻HUR磁盘复制的资源消耗。本发明基于底层磁盘复制的全量和稳定等优点，结合应用级日志的轻量和灵活，保障了数据完整恢复的同时，有效克服了现有同步技术所带来的数据延迟大和资源消耗高等问题。

本发明使得数据库系统可以在实施千里级别以上的异地灾备方案的同时，能够实现灾难恢复中RPO＝0，从而极大的提升了数据库异地灾备系统的RPO指标，进一步提高了整个企业信息化系统的高可用性和业务连续性。

下面结合具体的实施例对本发明技术方案做进一步详细说明，本发明实施例的技术思路是在应用服务器和数据库服务器之间，搭建专门的应用日志服务器，用于记录应用服务器访问数据库时的操作日志。结合底层的磁盘复制技术，该发明对于灾难备份和恢复。本实施例进行灾备和恢复的主要过程为：

1.在日常备份时，由磁盘复制同步主要数据，而应用日志实时记录当前应用的数据库操作，日志空间循环使用。

2.在灾难恢复时，先启用磁盘备份恢复整体系统，然后对于磁盘同步中断的时间点之后的所有数据库操作，自动重新执行应用日志中的记录，达到完整恢复数据的目的。

本实施例的系统总体架构如图7所示，本发明提出的基于应用级日志的数据恢复系统包括：日志记录部分、底层磁盘文件同步部分和日志恢复部分。

首先，在日志记录部分，由于业务对于数据库的操作，都是通过中间层的应用服务器App来进行的，记录了应用服务器对于数据库DB的操作日志，便可以保证对于数据变化的完整记录。日志仅记录应用服务器对数据库服务器的增、删、改等DML操作指令，对于大量的查询等不修改数据的操作并不做记录。按照灾备恢复的要求，应用日志服务器AppLog物理上将位于灾备中心，应用服务器远程记录。但由于需要记录的应用日志内容极少，仅包括操作的指令、参数和执行结果等，为纯文本信息，由此产生的网络延迟几乎可以忽略。应用日志主要用来补充底层磁盘所造成的短时数据丢失，因此日志空间可以做到循环使用，以减少磁盘占用。

其次，底层的磁盘同步部分，远程异地灾备环境中，搭建一套数据库的灾备库。主系统数据库服务器的数据文件所在磁盘Disk与灾备库磁盘Disk_B之间，通过常规的远程异步复制技术进行数据的同步。本实施例以HDS公司最新的磁盘复制技术HUR为例，但本发明的技术方案并不依赖于特定的磁盘远程复制技术。与传统磁盘复制技术相比，HUR主要特点在于不是将数据从生产中心推向灾备中心，而是将其吸拉到灾备中心。在这种方式下，所有的性能损耗都集中在灾备中心一端，进一步减少对生产中心性能的影响。HUR广泛应用于远程环境中的灾备，能同步磁盘全量数据，稳定可靠。但HUR并不能保证数据的实施同步，在千公里级别的实践中，将会有10秒-5分钟之间的数据延迟。

在灾难恢复时，首先使用灾备磁盘Disk_B重新启动备用数据库DB_B服务器。此时，由于HUR本身的延时，备数据库DB_B与主数据库DB之间会存在一定数据差异：(DB-DB_B)。而由于应用日志之间的延时要远远小于底层磁盘级的HUR同步延时，因此，在主库上执行成功的最新数据库操作，其应用日志已经同步传输至灾备中心的应用日志服务器AppLog上。重新在备库DB_B执行一遍自HUR同步中断时间点之后所有的日志内容，可以将缺少的数据进行补充，使得DB_B达到与灾难前的DB数据一致的目的。之后备用的应用服务器App_B连接上DB_B之外，可以重新对外提供服务。在这个过程中，DB_B最终实现了与DB的一致，即RPO＝0。

在这个架构中，日常活动的节点包括生产中心的App服务器、DB服务器、磁盘Disk，灾备中心的应用日志AppLog服务器、灾备磁盘Disk_B，以及HUR同步和日志同步机制；在灾难恢复过程中需要使用到的节点包括灾备中心的磁盘Disk_B、DB_B服务器和应用日志AppLog；在灾难恢复后的对外服务中，灾备中心的App_B服务器、DB_B服务器、磁盘Disk_B将共同提供服务。

本实施例整体方案充分利用了底层磁盘同步和上层应用层同步的优点，就底层同步技术而言，全量的数据同步，技术成熟而稳定；而应用日志轻量级的传输，网络延时极小，灵活易配置。在保证了可靠的异地灾备介质的同时，又弥补了底层全量数据同步所带来的延时。应用级日志仅记录操作数据库时所发出的指令，而将最主要的数据处理和计算仍然放在了服务器端来进行，极大地减少了数据传输和处理量，是本发明的一个创新点。

以实际应用场景为例，应用服务器发起了一笔根据批次号进行批量更新指令的操作，应用级只记录下这条命令、参数及其执行结果即可；对应到数据库级别，可能涉及到多张表的数十条记录的插入和更新等，数据库级别归档日志需要对这10多张表的update、insert语句全部做记录和同步；磁盘级的同步需要扫描涉及到的数据文件的变动做同步。需要同步的数据量级别呈现依次增加的趋势。

从表1的对比分析中，也可以看出在各级别进行远程异地同步时各主要技术指标的差异：

表1：应用级别与数据库级、磁盘级的对比

本实施例中，应用级日志的设计与实现：

本实施例中应用日志功能所涉及的总体模块、子模块及其关系见图8所示。应用日志记录部分主要由日志生成模块、日志传输模块、日志存储模块等组成，应用日志恢复部分涉及日志恢复模块，另外，系统包含一个控制与设置模块。

1.日志生成模块位于总体结构的应用服务器端App服务器，用于在应用服务器程序访问数据库时，记录和生产访问数据库日志内容。所述日志生成模块包括：

日志生成控件子模块101，用于对原有应用程序调用数据库程序的控件加以改造，形成公用的日志生成控件，在访问数据库程序时，将相关调用内容额外记录下来。

日志格式化子模块102，根据之后设置子模块502的设置选项，将日志内容进行格式化。日志内容主要有：调用的数据库程序用户及对象名称、调用参数、执行结果等。各项内容以指定的大分隔符间隔，而多项参数及多个执行结果直接，以指定的小分隔符间隔；形成纯文本内容。

日志传输子模块103，负责将生成的文本内容发送给日志传输模块。

2.日志传输模块用于将应用服务器App生成的应用日志，发送至总体结构图中位于灾备中心的日志服务器AppLog。

异步传输队列子模块201，用于接收子模块103中传输的应用日志，并放入待发送的异步传输队列。异步传输队列位于应用服务器上，异步来保证不对正常的交易产生影响，并有发送超时和溢出等控制。

Socket连接子模块202，用于建立应用服务器的异步传输队列和远程日志服务器上的接收进程之间的网络连接和数据传输，基于TCP的连接保证了传输的可靠性。

3.日志存储模块位于服务器AppLog上，用于日志记录以及日志文件的管理。

日志文件写入子模块301，将接收到日志内容，及时写入应用服务器AppLog的指定文件中，日志文件以文本内容保存，单行记录对应一笔数据库操作。文件路径、文件大小、字符集格式等均可由系统设置子模块502来设置。

日志文件管理子模块302，由于日志文件主要用于灾备恢复，日常产生的日志文件仅保留最近时间段的即可，过期日志文件由文件管理功能进行归档或销毁。

日志空间重用子模块303，对于日志空间需要进行循环和重用，以避免日志文件占用过多的系统空间。

4.日志恢复模块用于在灾备恢复时，重新执行应用日志以恢复磁盘同步所带来的数据丢失。

灾备库连接子模块401：用于建立和维护灾备恢复时与灾备数据库的连接。

日志文件加载子模块402：首先需要从磁盘同步系统中获取到磁盘数据最后成功同步的时间点，现有磁盘复制技术此时间精度均可到毫米以内。根据此时间点，从日志存储模块中记录的日志文件加载同步中断之后所有的日志记录。

数据库日志重做子模块403：这个子模块是数据恢复的关键，根据子模块402中加载的记录，按照之前的执行顺序，依次对原主库上已成功执行的数据库操作，在灾备库进行重新执行，以恢复同步中断之后已处理的数据，并记录执行结果。

恢复结果校验子模块404：由于数据恢复的特殊性，需要对数据进行必要的校验。通过对子模块403的执行结果，以及日志中记录的原执行结果进行比较，实现校验的自动化，并对可疑结果提供报表和人工介入的渠道。

5.控制和设置模块用于对整个日志记录和恢复系统进行过程控制和系统设置，其包括以下多个子模块：

过程控制子模块501：实现日志记录过程的可控和可监视，通过可视化界面和报表等方式，展示系统运行状况，资源消耗，空间占用，统计指标分析等。

系统设置子模块502：主要用于设置日志记录和恢复功能相关的系统属性，包括日志格式分割字符、传输队列连接数、网络最大延迟、单个日志文件大小、日志总占用空间、日志保留周期等系统参数。

恢复级别设置子模块503：专门用于设置日志记录和恢复的级别，本发明可支持的设置级别从上至下主要有：

业务级：在应用级别记录和恢复日志的一大好处是可以做到应用业务层面的控制。考虑到灾备恢复的特殊场景，一般要求在很短的时间内完成恢复和重新提供服务(RTO要求尽量小)，全业务的数据补充恢复要求更多的核对校验时间，而要求对关键的核心业务做到PRO＝0的目标，以保证有限的资源充分用于保障核心业务的持续运行。在业务层可以设置仅针对某些核心业务启动日志记录或恢复功能，以进一步减少负载和恢复时的压力。而基于磁盘层或数据库层的恢复，很难做到业务层面的筛选和控制。

数据库级：可针对某几台数据库服务器上的操作启用该功能，用于过滤对业务运行无关紧要的日志库等的操作。

应用服务器级：可指定某几台关键服务器开启记日志功能。例如银行常见的联机和批量交易场景，分别运行于不同的应用服务器上，均有数据库操作。对于批量一般在单独的批量服务器运行，如果批量文件还在，整批可以重新运行。但对于联机交易服务器，可以重点恢复。应用服务器级设置可以根据应用服务器用途的不同加以区分。

系统级：在整个系统可以设置开关，用于控制日志记录和恢复功能的开启或关闭。

如图9所示，本发明实施例还公开了一种基于应用级日志的数据恢复方法，该方法包括两部分，其一为日常运行和备份部分，其二为灾难恢复部分，所述日常运行和备份部分包括：

步骤110：在生产系统，应用服务器通过数据库连接，对生产数据库进行了正常的一笔业务操作。

步骤120：日志功能模块在应用服务器操作完成时，生成应用级的数据库操作日志，并过日志传输模块将日志内容进行传输。

步骤121：灾备中心的应用日志服务器接收日志，并写入日志文件。并对日志文件进行管理，对超期文件归档。

步骤130：生产中心保存数据库文件的存储磁盘启动异地同步机制。

步骤131：灾备中心接收生产中心磁盘的异地灾备介质。

以上步骤为本实施例公开的系统日常的运行和备份操作，一旦灾难发生而导致生产中心无法对外提供服务时，启动以下应急灾难恢复操作。

所述灾难恢复部分包括：

步骤210：首先利用磁盘的异地灾备介质启动备份数据库。此时，由于磁盘异地同步的延迟，可能导致生产中心最新已经完成的一笔交易，尚未通过磁盘同步传输到灾备中心。

步骤220：应用日志传输的网络延迟几乎可以忽略，灾难发生前所完成的操作交易，其操作日志已传输至灾备中心的日志服务器上。根据灾备同步的最后成功时间，从日志服务器中恢复该时间点以来的所有操作日志。在生产中心已操作完成的交易，将通过重新执行日志内容，其丢失数据将得以恢复。

步骤230：数据恢复完成后，灾备的应用服务器可以重新连接数据库，并进行必要的数据和交易的校验。

步骤240：灾备中心完成以RPO＝0的指标对外提供应急服务。

本发明实施例所提出的方案和技术，在演练环境中的灾备恢复演练，可以实现预定的关键业务RPO＝0的恢复目标。同时，由于数据恢复的自动执行和校验，此项新技术的应用也大大地降低了RTO等指标。

本发明充分利用了底层磁盘级数据同步和应用级日志恢复的优点，将消耗资源的计算和处理等工作放在服务器上来进行，最大程度地减少了网络传输和延迟，减轻了对主生产的负担。在不明显增加现有系统压力的情况下，实现了异地灾备数据恢复零丢失的目标。相比较现有的技术而言，本发明的主要优点有：

1、网络资源占用量低，相比较数据库日志级的传输，应用级日志传输数据量要小一个数量级。因此带来网络传输数据量少，延时短。

2、对生产系统的影响小，底层HUR磁盘同步使用吸的方式，不占用生产系统的资源。应用日志产生数据量小，异步传输，最大程度减少了对生产系统的影响。同时，应用日志补数据机制的存在，可以降低对底层HUR磁盘同步的实时性要求。

3、可以做到业务级别的控制，目前大部分的灾备机制均实现在系统层或数据库层，进行全量数据的恢复。在灾备的特殊环境下，全量数据的处理和校验，带来了更大的恢复压力。应用级日志可以设置在针对特定的核心业务上，对核心业务交易数据进行无丢失的保障，将有限资源优先应用在核心业务上，增强了灾备恢复的灵活性和可操作性。

4、可跨平台的实现，本发明不依赖于具体的平台实现，可应用于目前大部分应用服务器-数据库CS架构的系统中。

5、易用性，日志的设置和恢复可实现图形化操作界面，恢复过程可进度化显示，恢复结果和日志等可图形化展示。

本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。