CN102752404A - 一种新型的灾难备份恢复方法与系统 - Google Patents
一种新型的灾难备份恢复方法与系统 Download PDFInfo
- Publication number
- CN102752404A CN102752404A CN2012102595690A CN201210259569A CN102752404A CN 102752404 A CN102752404 A CN 102752404A CN 2012102595690 A CN2012102595690 A CN 2012102595690A CN 201210259569 A CN201210259569 A CN 201210259569A CN 102752404 A CN102752404 A CN 102752404A
- Authority
- CN
- China
- Prior art keywords
- data
- communication data
- backup
- communication
- production system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000011084 recovery Methods 0.000 title claims abstract description 106
- 238000000034 method Methods 0.000 title claims abstract description 63
- 230000006854 communication Effects 0.000 claims abstract description 272
- 238000004891 communication Methods 0.000 claims abstract description 271
- 238000004519 manufacturing process Methods 0.000 claims abstract description 134
- 230000008859 change Effects 0.000 claims abstract description 17
- 230000010076 replication Effects 0.000 claims description 21
- 238000012545 processing Methods 0.000 claims description 14
- 238000005516 engineering process Methods 0.000 abstract description 45
- 230000007704 transition Effects 0.000 abstract 1
- 238000004458 analytical method Methods 0.000 description 18
- 230000006870 function Effects 0.000 description 16
- 238000004364 calculation method Methods 0.000 description 14
- 238000012546 transfer Methods 0.000 description 11
- 230000000875 corresponding effect Effects 0.000 description 10
- 230000005540 biological transmission Effects 0.000 description 8
- 230000000694 effects Effects 0.000 description 6
- 238000013461 design Methods 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 238000006243 chemical reaction Methods 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 241001269238 Data Species 0.000 description 3
- 101000953492 Homo sapiens Inositol hexakisphosphate and diphosphoinositol-pentakisphosphate kinase 1 Proteins 0.000 description 3
- 101000953488 Homo sapiens Inositol hexakisphosphate and diphosphoinositol-pentakisphosphate kinase 2 Proteins 0.000 description 3
- 102100037739 Inositol hexakisphosphate and diphosphoinositol-pentakisphosphate kinase 1 Human genes 0.000 description 3
- 102100037736 Inositol hexakisphosphate and diphosphoinositol-pentakisphosphate kinase 2 Human genes 0.000 description 3
- 238000010276 construction Methods 0.000 description 3
- 230000002596 correlated effect Effects 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 238000012544 monitoring process Methods 0.000 description 3
- 230000005622 photoelectricity Effects 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 101000926140 Homo sapiens Gem-associated protein 2 Proteins 0.000 description 2
- 101000716750 Homo sapiens Protein SCAF11 Proteins 0.000 description 2
- 101000723833 Homo sapiens Zinc finger E-box-binding homeobox 2 Proteins 0.000 description 2
- 102100020876 Protein SCAF11 Human genes 0.000 description 2
- 230000002354 daily effect Effects 0.000 description 2
- 230000002950 deficient Effects 0.000 description 2
- 238000011156 evaluation Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000013519 translation Methods 0.000 description 2
- 238000006424 Flood reaction Methods 0.000 description 1
- 235000009499 Vanilla fragrans Nutrition 0.000 description 1
- 244000263375 Vanilla tahitensis Species 0.000 description 1
- 235000012036 Vanilla tahitensis Nutrition 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 230000008521 reorganization Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明涉及一种新型的灾难备份恢复方法与系统，通过改变客户端和生产系统之间的通讯数据在网络中的流向，或者生产系统内部服务器之间的通讯数据在网络中的流向，使之必然绕经网络中的一个或者若干个通讯数据获取点，在通讯数据获取点将上述通讯数据截获，并将截获的数据存储在备份数据中心；生产系统还同时和灾难备份系统之间通过传统灾备手段进行异步数据复制；当生产数据中心发生灾难导致生产系统无法正常运转时，灾难备份系统将因为异步数据复制而丢失的数据，通过在通讯数据获取点截获的数据补全。本发明对应用架构基本无改动，可以实现平滑过渡，不增加现有系统的负担，解决了目前任何一种远程灾难备份恢复技术不能达到RPO=0的问题。
Description
技术领域
本发明涉及IT技术领域中灾难备份及恢复，具体说是一种新型的灾难备份恢复方法与系统。
背景技术
目前IT技术领域中主要灾难备份恢复技术有如下几种：
1．数据备份
数据备份可以对数据实现某一时间点的完整拷贝，但该某一时间点的完整拷贝得到的备份数据处在非在线状态，不能被立刻访问，必须通过相应操作，如数据恢复等方式使用该备份数据。这种方式，恢复时间长，而且备份数据不能保证是最新的，不适合作为关键业务系统的主要灾难备份恢复措施。
2．数据复制（Replication）
数据复制（Replication）是将一个原数据及其改动，通过后续机制拷贝到另外一处，所述另外一处可以是另一个磁盘、另一个阵列、另一个服务器或另一个数据中心。数据复制技术可以用在生产数据中心的生产系统和备份数据中心的灾难备份系统间，也可以用在同一个数据中心的主用和备用系统间。
数据复制可进一步细分为：应用复制技术、中间件数据复制、数据库数据复制、存储管理软件数据复制（卷复制）、存储硬件数据复制。
2.1应用复制技术
应用复制技术是由应用软件来实现数据的复制和同步，当生产数据中心失效时，备份数据中心的应用软件系统恢复运行，接管生产数据中心的业务。所述的生产数据中心和备份数据中心是指分别容纳生产系统和灾难备份系统的设施（比如建筑物），生产系统和灾难备份系统是从事生产任务和灾备任务的计算机系统；一套生产系统可以存在多个生产数据中心，一个生产数据中心也可以有多套生产系统。
应用复制技术的缺陷在于：
? 对应用改动极大，且应用每次更新都要考虑灾备，应用维护的难度极大；
? 不同的应用要做不同的设计，不是一个通用的技术，兼容性差；
应用复制技术由于复杂性高、兼容性差，选择使用该方案的用户极少。
2.2中间件数据复制
中间件数据复制，是通过安装在数据库和应用软件上的代理程序对数据库进行监控，如果数据库中的数据发生变化，就将该变化利用数据库发布功能传递给具备接收数据库发布能力的灾难备份端代理，再由灾难备份端代理通过数据库接口将接收到的数据输入备用数据库。
2.3数据库数据复制
数据库数据复制技术是由数据库系统软件来实现数据库的远程复制和同步。基于数据库的复制方式可分为实时复制、定时复制和存储转发复制，并且在复制过程中，还有自动冲突检测和解决的手段，以保证数据一致性不受破坏。
2.4存储管理软件数据复制
存储管理软件数据复制，又称为卷复制，存储管理软件利用镜像工具或数据复制软件，将生产系统的本地数据同步或异步写到灾难备份系统（尤指远程灾难备份系统）。采用这种方式与应用软件和存储无关，可实现异构存储且不需修改应用软件，缺点是需要更改底层存储卷结构，存储架构变更产生的数据迁移会对生产系统带来较大影响。
2.5存储硬件数据复制
存储硬件数据复制技术是目前相当成熟的灾难备份恢复技术，通过存储硬件数据复制，可以实现生产系统和灾难备份系统的操作系统、文件系统、数据库的同步，且不占用主机资源。
中间件数据复制、数据库数据复制、存储管理软件数据复制、存储硬件数据复制等的复制，都可以分成同步数据复制和异步数据复制两种。
异步数据复制是指灾难备份系统（尤指远程灾难备份系统）在更新数据（备份数据）前，生产系统上的数据（业务数据）的基本操作已经完成的一种数据复制技术。将业务数据复制到远程的备份数据是以后台复制的方式进行的，这使设置在生产数据中心的生产系统性能受到的影响很小，传输距离长（可达1000公里以上），对网络带宽要求小。由于异步数据复制不需要等到远程灾难备份系统的存储系统的确认，生产系统的I/O（输入/输出）已经完成读写操作，所以当发生灾难的时候，备份数据中心的备份数据不一定是和生产数据中心的业务数据是一致的，即RPO（Recovery Point Objective 即业务数据恢复点目标）不能等于0，这是这种灾难备份恢复技术的重要缺陷，即当灾难发生的时候，业务数据将会丢失。
同步数据复制是指设置在备份数据中心的灾难备份系统将设置在生产数据中心的生产系统的数据（业务数据）以完全同步的方式复制到灾难备份系统，每一生产系统的I/O（输入/输出）事务均需等待远程的灾难备份系统提供复制完成确认信息，方予以释放。同步数据复制使备份数据中心的备份数据总能与生产数据中心的业务数据相匹配。当生产系统的主站点出现故障时，可以保证业务继续执行而没有数据的丢失。但同步数据复制存在往返传播造成延时较长的缺点，只限于在相对较近的距离上应用。
采用同步数据复制方式时，生产系统必须等到数据成功的写到灾难备份系统，才能进行下一个I/O（输入/输出）操作。一个I/O（输入/输出）通过远程链路写到灾难备份系统，涉及到三个技术参数：带宽、距离和中间设备及协议转换的时延。由于带宽可以随着投入增加而增加，所以我们忽略这个因素的影响，以下只讨论距离和中间设备及协议转换的时延对同步数据复制技术的影响：
光和电波在线路上传输的速度是30万公里/秒，当距离很长时，这种线路上的延时将会变得很明显。例如：对比灾难备份系统与生产系统均设置在生产数据中心本地和生产数据中心与备份数据中心间距离1000KM的两种情况。假设，生产系统数据库写盘的数据块大小是10KB（一次I/O的数据量），那么：
当灾难备份系统就在生产数据中心本地时，如100米距离内，
光电在线路上的延时=0.1km/300000km=0.334*10^-6秒
1秒钟内允许I/O（输入/输出）次=1/（（0.334*10^-6）*2）=1.5*10^6次
1秒钟允许的I/O（输入/输出）量=10KB*1.5*10^6=15GB
可见，光电在100米距离的线路上的延时对性能的影响可以忽略不计。
当灾难备份系统在距离生产数据中心1000公里的备份数据中心时，在1000公里的距离上，光电的传输时延加上中间设备及协议转换的时延约为10～15毫秒左右。
1秒钟内允许I/O（输入/输出）次=1/（15*2） *1000～1/（10*2） *1000=30～50次
1秒钟允许的I/O（输入/输出）量=10KB*（30～50）＝0.3MB～0.5 MB
假设某业务的生产系统每日做批处理需要串行改写100GB的数据，如果灾难备份系统在生产数据中心本地的话，由于灾备而需要额外增加的时间几乎可以忽略。但是，如果备份数据中心在1000公里以外的异地，那额外的增加的时间就约为 100G*1000/0.5=20万秒＝55.56小时，完全不能忍受了，系统几乎不能正常运行。
综上所述，目前没有一套灾难备份恢复技术及系统可以较好的解决远程灾备方案中，数据不丢失的问题，即RPO=0的问题，当发生灾难性事故的时候，灾难备份系统内的数据不能保证不丢失。
发明内容
针对现有技术中存在的缺陷，本发明的目的在于提供一种新型的灾难备份恢复方法与系统，在网络中设置一个或者若干个通讯数据获取点，并在通讯数据获取点截获客户端和生产系统之间的通讯数据，或在通讯数据获取点截获生产系统内部服务器之间的通讯数据，并将获取的数据存储在备份数据中心；当生产数据中心发生灾难导致生产系统无法正常运转时，用这些在通讯数据获取点上获取的数据来恢复灾难备份系统因异步数据复制而丢失的那部份数据，从而从根本上解决目前无论哪种技术在远程灾难备份恢复方面都存在数据丢失的情况，实现RPO=0。
为达到以上目的，本发明采取的技术方案是：
一种新型的灾难备份恢复方法，其特征在于：在网络中设置一个或者若干个通讯数据获取点，
在通讯数据获取点截获客户端和生产系统之间的通讯数据，并将获取的通讯数据存储在备份数据中心；
或在通讯数据获取点截获生产系统内部服务器之间的通讯数据，并将获取的通讯数据存储在备份数据中心；
同时，所述生产数据中心中的生产系统还同时和备份数据中心中的灾难备份系统之间通过传统灾备手段进行异步数据复制；
当生产数据中心发生灾难导致生产系统无法正常运转时，用在通讯数据获取点上获取的通讯数据来恢复灾难备份系统因异步数据复制而丢失的业务数据。
在上述技术方案的基础上，当客户端和生产系统进行数据通讯以处理业务数据时，通过改变客户端和生产系统之间的通讯数据在网络中的流向，使客户端和生产系统之间的通讯数据必然绕经网络中的一个或者若干个通讯数据获取点，使在通讯数据获取点能截获客户端和生产系统之间的通讯数据；
或当生产系统内部各个服务器进行数据通讯以处理业务数据时，改变生产系统内部服务器之间的通讯数据在网络中的流向，使生产系统各个服务器之间的通讯数据必然绕经网络中的一个或者若干个通讯数据获取点，使在通讯数据获取点能截获生产系统内部服务器之间的通讯数据。
在上述技术方案的基础上，通讯数据获取点所在的地理位置的选取原则为：在能够接受的概率下，通讯数据获取点所在的地理位置位于不会和生产数据中心同时受到某种灾难的影响的地区。
在上述技术方案的基础上，当将通讯数据获取点所处的地理位置距离生产数据中心的远近，作为影响能够接受的概率的唯一因素时，且生产数据中心到备份数据中心之间的距离为能够接受的最小灾备距离时，则：以生产数据中心为圆心，以生产数据中心到备份数据中心之间的距离为半径画一个圆，在圆上和圆外的任何一个有网络通过的地区，均能作为设置通讯数据获取点的地区。
在上述技术方案的基础上，当生产数据中心到备份数据中心之间的距离为能够接受的最小灾备距离时，将通讯数据获取点设置在备份数据中心。
在上述技术方案的基础上，采取改变网络路由的方法，使通讯数据必然绕经一个或者若干个通讯数据获取点。
在上述技术方案的基础上，通过改变网络拓扑结构的方法，使通讯数据必然绕经一个或者若干个通讯数据获取点。
在上述技术方案的基础上，通过将应用服务器安装在通讯数据获取点的所处的地点，或通过设置应用服务器的通讯代理，或通过设置生产系统其他服务器的通讯代理，并调整这些通讯代理在网络中的位置，来改变通讯双方的通讯数据在网络中流向，使通讯数据必然绕经一个或者若干个通讯数据获取点。
一种新型的灾难备份恢复系统，包括：生产数据中心和备份数据中心，生产数据中心设有生产系统，备份数据中心设有灾难备份系统，其特征在于：网络中设有至少一个通讯数据获取点，在该通讯数据获取点将客户端和生产系统之间的通讯数据截获，或将生产系统内部服务器之间的通讯数据截获，并将截获的数据发往并存储到备份数据中心。
本发明所述的新型的灾难备份恢复方法与系统，在网络中设置一个或者若干个通讯数据获取点，并在通讯数据获取点截获客户端和生产系统之间的通讯数据，或在通讯数据获取点截获生产系统内部服务器之间的通讯数据，并将获取的数据存储在备份数据中心；当生产数据中心发生灾难导致生产系统无法正常运转时，用这些在通讯数据获取点上获取的数据来恢复灾难备份系统因异步数据复制而丢失的那部份数据，从而从根本上解决目前无论哪种技术在远程灾难备份恢复方面都存在数据丢失的情况，实现RPO=0。其技术优点如下：
优点1：解决了目前任何一种远程（比如1000KM以上）灾难备份恢复技术不能达到RPO=0的问题。
优点2：方案对应用架构基本无改动，可以实现平滑过渡。
优点3：不增加现有系统的负担。
附图说明
本发明有如下附图：
图1 目前常见生产及灾难备份系统架构示意图
图2 核心思想实现示意图
图3 策略路由或路由策略实例下灾难备份恢复的一种常见实施方案示意图
图4 策略路由或路由策略实例下灾难发生时数据流向示意图
图5 网络汇聚中心实例下灾难备份恢复的一种常见实施方案示意图
图6 网络汇聚中心实例下灾难发生时数据流向示意图
图7 通讯代理实例下灾难备份恢复的一种常见实施方案示意图
图8 通讯代理实例下灾难发生时数据流向示意图。
具体实施方式
以下结合附图对本发明作进一步详细说明。
目前常见的生产及灾难备份系统架构如图1所示，其中包含：客户端，位于生产数据中心的生产系统和位于备份数据中心的灾难备份系统。客户端分别与生产系统和灾难备份系统通过网络相连。由于不可能穷举所有的生产及灾难备份系统架构，故图1仅仅展示了一种常见的生产及灾难备份系统架构，并不代表本发明只能适用于此种架构。例如：有的生产系统中，没有应用服务器，没有数据库服务器，而是只有集成应用、数据库功能的“服务器”，或者有多种类型的不同的应用服务器，或者有些系统不把应用服务器叫应用服务器，而是叫前置服务器，卫星服务器等。都可以用本发明的方法来达到技术目的。
所述生产系统和灾难备份系统一般均包括：应用服务器，数据库服务器，存储系统，还可以根据实际需要选择性的增设负载均衡器或WEB服务器。为简化讨论，下文中所有的讨论，均做出以下假设：
1. 假设不存在WEB服务器，即默认生产数据中心及备份数据中心未增设WEB服务器；
2. 假设客户端和生产系统之间通讯，只存在在客户端和应用服务器之间；生产系统内部的网络通讯只存在在应用服务器和数据库服务器之间；
3. 假设整个通讯过程是用以下形式进行的：由客户端发起通讯，至应用服务器，再由应用服务器发至数据库服务器，最终由数据库服务器发至存储系统，并再逐级返回至客户端。
4. 生产系统只存在在一个生产数据中心中，灾难备份系统只存在在一个备份数据中心中。
上述这些假设，只是为了说明问题方便，并不代表本发明只能适用于这样的系统架构或者通讯模式。
以银行的交易系统举例，假设由客户端发起一笔由账户A转账1000元到账户B的转账交易。该转账交易的业务数据中至少包括：账户A的账号，账户A的转账密码，账户B的账号，转账交易流水号，转账交易金额等信息，业务数据的数据包的大小约1KB。该转账交易的业务数据由客户端发给生产系统的应用服务器后，生产系统的应用服务器至少要做以下操作：
查询账户A的转账密码是否正确，查询账户A是否有足够的余额，查询账户A是否允许转账，记录转账交易，记录通讯日志等。
上述操作期间，生产系统的应用服务器要和生产系统的数据库服务器通讯几次到几十次，通讯量放大了多倍。而生产系统的数据库服务器在上述操作期间可能要更新几张到十几张表，每张表的更新都会引起多次生产系统的数据库服务器和生产系统的存储系统之间的I/O通讯，同时生产系统的数据库服务器还要记录数据库日志，也会引起多次和生产系统的存储系统之间的I/O通讯。
由上述可见，一笔在客户端和生产系统的应用服务器之间一个来回的数据通讯，在生产系统的应用服务器和生产系统的数据库服务器之间被放大成了多次来回往复的数据通讯，在生产系统的数据库服务器和生产系统的存储系统之间的数据通讯又将被再次放大几倍。
很显然，如果要实现RPO=0，即不丢失数据的灾难备份恢复技术，该灾难备份恢复技术必须保证将交易内容和结果传送到备份数据中心中的灾难备份系统，同时还要保证即使生产数据中心发生了任何故障，都不能丢失数据。
分析上述假设的转账交易过程不难发现，客户端和生产系统的应用服务器之间的数据通讯次数和产生的通讯数据的数据量都是整个转账交易过程中最小的，因此，本发明的核心思想就是：
改变客户端和生产系统的应用服务器之间的通讯数据在网络中的流向，使之必然绕经网络中的通讯数据获取点，在通讯数据获取点上截获客户端和生产系统的应用服务器之间的通讯数据，并将截获的通讯数据复制到备份数据中心记录下来，就能在对交易性能影响最小的情况下实现RPO=0，即灾难备份恢复数据不丢失。所以，下述的讨论中，将主要就怎么改变客户端和生产系统的应用服务器之间的通讯数据在网络中的流向，使之必然绕经通讯数据获取点做讨论和说明。
当然，改变生产系统内部服务器之间（比如应用服务器和数据库服务器之间）的通讯数据在网络中的流向，也能达到类似的目的，但由于生产系统内部服务器之间的数据通讯次数和产生的通讯数据的数据量较大，效果则较差。而且，用以改变客户端和生产系统的应用服务器之间的通讯数据在网路中流向的方法，也可同样运用于改变生产系统内部服务器之间的通讯数据在网络中的流向，所以下文不再单独针对改变生产系统内部服务器之间的通讯数据在网络中的流向做详述。
如图2所示，本发明所述的新型的灾难备份恢复方法，在网络中设置一个或者若干个通讯数据获取点，
在通讯数据获取点截获客户端和生产系统之间的通讯数据，并将获取的通讯数据存储在备份数据中心；
或在通讯数据获取点截获生产系统内部服务器之间的通讯数据，并将获取的通讯数据存储在备份数据中心；
同时，所述生产数据中心中的生产系统还同时和备份数据中心中的灾难备份系统之间通过传统灾备手段进行异步数据复制，例如：通过数据库、中间件或者存储系统等进行异步数据复制；
当生产数据中心发生灾难导致生产系统无法正常运转时，用在通讯数据获取点上获取的通讯数据来恢复灾难备份系统因异步数据复制而丢失的业务数据。
即：用在通讯数据获取点获取的数据（通讯数据）来恢复（补全）备份数据中心中灾难备份系统因异步数据复制丢失的那部份数据。例如：假设异步数据复制方式能保证的RPO为5分钟，即生产系统最后5分钟的数据丢失了，而在通讯数据获取点上获取的通讯数据中，含有客户端通讯请求和生产系统对该通讯请求如何回复的信息，我们可以用在通讯数据获取点获取的最后5分钟的通讯数据，经过分析和重组后，自动恢复这5分钟之内的业务数据，从而做到RPO=0。
应当注意的是：无论通讯数据获取点在哪里获取通讯数据，所截获的通讯数据一般均应为双向的通讯数据，例如：在客户端和生产系统的应用服务器之间的网络截获通讯数据，则包括：客户端发往生产系统的应用服务器的通讯数据（客户端通讯请求的内容），以及生产系统的应用服务器发往客户端的通讯数据（应用服务器针对客户端通讯请求给出的通讯回复的内容）。
在上述技术方案的基础上，当客户端和生产系统进行数据通讯以处理业务数据时，通过改变客户端和生产系统之间的通讯数据在网络中的流向，使客户端和生产系统之间的通讯数据必然绕经网络中的一个或者若干个通讯数据获取点，使在通讯数据获取点能截获客户端和生产系统之间的通讯数据；
或当生产系统内部各个服务器进行数据通讯以处理业务数据时，改变生产系统内部服务器之间的通讯数据在网络中的流向，使生产系统各个服务器之间的通讯数据必然绕经网络中的一个或者若干个通讯数据获取点，使在通讯数据获取点能截获生产系统内部服务器之间的通讯数据。
通讯数据绕经“若干个通讯数据获取点”的优点，至少可以体现在以下场景中：首先，复杂的系统，通讯不会发生在一个客户端和一个应用服务器之间，可以发生在几万个客户端和几百台应用服务器之间，如果用一个通讯数据获取点，实施中就不会获取好的效果，可以通过设置多个通讯数据获取点的方法，按照一定的规则分流数据，达到较好的效果。另外，如果只用一个通讯数据获取点，当通讯数据获取点失效后，本发明要到达的目的会失效，所以可以多备几个通讯数据获取点。
在上述技术方案的基础上，通讯数据获取点所在的地理位置的选取原则为：在能够接受的概率下，通讯数据获取点所在的地理位置位于不会和生产数据中心同时受到某种灾难的影响的地区。
因为绝对避免物理上的两个不同地区不受某种灾难的同时影响是不可能的，所以具体地区的选取是在可以接受的概率下进行选择，例如生产数据中心在中国，通讯数据获取点在美国，则二者同时受到某种灾难的影响概率就很低了，属于可以接受的概率。所述某种灾难是指战争、火灾、水灾或地震等。
在上述技术方案的基础上，当将通讯数据获取点所处的地理位置距离生产数据中心的远近，作为影响能够接受的概率的唯一因素时（即：将通讯数据获取点所处的地理位置距离生产数据中心的远近作为通讯数据获取点避免和生产数据中心同时受到某种灾难影响的唯一因素），且生产数据中心到备份数据中心之间的距离为能够接受的最小灾备距离时，则：以生产数据中心为圆心，以生产数据中心到备份数据中心之间的距离为半径画一个圆，在圆上和圆外的任何一个有网络通过的地区，均能作为设置通讯数据获取点的地区。
当然除距离以外，在实际实施中根据需求的不同还必须考虑其他因素，因为超出了本发明内容，不再讨论。
很显然，当生产数据中心到备份数据中心之间的距离为能够接受的最小灾备距离时，备份数据中心所处的地理位置本身就满足设置通讯数据获取点的条件，为了便于技术实施和降低成本，我们可以选择将通讯数据获取点设置在备份数据中心，当然也可以选择在其他满足条件的地区设置通讯数据获取点，下文中提到的“网络汇聚中心”，就是不在备份数据中心设置通讯数据获取点的实例。
为了使通讯数据（指客户端和生产系统的应用服务器之间的通讯数据，或生产系统内部服务器之间的通讯数据）必然绕经通讯数据获取点，可选择的方案有以下几种：
1、可采取改变网络路由的方法。如可以通过设置路由策略或策略路由来改变路由，为便于描述，下文中将以在备份数据中心中设置通讯数据获取点来举例。
2、通过改变网络拓扑结构的方法，使通讯数据必然绕经一个或者若干个通讯数据获取点。如在通讯数据获取点所处的地点上设置网络汇聚中心，物理上让客户端首先经过网络接入网络汇聚中心，再由网络汇聚中心接入生产数据中心，下文中也将举例。
3、通过将生产系统的应用服务器安装在通讯数据获取点的所处的地点，或者通过设置应用服务器的通讯代理（例如：在通讯数据获取点的所处的地点安装生产系统的应用服务器的通讯代理），或通过设置生产系统其他服务器（比如数据库服务器）的通讯代理，并调整这些通讯代理在网络中的位置，来改变通讯双方的通讯数据在网络中流向，使通讯数据必然绕经一个或者若干个通讯数据获取点。
本发明中所说的“通讯代理”是指可以实现以下功能的一切软硬件设备：通过合理设置通讯双方和“通讯代理”，可以让原本由一方发起直接访问另一方的通讯数据，转而先发往另一方的“通讯代理”，再由另一方的“通讯代理”将通讯数据转发给另一方，使通讯双方通过“通讯代理”的通讯，等效于通讯双方直接的通讯。比如：负载均衡器，通讯代理服务器，带有地址转换功能的防火墙，路由器等通过合理的设置，均可以充当本发明所说的“通讯代理”，当然也可以是专门开发的有此功能的软硬件产品，下文以负载均衡器为例予以说明。为便于说明问题，实例中将通讯数据获取点所处的地点设置在备份数据中心。
上述方法，可以归结为：可通过改变路由、网络拓扑，或通过改变通讯双方中一方或双方在网络中的位置，又或通过为通讯的双方中的一方或双方设置“通讯代理”，并调整“通讯代理”在网络中的位置，来改变通讯双方的通讯数据在网络中流向，使通讯数据必然通过网络中的某些特定的区域（如通讯数据获取点）。这个方法是有一定普遍适用性的，可以用来改变生产系统内部服务器之间的通讯数据的流向，使之必然通过通讯数据获取点。但利用生产系统内部服务器之间的通讯数据来达到本发明的目的，效果可能较差，且方法类似，故下文不再详述。
客户端和生产系统的应用服务器间的通讯绕行通讯数据获取点，可能会带来每千公里几十毫秒的通讯延迟开销，但考虑到大多数交易的忍受时间都可以长达数秒到数十秒，所以相关开销可以忽略不计。事实上，一般交易系统都是支持远程的客户端进行交易的，比如应用服务器位于上海的生产数据中心中，无论客户端是从上海本地访问应用服务器，或者通过网络在北京甚至国外访问应用服务器，应用都应该正常运行，虽然从北京或者国外访问会比在上海本地访问多几十到几百毫秒的通讯延迟开销。综上，显然将通讯绕行通讯数据获取点不会对交易及交易系统产生重大影响。
在通讯数据获取点截获并记录下来的通讯内容和结果来补录交易或者临时冻结相关的交易账户，需要按照不同的应用来开发不同的补录接口，同时批处理修改的数据仍然需要通过异步方式来传输，所以应用系统的批处理必须要能做到断点重入，但显然这种补录接口和批处理的断点重入的复杂性是可控的，要远远优于传统的基于应用的灾备方式，可以广泛的使用。复杂性可控的原因是，绝大部分数据仍然是通过“备份数据中心和生产数据中心之间通过传统灾备手段进行异步数据复制”的现有技术复制到备份数据中心的，本发明给出的方案仅仅需要补录丢失的最后几分钟的交易数据，使补录的复杂性极大的下降。同时，即使不发生灾难事件，批处理也可能由于应用、操作或者系统软件的出错中断，所以支持断点重入的批处理作业是严谨的应用必须具备的。综上，自动补录最后几分钟的交易，批处理作业需要支持断点重入等不会造成该方案实施难度过大。
根据上述方法，本发明还给出了一种应用该方法的新型的灾难备份恢复系统，包括：生产数据中心和备份数据中心，生产数据中心设有生产系统，备份数据中心设有灾难备份系统，在网络中设有至少一个通讯数据获取点，所述通讯数据获取点用于截获客户端和生产系统之间的通讯数据，或截获生产系统内部服务器之间的通讯数据；即：在该通讯数据获取点将客户端和生产系统之间的通讯数据截获，或将生产系统内部服务器之间的通讯数据截获，并将截获的数据发往并存储到备份数据中心。
上述为本发明的核心思想和方法，下面是一些具体实现的技术实例：
1通过策略路由或路由策略使数据流绕行备份数据中心的实例
1.1 基本思路
备份数据中心所处的地点，满足设置通讯数据获取点的条件。通过策略路由或路由策略控制客户端和应用服务器间的通讯数据流，使之流向备份数据中心，然后再流回生产数据中心。当数据流经备份数据中心的时候，通过镜像、分光复制等方法复制所有的通讯数据，存储在数据库中。同时使用传统灾备技术如数据库数据复制技术等，进行生产数据中心和备份数据中心间的数据复制，当灾难发生的时候，通过数据补录程序，提取之前存储的数据，将传统灾备技术由于技术限制不能弥补的数据差补录回来，实现RPO=0。
实现办法
遵循上述的基本思路，可以通过交换模块、数据流绕行模块、数据获取模块、协议分析和存储模块，数据追平模块构建整个数据恢复系统，下文简称为“数恢系统”，实现RPO=0。各模块目前基本均有成熟的技术或产品，比如可以用三层交换机同时充当交换模块、数据绕行模块和数据获取模块，可以用通讯嗅探器（SNIFFER）充当协议分析和存储模块，当然也可以为实现各模块功能自行开发产品。“数恢系统”及其组成模块，仅仅是为了说明而举的实例，并不表示系统必须或只能按此设计，各模块详细的功能如下：
1.2.1 交换模块
该模块对数据进行简单的交换和转发。
数据流绕行模块
在本实例中，该模块利用策略路由或路由策略控制客户端和应用服务器间的通讯数据的流向，使之必然流经备份数据中心。路由或者路由表可以简单理解为通讯数据在网络中流动需要依据的地图或者路标。路由策略是指使用某种策略影响路由发布、接收或路由选择的参数最终改变路由内容的一种方法。设置静态路由也可以看作是一种路由策略。通过路由策略，可以控制通讯数据在网络中的流向。策略路由是一种比基于目标网络地址进行路由更加灵活的数据包路由转发机制。策略路由可以根据通讯数据包的目的地址来进行的路由，也可以根据通讯数据包的源地址，或者根据其他条件来进行路由。显然，通过策略路由也可以控制通讯数据在网络中的流向。
数据获取模块
该模块可以利用SPAN、RSPAN或者分光复制等成熟的技术来获取通讯数据流的内容，也可以通过自行开发有相应功能的软硬件来实现。
SPAN技术目前主要是用来监控交换机上的数据流，大体分为两种类型，本地SPAN和远程SPAN.----Local Switched Port Analyzer （SPAN） and Remote SPAN （RSPAN），实现方法上稍有不同。利用SPAN技术我们可以把交换机上某些想要被监控端口（以下简称受控端口）的数据流COPY或MIRROR一份，发送给连接在监控端口上的流量分析仪。
协议分析和存储模块
该模块可以利用成熟的协议分析器对取得的数据流进行解包分析，并将相关解包数据存储到专门的数据库中，也可以用自行开发的软硬件，实现对数据的解包和存储。
数据追平模块
该模块在灾难发生时，利用专门开发的数据补录程序将协议分析和存储模块数据库中的数据补录回备份数据中心的灾难备份系统中，实现RPO=0。
实现细节
如图3所示，生产数据中心和备份数据中心各配置一套数恢系统，也可以在每个生产数据中心内部设置两套数恢系统互为主备关系，当主用数恢系统出现故障的时候，可以切换到备用数恢系统。
通过路由策略或者策略路由改变通讯数据流的方向，是非常成熟的技术，在各类网络设备上都有大量使用，有无法穷举的各种方案，如下为一举例：
将数恢系统放置在生产数据中心中客户端和应用服务器间通讯流必须经过的网络路径上，在生产数据中心和备份数据中心的数恢系统上启用数据绕行模块，当通讯数据在进入生产数据中心数恢系统端口时，在该端口或相应vlan的svi接口下设置策略路由，策略路由的下一跳指向备份数据中心数恢系统的ip地址；同时在备份数据中心数恢系统的端口或相应vlan的svi接口上设置策略路由，策略路由的下一跳指向生产数据中心数恢系统，这样通讯数据就会绕行备份数据中心，同时在备份数据中心数恢系统上启用数据获取模块，假设数据获取模块使用的是span技术，可以将span 会话的源端口为该数据流入备份数据中心数恢系统的端口，目的端口为备份数据中心数恢系统的任意空闲端口，同时启动协议分析和存储模块，将流经的数据进行解包并储存；同理在当数据流返回时，在生产数据中心数恢系统流入端口，设置类似的策略路由，保证数据原路返回，并获取相应的通讯数据。
这样，本来应该直接由客户端访问生产数据中心的数据流将改变如下：客户端—>生产数据中心的数恢系统—>备份数据中心的数恢系统—>生产数据中心的数恢系统—>生产数据中心的应用服务器—>生产数据中心的数据库服务器—>生产数据中心的存储，并且原路返回客户端。
当灾难发生的时候，如图4所示，由于传统灾难备份恢复技术的限制，生产数据中心和备份数据中心的数据是不一致的，这时我们应启动备份数据中心数恢系统的数据追平模块，提取之前存储的通讯数据，来弥补生产数据中心和备份数据中心间的数据差，实现RPO=0。 等数据差弥补完毕后，客户端即可访问备份数据中心的应用服务器，而由备份数据中心的应用服务器再访问备份数据中心的数据库服务器和存储，从而使业务中断得以恢复。
通过网络汇聚中心使数据流绕行的实例
2.1 基本思路。
客户端的网络不直接接入生产数据中心，而是先接入一个或多个位于满足设置通讯数据获取点条件的网络汇聚中心，网络汇聚中心再通过网络连接生产数据中心和备份数据中心，这样客户端和生产数据中心的应用服务器的通讯自然就会经过网络汇聚中心，只要在网络汇聚中心获取客户端和应用服务器间的通讯数据，并发送给备份数据中心的数据收集服务器，并由其存储起来；同时使用传统灾备技术如数据库数据复制技术等，进行生产数据中心和备份数据中心间的数据复制，当灾难发生的时候，通过数据补录程序，提取之前存储的数据，将传统灾备技术由于技术限制不能弥补的数据差补录回来，实现RPO=0。
实现办法。
如图5所示，遵循上述的基本思路，我们将在网络汇聚中心获取数据并发送至备份数据中心的系统称为数据恢复系统前端，简称数恢系统前端；将在备份数据中心接收各个网络汇聚中心中数恢系统前端发送的通讯数据，并存储下来，等灾难发生时，使用存储的数据来恢复业务的系统称为数据恢复系统后端，简称数恢系统后端；数恢系统前端和后端共同组成数恢系统。可通过交换模块、数据获取模块与数据发送模块构建数恢系统前端，通过交换模块、数据接收模块、协议分析模块和存储模块、数据追平模块构建数恢系统后端。各模块目前基本均有成熟的技术或产品，比如可以用三层交换机同时充当交换模块、数据获取模块，数据发送模块和接收模块，可以用通讯嗅探器（SNIFFER）充当协议分析和存储模块，当然也可以为实现各模块功能自行开发产品。“数恢系统”以及其组成模块，仅仅是为了说明而举的实例，并不表示系统必须或只能按此设计，各模块详细的功能如下：
2.2.1 交换模块
对数据进行简单的交换和转发。
数据发送模块
指可以将获取的数据向指定网络地址发送的软硬件。
数据接收模块
指可以接收数据发送模块发送来数据的软硬件。
数据获取模块
该模块可以利用SPAN、RSPAN或者分光复制等成熟的技术来获取通讯数据流的内容，也可以通过自行开发有相应功能的软硬件来实现。
SPAN技术目前主要是用来监控交换机上的数据流，大体分为两种类型，本地SPAN和远程SPAN.----Local Switched Port Analyzer （SPAN） and Remote SPAN （RSPAN），实现方法上稍有不同。利用SPAN技术我们可以把交换机上某些想要被监控端口（以下简称受控端口）的数据流COPY或MIRROR一份，发送给连接在监控端口上的流量分析仪。
协议分析和存储模块
该模块可以利用成熟的协议分析器对取得的数据流进行解包分析，并将相关解包数据存储到专门的数据库中，也可以用自行开发的软硬件，实现对数据的解包和存储。
数据追平模块
该模块在灾难发生时，利用专门开发的数据补录程序将协议分析和存储模块数据库中的数据补录回备份数据中心的灾难备份系统中，实现RPO=0。
实现细节
如图5所示，可以在备份数据中心内部设置两套数恢系统后端互为主备关系，当主用数恢系统后端出现故障的时候，可以切换到备用数恢系统后端。
将数恢系统前端放置在网络汇聚中心中客户端和应用服务器间通讯流必须经过的网络路径上，数恢系统前端上启用数据获取模块，假设数据获取模块使用的是span技术，可以将span 会话的源端口为该数据流入备份数据中心数恢系统的端口，目的端口为数恢系统后端的任意空闲端口，同时启动数据发送模块，将获取的通讯数据发送到位于备份数据中心的数恢系统后端数据接收模块，数恢系统后端同时启动协议分析和存储模块，将接收到数据包进行解包并储存。当灾难发生的时候，如图6所示，由于传统灾难备份恢复技术的限制，生产数据中心和备份数据中心的数据是不一致的，这时我们应启动备份数据中心数恢系统后端的数据追平模块，提取之前存储的通讯数据，来弥补生产数据中心和备份数据中心间的数据差，实现RPO=0。待数据差弥补完毕后，客户端即可访问备份数据中心的应用服务器，而由备份数据中心的应用服务器再访问备份数据中心的数据库服务器和存储，从而使业务中断得以恢复。
通过通讯代理使数据流绕行备份数据中心的实例
3.1 基本思路
备份数据中心所处的地点，满足设置通讯数据获取点的条件。通过在备份数据中心放置“通讯代理”，合理配置客户端、“通讯代理”和应用服务器，使得客户端与生产数据中心的应用服务器的访问变成客户端首先访问备份数据中心的“通讯代理”，再访问生产数据中心的应用服务器，这样所有客户端与应用服务器之间的数据都将流经备份数据中心。当数据流经备份数据中心的时候，通过镜像、分光复制等方法复制所有的通讯数据，存储在数据库中。同时使用传统灾备技术如数据库数据复制技术等，进行生产数据中心和备份数据中心间的数据复制，当灾难发生的时候，通过数据补录程序，提取之前存储的数据，将传统灾备技术由于技术限制不能弥补的数据差补录回来，实现RPO=0。
实现办法
遵循上述的基本思路，可以通过交换模块、通讯代理模块、数据获取模块、协议分析和存储模块，数据追平模块构建整个数据恢复系统下文称“数恢系统”。各模块目前基本均有成熟的技术或产品，比如可以用三层交换机同时充当交换模块和数据获取模块，可以用通讯嗅探器（SNIFFER）充当协议分析和存储模块，当然也可以为实现各模块功能自行开发产品。“数恢系统”以及其组成模块，仅仅是为了说明而举的实例，并不表示系统必须或只能按此设计，各模块详细的功能如下：
3.2.1 交换模块
该模块对数据进行简单的交换和转发。
通讯代理模块
即前文所说的“通讯代理”，负载均衡器，通讯代理服务器，带有地址转换功能的防火墙，路由器等通过合理的设置，均可以充当本发明所说的“通讯代理”，当然也可以是专门开发的有此功能的软硬件产品。为简化说明，本例将以负载均衡器作为通讯代理模块。
下面简述合理配置客户端和负载均衡器使通讯绕行备份数据中心的步骤和原理：
第一步，将负载均衡器放置在备份数据中心。
第二步，合理配置客户端，使之从访问生产数据中心的应用服务器的实际IP地址（下文称SIP1），改为访问备份数据中心负载均衡器拥有的某个虚拟IP地址（下文称VIP1）。
第三步，合理配置负载均衡器，使之可以使客户端访问VIP1地址的通讯流，转发到生产数据中心的应用服务器的实际地址SIP1上。同时，对客户端的IP地址做源地址转换，即将客户端的IP地址（下文称CIP），转换成负载均衡器拥有的另一个IP地址（下文称VIP2）。这样，应用服务器的返回数据流就从直接发送给客户端地址CIP，变成发送给VIP2。
由于VIP1和VIP2都是放置在备份数据中心中的负载均衡器的地址，无论是客户端访问生产数据中心的通讯或者应用服务器返回客户端的通讯均将绕行备份数据中心。
当然，我们也可以不改变客户端的配置，而通过合理配置应用服务器和负载均衡器达到一样的效果。
数据获取模块
该模块可以利用SPAN、RSPAN或者分光复制等成熟的技术来获取通讯数据流的内容，也可以通过自行开发有相应功能的软硬件来实现。
SPAN技术目前主要是用来监控交换机上的数据流，大体分为两种类型，本地SPAN和远程SPAN.----Local Switched Port Analyzer （SPAN） and Remote SPAN （RSPAN），实现方法上稍有不同。利用SPAN技术我们可以把交换机上某些想要被监控端口（以下简称受控端口）的数据流COPY或MIRROR一份，发送给连接在监控端口上的流量分析仪。
协议分析和存储模块
该模块可以利用成熟的协议分析器对取得的数据流进行解包分析，并将相关解包数据存储到专门的数据库中，也可以用自行开发的软硬件，实现对数据的解包和存储。
数据追平模块
该模块在灾难发生时，利用专门开发的数据补录程序将协议分析和存储模块数据库中的数据补录回备份数据中心的灾难备份系统中，实现RPO=0。
实现细节
可以在备份数据中心内部设置两套数恢系统互为主备关系，当主用数恢系统出现故障的时候，可以切换到备用数恢系统。
如图7所示，配置备份数据中心数恢系统的通讯代理模块，客户端或者生产中心应用服务器，使原来直接访生产数据中心的应用服务器的通讯流变为如下：客户端 —>备份数据中心数恢系统的通讯代理模块—>生产数据中心的应用服务器—>生产数据中心的数据库服务器—>生产数据中心的存储，并且原路返回客户端，在备份数据中心数恢系统上启用数据获取模块，将流经的数据进行解包并储存到备份数据中心的数据库中。
当灾难发生的时候，如图8所示，由于传统灾难备份恢复技术的限制，生产数据中心和备份数据中心的数据是不一致的，这时我们应启动备份数据中心数恢系统的数据追平模块，提取之前存储的通讯数据，来弥补生产数据中心和备份数据中心间的数据差，实现RPO=0。待数据差弥补完毕后，客户端即可访问备份数据中心的应用服务器，而由备份数据中心的应用服务器再访问备份数据中心的数据库服务器和存储，从而使业务中断得以恢复。
本申请涉及到的相关技术资料
1.技术指标RPO、RTO
衡量灾难备份恢复技术的两个技术指标RPO、RTO
RPO（Recovery Point Objective）：以数据为出发点，主要指的是业务系统所能容忍的数据丢失量。即在发生灾难，灾难备份恢复系统接替原生产系统运行时，灾难备份恢复系统与原主生产数据中心不一致的数据量。RPO是反映恢复数据完整性的指标，在同步数据复制方式下，RPO等于数据传输时延的时间；在异步数据复制方式下，RPO基本为异步传输数据排队的时间。在实际应用中，考虑到数据传输因素，业务数据库与灾难备份恢复备份数据库的一致性（SCN）是不相同的，RPO表示业务数据与灾难备份恢复备份数据的SCN的时间差。发生灾难后，启动灾难备份恢复系统完成数据恢复，RPO就是新恢复业务系统的数据损失量。
RTO（Recovery Time Objective）：以应用为出发点，即应用的恢复时间目标，主要指的是所能容忍的应用停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。是反映业务恢复及时性的指标，表示业务从中断到恢复正常所需的时间。RTO值越小，代表灾难备份恢复系统的数据恢复能力越强。各种灾难备份恢复解决方案的RTO有较大差别，基于光通道技术的同步数据复制，配合异地备用的业务系统和跨业务中心与备份数据中心的高可用管理，这种灾难备份恢复解决方案具有最小的RTO。灾难备份恢复系统为获得最小的RTO，需要投入大量资金。
不同灾难备份恢复方案的RTO和RPO是不相同的。
国际标准SHARE78
要建设灾难备份恢复系统，就必须提出相应的设计指标，以此作为衡量和选择灾难备份恢复解决方案的参数。目前，国际上通用的灾难备份恢复系统的评审标准为SHARE78，主要包括以下内容。
●备份/恢复的范围
●灾难恢复计划的状态
●业务中心与灾难备份恢复中心之间的距离
●业务中心与灾难备份恢复中心之间如何连接
●数据是怎样在两个中心之间传送的
●允许有多少数据丢失
●保证更新的数据在灾难备份恢复中心被更新
●灾难备份恢复中心可以开始灾难备份恢复进程的能力
SHARE78是建立灾难备份恢复系统的一种评审标准。建立灾难备份恢复系统的最终目的，是为了在灾难发生后能够以最快速度恢复数据服务，主要体现在RTO和RPO上。SHARE78，M028报告中定义的灾备的七个级别和与其对应的数据丢失量与恢复时间情况详见下表：
| 等级 | 描述 | RPO | RTO |
| 0级 | 无灾备计划 | - | - |
| 1级 | 车辆运送方式 | 24~48小时 | >48小时 |
| 2级 | 车辆运送＋热备份 | 24~48小时 | 24小时 |
| 3级 | 电子传送 | <24小时 | <24小时 |
| 4级 | 活动状态备份数据中心 | 秒级 | <24小时 |
| 5级 | 两中心、两阶段确认 | 秒级 | <2小时 |
| 6级 | 零数据丢失 | 零丢失 | <2小时 |
3.名词解释
通讯数据获取点：
网络一个比较通用的定义是指，利用通信线路将地理上分散的、具有独立功能的计算机系统和通信设备按不同的形式连接起来，以功能完善的网络软件及协议实现资源共享和信息传递的系统。
本发明中，通讯数据获取点是指整个网络系统中满足以下条件的某一部分连续的网络：1.这一部分网络所处的地理位置和其他条件，可确保其在可以接受的概率下，不会和生产数据中心同时受到某种灾难的影响。2.在这部分网络上，可安装截获网络通讯数据的设备，以达成本发明的目的。 比如，假设备份数据中心不会和生产数据中心同时受到某种灾难的影响，且其内部的网络上也能安装截获网络通讯数据的设备，则备份数据中心内部的网络就可以视做一个通讯数据获取点。
生产系统：
本发明中指，对外提供某种服务的计算机系统或计算机系统的集合。一般包括WEB 服务器， 应用服务器，数据库服务器等。
灾难备份系统：
本发明中指，在发生使生产系统无法工作的灾难时，对外提供某种服务的计算机系统或计算机系统的集合。一般包括WEB 服务器， 应用服务器，数据库服务器 等。
生产数据中心、备份数据中心
本发明中，将集中存放某套生产系统主要软硬件设备，特别是该生产系统中存储主要生产数据的软硬件设备的数据中心，称之为该生产系统的生产数据中心。将集中存放与某套生产系统对应的灾难备份系统的主要软硬件设备，特别是该灾难备份系统中存储灾难备份数据的软硬件设备的数据中心，称之为备份数据中心。按照以上定义，现实中，某个数据中心可以在是某套系统的生产数据中心的同时，又是另一套系统的备份数据中心。
网络汇聚中心
本发明中，指供客户端网络接入，并由之再转接到生产数据中心和备份数据中心的特殊通讯数据获取点，以及支持该通讯数据获取点工作的场地和设施。
应用服务器
本发明中，应用服务器指：处理（如，接收、转发、计算、整合、加工等）关键业务数据，但不存储或不单独存储关键业务数据的软硬件。从这种意义上来说，WEB 服务器也可以视作一种特殊的应用服务器。关键业务数据指，生产系统正常运行所必须的业务数据。
Claims (9)
1.一种新型的灾难备份恢复方法，其特征在于：在网络中设置一个或者若干个通讯数据获取点，
在通讯数据获取点截获客户端和生产系统之间的通讯数据，并将获取的通讯数据存储在备份数据中心；
或在通讯数据获取点截获生产系统内部服务器之间的通讯数据，并将获取的通讯数据存储在备份数据中心；
同时，所述生产数据中心中的生产系统还同时和备份数据中心中的灾难备份系统之间通过传统灾备手段进行异步数据复制；
当生产数据中心发生灾难导致生产系统无法正常运转时，用在通讯数据获取点上获取的通讯数据来恢复灾难备份系统因异步数据复制而丢失的业务数据。
2.如权利要求1所述的新型的灾难备份恢复方法，其特征在于：当客户端和生产系统进行数据通讯以处理业务数据时，通过改变客户端和生产系统之间的通讯数据在网络中的流向，使客户端和生产系统之间的通讯数据必然绕经网络中的一个或者若干个通讯数据获取点，使在通讯数据获取点能截获客户端和生产系统之间的通讯数据；
或当生产系统内部各个服务器进行数据通讯以处理业务数据时，改变生产系统内部服务器之间的通讯数据在网络中的流向，使生产系统各个服务器之间的通讯数据必然绕经网络中的一个或者若干个通讯数据获取点，使在通讯数据获取点能截获生产系统内部服务器之间的通讯数据。
3.如权利要求2所述的新型的灾难备份恢复方法，其特征在于：通讯数据获取点所在的地理位置的选取原则为：在能够接受的概率下，通讯数据获取点所在的地理位置位于不会和生产数据中心同时受到某种灾难的影响的地区。
4.如权利要求3所述的新型的灾难备份恢复方法，其特征在于：当将通讯数据获取点所处的地理位置距离生产数据中心的远近，作为影响能够接受的概率的唯一因素时，且生产数据中心到备份数据中心之间的距离为能够接受的最小灾备距离时，则：以生产数据中心为圆心，以生产数据中心到备份数据中心之间的距离为半径画一个圆，在圆上和圆外的任何一个有网络通过的地区，均能作为设置通讯数据获取点的地区。
5.如权利要求4所述的新型的灾难备份恢复方法，其特征在于：当生产数据中心到备份数据中心之间的距离为能够接受的最小灾备距离时，将通讯数据获取点设置在备份数据中心。
6.如权利要求2所述的新型的灾难备份恢复方法，其特征在于：采取改变网络路由的方法，使通讯数据必然绕经一个或者若干个通讯数据获取点。
7.如权利要求2所述的新型的灾难备份恢复方法，其特征在于：通过改变网络拓扑结构的方法，使通讯数据必然绕经一个或者若干个通讯数据获取点。
8.如权利要求2所述的新型的灾难备份恢复方法，其特征在于：通过将应用服务器安装在通讯数据获取点的所处的地点，或通过设置应用服务器的通讯代理，或通过设置生产系统其他服务器的通讯代理，并调整这些通讯代理在网络中的位置，来改变通讯双方的通讯数据在网络中流向，使通讯数据必然绕经一个或者若干个通讯数据获取点。
9.一种新型的灾难备份恢复系统，包括：生产数据中心和备份数据中心，生产数据中心设有生产系统，备份数据中心设有灾难备份系统，其特征在于：网络中设有至少一个通讯数据获取点，在该通讯数据获取点将客户端和生产系统之间的通讯数据截获，或将生产系统内部服务器之间的通讯数据截获，并将截获的数据发往并存储到备份数据中心。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201210259569.0A CN102752404B (zh) | 2012-07-25 | 2012-07-25 | 一种新型的灾难备份恢复方法与系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201210259569.0A CN102752404B (zh) | 2012-07-25 | 2012-07-25 | 一种新型的灾难备份恢复方法与系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN102752404A true CN102752404A (zh) | 2012-10-24 |
| CN102752404B CN102752404B (zh) | 2015-02-18 |
Family
ID=47032302
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201210259569.0A Expired - Fee Related CN102752404B (zh) | 2012-07-25 | 2012-07-25 | 一种新型的灾难备份恢复方法与系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102752404B (zh) |
Cited By (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103152407A (zh) * | 2013-02-20 | 2013-06-12 | 浪潮电子信息产业股份有限公司 | 一体化数据灾备系统设计方法 |
| CN103595570A (zh) * | 2013-11-20 | 2014-02-19 | 中国农业银行股份有限公司广东省分行 | 一种多活架构前置系统、服务器与业务处理方法 |
| CN104461774A (zh) * | 2014-11-24 | 2015-03-25 | 华为技术有限公司 | 异步复制方法、装置与系统 |
| CN104954470A (zh) * | 2015-06-19 | 2015-09-30 | 中国工商银行股份有限公司 | 联机交易处理系统和方法 |
| CN105959169A (zh) * | 2016-07-19 | 2016-09-21 | 中国银联股份有限公司 | 一种交易数据处理系统及方法 |
| WO2017173946A1 (zh) * | 2016-04-05 | 2017-10-12 | 中国银联股份有限公司 | 提供业务连续性保护的数据处理系统 |
| CN107688584A (zh) * | 2016-08-05 | 2018-02-13 | 华为技术有限公司 | 一种容灾切换的方法、节点及系统 |
| CN107766175A (zh) * | 2017-09-07 | 2018-03-06 | 中国光大银行股份有限公司信用卡中心 | 一种用于银行的数据处理系统 |
| CN107783860A (zh) * | 2016-08-31 | 2018-03-09 | 阿里巴巴集团控股有限公司 | 一种数据传输的恢复点目标监控方法及设备 |
| CN108845896A (zh) * | 2018-07-10 | 2018-11-20 | 中国建设银行股份有限公司 | 灾难后数据追踪系统及方法 |
| CN108958969A (zh) * | 2018-05-08 | 2018-12-07 | 杭州数梦工场科技有限公司 | 数据库灾备方法、装置及灾备系统 |
| CN109302391A (zh) * | 2018-09-21 | 2019-02-01 | 深圳市九洲电器有限公司 | 一种安防数据上传方法及装置、客户端 |
| CN109688198A (zh) * | 2018-11-23 | 2019-04-26 | 四川九洲电器集团有限责任公司 | 分布式系统及故障检测方法 |
| CN109901949A (zh) * | 2019-02-25 | 2019-06-18 | 中国工商银行股份有限公司 | 双活数据中心的应用灾备系统及方法 |
| CN113010348A (zh) * | 2020-09-25 | 2021-06-22 | 证通股份有限公司 | 用于容灾中数据恢复的装置、系统和方法 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101621394A (zh) * | 2008-06-30 | 2010-01-06 | 上海邮电设计咨询研究院有限公司 | 一种用于话务数据处理的容灾系统 |
| CN101651710A (zh) * | 2009-09-21 | 2010-02-17 | 北京工业大学 | 基于p2p的容灾备份方法 |
| CN101741601A (zh) * | 2008-11-06 | 2010-06-16 | 上海市医疗保险信息中心 | 结构化灾难备份系统和备份方法 |
| CN102263657A (zh) * | 2011-06-07 | 2011-11-30 | 华为软件技术有限公司 | 数据业务容灾切换方法、装置和系统 |
| CN102541686A (zh) * | 2011-11-29 | 2012-07-04 | 中标软件有限公司 | 一种使用虚拟机来实现系统的备份以及灾难恢复的方法 |
-
2012
- 2012-07-25 CN CN201210259569.0A patent/CN102752404B/zh not_active Expired - Fee Related
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101621394A (zh) * | 2008-06-30 | 2010-01-06 | 上海邮电设计咨询研究院有限公司 | 一种用于话务数据处理的容灾系统 |
| CN101741601A (zh) * | 2008-11-06 | 2010-06-16 | 上海市医疗保险信息中心 | 结构化灾难备份系统和备份方法 |
| CN101651710A (zh) * | 2009-09-21 | 2010-02-17 | 北京工业大学 | 基于p2p的容灾备份方法 |
| CN102263657A (zh) * | 2011-06-07 | 2011-11-30 | 华为软件技术有限公司 | 数据业务容灾切换方法、装置和系统 |
| CN102541686A (zh) * | 2011-11-29 | 2012-07-04 | 中标软件有限公司 | 一种使用虚拟机来实现系统的备份以及灾难恢复的方法 |
Non-Patent Citations (2)
| Title |
|---|
| 杨凯 等: "银联数据异地灾难备份架构设计探讨", 《中国金融电脑报》 * |
| 王仲怡 等: "银行业数据中心系统灾备技术", 《上海大学学报（自然科学版）》 * |
Cited By (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103152407A (zh) * | 2013-02-20 | 2013-06-12 | 浪潮电子信息产业股份有限公司 | 一体化数据灾备系统设计方法 |
| CN103595570A (zh) * | 2013-11-20 | 2014-02-19 | 中国农业银行股份有限公司广东省分行 | 一种多活架构前置系统、服务器与业务处理方法 |
| CN104461774B (zh) * | 2014-11-24 | 2018-01-16 | 华为技术有限公司 | 异步复制方法、装置与系统 |
| CN104461774A (zh) * | 2014-11-24 | 2015-03-25 | 华为技术有限公司 | 异步复制方法、装置与系统 |
| CN104954470A (zh) * | 2015-06-19 | 2015-09-30 | 中国工商银行股份有限公司 | 联机交易处理系统和方法 |
| CN104954470B (zh) * | 2015-06-19 | 2019-05-21 | 中国工商银行股份有限公司 | 联机交易处理系统和方法 |
| WO2017173946A1 (zh) * | 2016-04-05 | 2017-10-12 | 中国银联股份有限公司 | 提供业务连续性保护的数据处理系统 |
| CN105959169A (zh) * | 2016-07-19 | 2016-09-21 | 中国银联股份有限公司 | 一种交易数据处理系统及方法 |
| CN107688584A (zh) * | 2016-08-05 | 2018-02-13 | 华为技术有限公司 | 一种容灾切换的方法、节点及系统 |
| CN107783860A (zh) * | 2016-08-31 | 2018-03-09 | 阿里巴巴集团控股有限公司 | 一种数据传输的恢复点目标监控方法及设备 |
| CN107766175A (zh) * | 2017-09-07 | 2018-03-06 | 中国光大银行股份有限公司信用卡中心 | 一种用于银行的数据处理系统 |
| CN108958969A (zh) * | 2018-05-08 | 2018-12-07 | 杭州数梦工场科技有限公司 | 数据库灾备方法、装置及灾备系统 |
| CN108958969B (zh) * | 2018-05-08 | 2019-09-17 | 杭州数梦工场科技有限公司 | 数据库灾备方法、装置及灾备系统 |
| CN108845896A (zh) * | 2018-07-10 | 2018-11-20 | 中国建设银行股份有限公司 | 灾难后数据追踪系统及方法 |
| CN109302391A (zh) * | 2018-09-21 | 2019-02-01 | 深圳市九洲电器有限公司 | 一种安防数据上传方法及装置、客户端 |
| CN109688198A (zh) * | 2018-11-23 | 2019-04-26 | 四川九洲电器集团有限责任公司 | 分布式系统及故障检测方法 |
| CN109688198B (zh) * | 2018-11-23 | 2022-05-13 | 四川九洲电器集团有限责任公司 | 分布式系统及故障检测方法 |
| CN109901949A (zh) * | 2019-02-25 | 2019-06-18 | 中国工商银行股份有限公司 | 双活数据中心的应用灾备系统及方法 |
| CN109901949B (zh) * | 2019-02-25 | 2021-06-18 | 中国工商银行股份有限公司 | 双活数据中心的应用灾备系统及方法 |
| CN113010348A (zh) * | 2020-09-25 | 2021-06-22 | 证通股份有限公司 | 用于容灾中数据恢复的装置、系统和方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN102752404B (zh) | 2015-02-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102752404B (zh) | 一种新型的灾难备份恢复方法与系统 | |
| US6848007B1 (en) | System for mapping addresses of SCSI devices between plurality of SANs that can dynamically map SCSI device addresses across a SAN extender | |
| US8185663B2 (en) | Mirroring storage interface | |
| US6718347B1 (en) | Method and apparatus for maintaining coherence among copies of a database shared by multiple computers | |
| CN110198226A (zh) | 一种负载均衡集群中访问请求处理方法、系统和可读介质 | |
| CN101124567A (zh) | 消息传递系统中的缓存引擎 | |
| US7987154B2 (en) | System, a method and a device for updating a data set through a communication network | |
| CN103118148B (zh) | 一种arp缓存更新方法和设备 | |
| CN106506588A (zh) | 多地多中心的数据中心双活方法和系统 | |
| CN102647406A (zh) | 用于高度可实现性应用的智能集成网络安全设备 | |
| CN101426025A (zh) | 远程复制网络 | |
| US11704206B2 (en) | Generation of host requests to a storage controller for read diagnostic parameters for a data mirroring configuration | |
| US11050655B2 (en) | Route information distribution through cloud controller | |
| CN102412990A (zh) | 具有集中管理和实时传输功能遥感卫星原始数据记录系统 | |
| CN116401225A (zh) | 一种面向卫星云的分布式文件系统 | |
| US8737228B2 (en) | Flow control management in a data center ethernet network over an extended distance | |
| JP2003517765A (ja) | パケットベースのネットワークを介してストレージエリアネットワークをリンクする封入プロトコル | |
| US20220121537A1 (en) | Communication of diagnostic parameters of a data mirroring configuration from a storage controller to a host | |
| CN101207569B (zh) | 用于确定计算机网络上的通信路径的设备和方法 | |
| CN104782081A (zh) | 套接字状态转移 | |
| CA2390793A1 (en) | Method and system for mapping addressing of scsi devices between storage area networks | |
| FR2947127A1 (fr) | Systeme de simulation ou de test, et procede associe. | |
| EP3652905B1 (en) | Networks for packet monitoring and replay | |
| JP2008047142A (ja) | 情報処理システム、および、情報処理システムのストレージ制御方法 | |
| CN112073506B (zh) | 基于IPv6与消息队列的复杂电磁数据采集方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20150218 |