作者baizhaoxian

·2018-05-09 10:58

容灾备份管理工程师·无

关注171

某商行异地灾难备份方案 <最佳实践建议书>

字数 11141阅读 9546评论 8赞 36

# 1	项目概述
## 1.1	项目背景
某行金融电子化工作经过多年的发展，信息技术已得到广泛的应用，主要业务系统如核心业务、现代化支付、中间业务及卡前置等都实现信息电子化，综合性多功能的金融信息化服务体系已初步形成。

某行业务对信息化依赖程度越来越高，信息系统安全问题对业务的影响突出。数据集中的同时也意味着风险相对集中，在地震、火灾、水灾、疫情、计算机病毒、黑客攻击等灾难事件不断集中爆发，为确保某行信息系统安全和业务持续运行已成为一项重要而艰巨的任务。

某行的业务经营体系不断发展，业务领域不断拓展，业务覆盖区域不断扩大。在这种情况下，某行目前的核心业务系统已经实现了数据的本地自动备份，未进行完整的灾难备份体系建设。一旦因为机房、建筑物损坏等较大规模的灾难引起数据丢失或者信息系统长时间宕机，将造成某行全省范围内的业务停顿，相关单位和个人无法从事有关金融业务，不仅造成严重不良的社会影响，更影响金融行业的稳定。

某行信息系统灾难备份体系建设以及业务连续体系建设的重要开端，异地灾备系统工程建设的建设实施，为某行后续的业务连续体系建设打下坚实的基础。

## 1.2	规范要求
国家历来对加强信息安全保障工作高度重视，先后出台有关灾难备份的保障措施。其有关灾备规范要求要点文件：

	2002年8月， 中国人民银行出台并下发了《中国人民银行关于加强银行数据集中安全工作的指导意见》(银发[2002]260号文件)。
	2003年9月,中共中央办公厅、国务院办公厅下发了《国家信息化领导小组关于加强信息安全保障工作的意见》(中办发[2003]27号)。
	2004年1月9日，全国信息安全保障工作会议下发了《关于做好国家重要信息系统容灾备份工作的通知》。
	国信办于2004年9月份下发了《关于加强国家重要信息系统灾难备份工作的意见》(信安通〔2004〕11号)。
	2006年4月，中国人民银行出台并下发了《关于进一步加强银行业金融机构信息安全保障工作的指导意见》(银发[2006]123号文件)。
	2006年8月，银监会下发的《银行业金融机构信息系统风险管理指引》(银发[2006]63号)文件中。
	2007年11月1日，国家正式下发了《信息安全技术信息系统灾难恢复规范》(GB/T 20988-2007) 。
	2008年2月，中国人民银行下发了《中国人民银行关于发布《银行业信息系统灾难恢复管理规范》行业标准的通知》(银发[2008]48号 )。
	2008年2月4日，JR/T0044-2008 《银行业信息系统灾难恢复管理规范》标准正式发布和实施。

## 1.3	建设现状
目前IT服务外包特别是灾难备份外包已成企业提高服务质量与管理效率，提高企业核心竞争力，降低IT投资压力，提高企业应变处置应急能力的普遍选择。原则上除政府内网和军事机构没有外包案例外，银行、保险、证券、制造企业、商业企业等进行相关灾备系统建设的案例。如国内银行案例：

![微信图片_20180509100620.png](/home/attachment/201805/09/9781_152583161697514.png)

## 1.4	紧迫性
某行在保持业务持续运行方面正面临压力因素：

	没有完善的业务信息系统建设规划。为适应高速发展的业务需要，系统建设过程中存在着“边集中、边生产、边规划”的矛盾。
	没有进行各部门的风险分析和业务影响分析；
	没有总行及分支行的业务连续性计划和业务恢复计划。
	没有建设完善的灾难备份体系，并制订其运营管理制度，关系着金融稳定的关键业务信息系统仅有单点、地点的低等级数据备份。
	业务依赖于信息电子化程度日益提高。

建立安全可靠的灾难备体系，实现某行的信息系统运行保障场地、重要信息和处理系统的灾难备份，提高其信息系统的风险抵御能力，避免或减少灾难打击和重大事故造成损失程度，确保核心数据安全和业务经营的连续性，避免引起重要服务功能和渠道严重中断。
# 2	需求分析与建设目标
## 2.1	不足和挑战
目前，某行已初步建立一个安全的生产系统架构和灾备体系架构，为建立相对完善的业务连续性体系及配合未来某行全国--分行开展，其建议：
### 1.	网络安全性问题：
	当前某行在本地已初步建立一个数据备份中心，但备份中心没有与支行连接的线路，所有支行的上连线路均连接到生产中心，一旦生产中心的传输设备发生故障，将导致所有支行与总行的连接中断。
	各支行与总行连接的线路均采用网通的线路，没租用其他运营商的线路，一旦网通的局端网络出现问题，也将导致连接中断。
	生产中心只有一台路由器与ATM终端连接，无备份机制，一旦该路由器发生故障，将导致银行卡交易中断。
### 2.	业务连续性问题：
	同城备份中心已经配置业务主机处理系统并建立应用级灾备，但是同城备份中心的主机并没有同支行和外联单位连接，所以一旦生产中心发生灾难，只保证数据不丢失，但业务无法恢复。
	同城灾备中心仅仅备份核心存储的数据，其他业务系统的数据没有备份，一旦生产中心发生灾难，这些业务系统的数据也将丢失。
	建立同城灾备中心，但没有建立有效、规范的业务连续性管理体系，无法保证灾难发生时业务的连续性。
### 3.	灾难抵御能力问题：
	目前只建立同城灾备中心，没有异地灾备中心，因此无法抵御区域性灾难。
	尽管生产数据建立定期的本地磁带备份机制，但备份的介质没有做到异地存放，发生区域性灾难后，异地没有数据副本。
## 2.2	灾备需求
### 2.2.1	建设内容
按照建立异地应用级灾备系统总体要求，其建设将涵盖以下内容：

	通过整体外包方式，在异地建立应用级灾备体系；
	建立生产数据的异地备份体系，保证异地的数据与生产中心的一致性；
	建立完善异地应用级灾备体系，保证异地灾备中心运行的独立性；
	开发完善的灾难恢复应急响应预案，建立有效的应急响应组织体系和流程，保证灾难发生时系统切换有序性；
	建立定期的应急切换演练机制，保证异地灾备中心的可用性；
	在原有同城应用级灾备体系的基础上，建立“生产+同城+异地”的灾备体系架构；
	建立异地灾备的运维管理体系，保证异地灾备中心系统可靠运行。
### 2.2.2	职能定位

#### 1.异地灾备中心的灾难防范策略

以下事件发生，需要切换到异地灾备中心
–	区域性的自然灾害，影响到呼市两个数据中心的正常运行；
–	区域性的人为灾难，例如：战争、区域性停电、区域性疫病等，影响到呼市两个数据中心的正常运行；
–	涉及生产中心的大规模改造或迁移事件；

#### 2.异地灾备中心与同城灾备中心的职能差异

![微信截图_20180509101027.png](/home/attachment/201805/09/9781_152583185258744.png)

#### 3.异地灾备中心的资源利用方式

异地灾备中心启用的场景属于小概率事件，为保证这种小概率事件未发生时能充分异地灾备中心的资源，必考虑异地灾备中心的资源利用方式，从而做到对异地灾备中心资源的投资保护。
–	数据资源利用：通过异步数据复制手段保证了异地灾备中心与生产中心及同城灾备中心数据的一致性，因此在平时可将这些数据用于测试、开发及培训等；
–	处理能力利用：异地灾备中心的数据处理系统可测试机和开发机使用，运行数据仓库和数据挖掘应用系；
–	网络资源利用：异地灾备中心与各分行的广域网连接线路可承载一些非关键性业务即分支行的这非关键业务可以通过分支行与异地灾备中心的连接线路运行，避免这非关键业务占用生产中心与分支行的网络资源，使资源更多地用于生产业务。
### 2.2.3	分析建议
目前某行已建同城灾备中心，实现综合业务系统、现代化支付系统、中间业务前置、银行卡前置的同城数据级灾备。当生产中心发生灾难时，尽管这些业务系统的数据不会丢失，但业务系统不能在同城灾备中心运行，不能实现业务连续性。建立异地灾备中心的目的不仅在异地建立与生产中心和同城灾备中心相同的数据副本，而且保证当生产中心发生灾难时，其业务系统能在异地灾备中心运行，需及早建立异地灾应用级灾备系统。

根据JR/T0044-2008 《银行业信息系统灾难恢复管理规范》中第一类信息系统恢复最低要求：同城灾难恢复RTO<4小时，RPO<15-30分钟；

某公司初步建议某行核心系统异地灾难恢复指标要求，如下表：

![微信截图_20180509101548.png](/home/attachment/201805/09/9781_152583217366787.png)

## 2.3	规划阶段
### 2.3.1	总体目标
为抵御生产中心灾难及区域性灾难的风险，需建立完善的异地灾备系统，异地灾备系统的建设不仅要保证生产数据的异地备份，需保证区域性灾难发生时业务连续性。利用第三方基础设施建设某行异地灾备中心，利用第三方运营团队提供日常运营服务，确保异地灾备系统稳定可靠运行。
### 2.3.2	规划建议
按照“统筹规划、分步实施”的原则，分阶段实施：

#### 第一阶段：建立核心业务、关键支付、关键渠道和关键管理系统的异地应用级灾备
包括综合业务系统、现代化支付系统、中间业务前置系统和银行卡前置系统；实施内容如下：
	建立某行异地灾备中心运营管理队伍；
	核心主机、核心存储、核心网络设备到货、进场；
	按照异地灾备系统方案，进行系统建设资源支持服务，包括网络通信线路的安装、坐席、应急通讯和机房场地、基础设施的准备等；
	异地灾备系统安装、联调、测试等技术实施工作；
	异地灾备系统演练与恢复预案开发。
#### 第二阶段：其他系统的异地应用级灾备
除以上四个系统之外的其他系统；实施内容如下：
	相关业务系统的IT设备到货、进场；
	网络系统的扩容；
	进行系统建设资源支持服务，包括网络通信线路升级、坐席扩充、应急通讯和机房场地、基础设施的完善等；
	系统安装、联调、测试等技术实施工作；
	灾难恢复预案和演练相关的修改和完善。
#### 第三阶段：建立全行业务连续性管理体系
实施内容如下：
	根据BCM方法论和某行业务连续运行的要求，定义、设计和开发某行BCP计划需求模型，确保所选择的方法论适合恢复需求和恢复目标的要求。
	按照业务连续性开发的理论体系和方法论，开发符合某行业务特点，具有可操作性的BCP计划，支持关键业务功能在灾难环境下的持续运作。
	业务连续运行计划研讨会和培训，建立某行关键业务部门的项目组，开展业务连续性项目培训，使每个项目成员掌握业务连续运行的重要性，掌握成功实施业务连续运行计划需要担当的角色和业务流程。

本方案第一阶段灾备建设：建立核心业务-关键支付-关键渠道和关键管理系统的异地应用级灾备。

# 3	设计方法与思路
## 3.1	理论依据
本系统设计需要参考的规范和标准，包括国外灾备系统和业务连续性管理规范，客户所属行业针对信息系统灾难恢复建设的相关规定和要求。
## 3.2	方法论
### 3.2.1	总体方法
总体系统设计流程是“通过问卷了解需求、通过访谈确认需求、通过分析制定策略、通过策略细化方案”。
### 3.2.2	需求分析
系统需求分析是编制灾难备份系统技术方案的依据,也是建立业务连续性管理体系的基础。系统需求分析主要包括应用系统调研、IT系统调研、应用影响分析、系统差异性分析等方面，其中业务系统调研和业务影响分析的目的是为了确定灾备范围和灾备策略，IT系统调研和系统差异性分析的目的是为了制定灾备中心IT资源规划和确定灾备中心相关IT资源配置，系统分析方法如下：
1.	系统调研问卷：
–	应用系统调研问卷包括应用系统的名称、功能介绍、交易量统计、交易情况、与其他应用系统的关联关系、数据流向等。
–	IT系统调研问卷包括应用系统运行的主机平台、数据库和中间件平台、数据分布情况、存储系统、网络和安全系统等。
2.	问卷访谈：通过定向访谈的方式对调研问卷的内容进行确认和细化，使需求更详细、更清晰、更具体。
3.	应用影响分析：根据应用系统调研问卷和访谈记录，对各应用系统对单位业务的影响程度进行分析，确立各应用系统的灾难恢复等级、资源需求和关键技术指标（RTO，RPO等）。
4.	IT系统需求分析：根据IT系统调研问卷和访谈记录，分析现有系统存在的问题，确定系统设计的总体思路和原则。

### 3.2.3	策略制定
灾备策略是制定灾备技术方法的核心内容，灾备策略的制定主要包括如下：
1.	灾备范围确立：据应用影响分析的结论确立灾备的范围，即确定应用系统异地灾备的优先顺序。
2.	灾备策略制定：据现有IT系统的现状，结合国内外数据备份技术的潮流，制定切实可行的数据备份策略。

### 3.2.4	技术方案

1.	根据灾备策略，结合客户的数据容量及分布情况，制定数据备份方案。
2.	根据应用系统的客户端分布情况及应用系统的实时性要求，制定灾备网络的连接架构。
3.	根据生产端的IT资源配置情况，确定灾备端的IT资源配置。

### 3.2.5	演练方案
1.	客户的灾备服务要求和灾备体系架构，开发适合其业务模式相关的灾难恢复应急响应预案。
2.	按照应急响应预案的内容进行应急切换演练，只考虑桌面演练，其目的是验证切换流程的可行性和切换步骤的可操作性。

## 3.3	技术路线
### 3.3.1	安全性
–	通过成熟的数据备份技术，保证异地灾备中心与生产中心和同城灾备中心数据的一致性。
–	采用与现有同城数据镜像技术一致的异步数据镜像技术实现数据的异地备份。
–	通过异地灾备中心的运维体系，定期对备份的数据进行一致性和完整性检验，确保数据的可用性。
### 3.3.2	可用性
–	异地灾备中心的业务主机应与生产中心的业务主机在操作系统、数据库、应用中间件等各层面上完全兼容，保证异地灾备应用系统的可用性。
–	异地灾备中心应选用与生产中心性能相当的主机，配置可略低于生产中心的配置，以保证异地灾备应用系统的处理能力。
### 3.3.3	技术性
–	异地灾备中心应配备相关的专业技术人员，保证对灾备系统资源的技术支持能力。
–	异地灾备中心应据生产中心的技术支持手段和流程，结合客户对技术支持方式、服务响应能力的要求，制定规范的技术支持流程和采取先进的技术手段。
### 3.3.4	恢复性
–	在系统切换演练过程中，不仅要考虑从生产端到异地灾备端的切换，还要考虑到生产端环境恢复后如何从异地灾备端恢复到生产端运行的机制和流程。
–	当系统切换出现问题时，需采取相应的系统回退流程，保证灾备系统能回退到生产系统，且不能影响正常的生产和交易。

# 4	技术方案
## 4.1	系统设计
### 4.1.1	可维护性
异地灾备系统涉及高端服务器、高性能网络设备、大容量磁盘阵列等存储设备以及各种光纤存储域网络连接设备，为保证系统良好运转，需要系统具有良好的可管理性，采用统一的监控代理机制实现对系统的监测、故障诊断、远程管理和优化等功能。同时在产品选型方面应尽可能选取集成度高、采用模块化通用设计的产品，以便于管理和维护。
### 4.1.2	可持续性
异地灾备建设是一个长期、持续性的工作，随着数据量、业务量和用户量的持续增长，系统将变得越来越复杂，服务质量要求越来越高，确保系统的可持续性服务是本方案设计需要考虑的重要环节。
### 4.1.3	投资保护
经济性也是本系统设计重要方面。需从两个方面来考虑：
	是建立存储、备份系统过程中的费用。
	是系统建成后的运行维护费用和对已有投资的保护能力。
在考虑采用高性能的IT设备的同时，必考虑投资的合理性。
### 4.1.4	资源整合
为保证异地灾备中心与生产中心运行环境的一致性，异地灾备中心随着生产中心IT资源的变更而变化，通过资源整合提高灾备中心IT资源的利用率，保证灾备中心资源具有动态调整和分配能力，以满足与生产中心资源的一致性和对应用系统灾备资源需求的适应性。

# 4.2	总体架构
现状架构如图：

![微信图片_20180509102915.png](/home/attachment/201805/09/9781_152583308425727.png)

三中心总体架构如下图：

![微信图片_20180509103153.png](/home/attachment/201805/09/9781_152583313385111.png)

总体架构说明：
	利用某数据中心作为某行的异地灾备中心，实现综合业务系统、中间业务前置、现代化支付和银行卡前置系统的应用级灾备。
	采用NetApp的SnapMirror数据备份技术实现异地数据备份，备份路径先将生产端数据通过SnapMirror备份到同城灾备中心（已有的技术），再将同城灾备中心的数据备份到异地灾备中心。
	按以上备份策略，在保留原有生产中心和同城灾备中心的连接架构不变的情况下，建立同城灾备中心与异地灾备中心的数据复制链路。
	为实现异地灾备中心的应用级灾备，各地各分支行需要连接到异地灾备中心，当某个分支行与生产中心的线路出现故障时，需要切换到异地灾备中心时，此时不启用异地灾备端的应用系统，而是在异地灾备端建立一条到生产端的路由，迂回到生产端的应用服务器。基于考虑，在生产中心和异地灾备中心建立一条专线，用于分支行的访问生产中心的冗余备份线路。

数据复制及备份方案：

![微信图片_20180509103300.png](/home/attachment/201805/09/9781_152583319886360.png)

数据复制选择的是NETAPP的SNAPMIRROR技术，这种数据复制技术在三个数据中心之间只能采用层叠的方式。所以数据复制的路线是从生产中心先通过SNAPMIRROR同步复制到同城灾备中心，再通过同城灾备中心把快照数据异步复制到异地灾备中心。

生产中心和同城灾备中心的数据复制是通过千兆裸光纤。

同城灾备中心和异地灾备中心的数据复制是通过专线连接。
### 4.2.1	数据方式
1、同城数据备份：
采用原有的数据备份方式，将生产端的数据从生产中心的NETAPP上使用SnapMirror技术通过千兆以太线路备份到同城的NETAPP 。

2、异地数据备份：
数据从生产中心通过SnapMirror把数据从NETAPP存储上复制到同城灾备中心的NETAPP上，同城的上把盘阵的数据使用SnapShot生成快照，通过同城和异地之间的SnapMirror把快照传送到异地灾备中心，再把快照还原成数据。

3、本地磁带备份：
某行核心业务系统包括综合业务系统、现代化支付系统、中间业务前置、银行卡前置都是存储在NETAPP上，使用IBM作为数据备份的磁带库，包含30盘800G磁带，2个LTO3磁带驱动器。使用IBM Tivoli Storage Manger软件实现备份数据的集中管理，将各业务系统数据集中备份到磁带库中，通过策略设置实现自动的定时备份，自动的版本控制。使用TSM for Informix的归档模式，允许时间点恢复，确保故障发生时最少的数据丢失。
### 4.2.2	备份线路
生产中心到同城灾备中心的数据复制是两端的千兆光纤以太网实现，复制方式采用准同步方式。

同城灾备中心到异地灾备中心也采用SnapMirror数据复制技术，按照SnapMirror数据复制技术的原理，结合数据复制量，建议如下：
	同城灾备中心与异地灾备中心之间采用1条8M的专线实现数据复制。
	异地灾备中心与生产中心采用1条2M的专线作为分支行冗余备份线路和管理线路。
### 4.2.3	备份技术
同城和异地灾备中心采用NETAPP盘阵复制技术（SnapMirror），异地灾备端建议配置本地备份软件及带库。

![微信图片_20180509103957.png](/home/attachment/201805/09/9781_152583361256634.png)

以生产中心、同城灾备中心、异地灾备中心部署的NETAPP存储，采用级联的方式，将生产中心数据先复制到同城灾备中心后，再复制到异地灾备中心。
### 4.2.4	备份线路
	生产中心到同城灾备中心是通过千兆以太网进行连接。
	同城灾备中心到异地灾备中心是通过10M 专线连接。
	生产中心到异地灾备中心是通过4M专线连接。
### 4.2.5	备份资源
某市生产中心和同城灾备中心的NetApp FAS系统裸容量都是5TB，因生产中心存储需要通过快照的形式把数据备份到异地灾备中心，所以在异地灾备中心的存储容量配置成6TB，在存储上划分3个分区用来分别存放3套系统的数据，银行卡系统在本地硬盘，见下表：

![微信截图_20180509104054.png](/home/attachment/201805/09/9781_152583367170070.png)

## 4.3	异地灾备主机方案
### 4.3.1	生产中心配置现状
某行生产中心现有两台IBM小机作为集中的生产服务器，每台小机做到4个分区，两台小机的分区之间两两用HACMP集群实现本地服务器之间的高可用性。2台IBM 小机主机采用的是HACMP热备份方式，平时所有的生产业务都是跑在ACTIVE的主机上，另外一台处于STANDBY的状态。IBM 每台小机划分4个分区，具体划分

![微信截图_20180509104148.png](/home/attachment/201805/09/9781_152583372482994.png)

### 4.3.2	异地灾备配置方案
主机配置原则：

1)	兼容性：
–	配置与生产中心完全兼容的异地灾备中心主机处理系统，以保证当同生产中心发生灾难时，异地灾备中心有接管的能力。
–	异地灾备中心主机应在内码、操作系统、数据库、中间件及应用软件等各个层次上与生产中心完全兼容。

2)	升级扩展：
异地灾备中心的主机应具有较强的本地升级和扩展能力，以保证未来3~5年业务发展对主机数据处理系统的要求。

3)	可靠性和可用性：
异地灾备中心的主机应具有良好的系统自愈能力，保证系统的可靠性和可用性；

4)	设备配置原则：
异地灾备中心主机设备的硬件配置应与生产中心的主机配置一致，或略低于生产中心的主机配置。

异地灾备中心主机配置方案
建议在灾备中心采用一台与生产中心同型号、同配置的IBM小机主机，并和生产中心一样在IBM 小机上开4个逻辑分区，分别跑综合业务系统、现代化支付系统、中间业务前置、银行卡前置等。

## 4.4	灾备网络方案
建设异地灾备目的是为某行开异地分支行，并且防范在某市地区发生区域性灾难时，某市以外地区的分支行业务不中断。 在网络连接方案里，异地分行有两条线路，一条连接生产中心，一条连接异地灾备中心。建议市内的支行和未来要建立的分行可以连接异地灾备中心，如果考虑到长途线路租用费用的问题，考虑某市内的支行的两条线路，一条连接生产中心，一条连接同城灾备中心。具体线路如下：

	异地灾备中心和生产中心连接
异地灾备中心使用接入路由器H3C MSR上的一块ATM板卡的155M端口，分出一条2M时隙和生产中心的NE5进行连接，用于管理连接和分行备线路由到总行的线路。

	异地灾备中心和同城灾备中心连接
异地灾备中心使用接入路由器H3C MSR上的ATM板卡155M端口，分出一条8M时隙和同城灾备中心的H3C MSR上ATM板卡端口进行连接。这条8M线路主要是同城到异地的数据复制线路。其网通，电信各一条互备，平时一条复制数据，一条管理或分行备线路由到总行的线路。

# 5	异地灾备细则
考虑到灾备建设成本与风险损失的关系及异地灾备建设资金投入量，异地灾备系统可考虑采用分步实施的策略，先完成异地灾备系统的数据级灾备，再进行异地灾备系统的应用级实施。对本期实施的核心生产系统相关业务的异地灾备系统。
## 5.1	数据级灾备建设
### 5.1.1	数据级灾备拓扑

![微信图片_20180509105012.png](/home/attachment/201805/09/9781_152583424086927.png)

在异地灾备中心部署灾备主机（与生产中心主机资源匹配）、灾备存储设备、网络交换机、光纤盘阵交换机、路由器等相关设备，并根据数据复制产品SnapMirror的层叠技术特性完成由同城灾备中心至异地灾备中心的数据灾备过程。

异地灾备中心使用接入路由器H3C MSR上的一块ATM板卡上的155M端口，分出不同的时隙，同城和异地灾备中心通过网通和电信各10M连接，生产中心和异地通过4M连接。

数据从生产中心通过SnapMirror把数据从NETAPP存储上复制到同城灾备中心的NETAPP上，并在同城的上把盘阵的数据使用SnapShot生成快照，通过同城和异地之间的SnapMirror把快照传送到异地灾备中心，再把快照还原成数据。

按照SnapMirror数据复制技术的原理，结合数据复制量，建议同城灾备中心与异地灾备中心之间采用2条10M的专线实现数据复制，网通电信各1条，1条主线，1条备份和管理线路。
### 5.1.2	存储部署设计
某市生产中心和同城灾备中心的NetApp FAS0系统裸容量都是4TB，所以建议在异地灾备中心的存储容量配置成4.2TB，并议在存储上划分3个分区用来分别存放3套系统的数据，银行卡系统在本地硬盘：

![微信截图_20180509105419.png](/home/attachment/201805/09/9781_152583447638850.png)

## 5.2	应用级灾备建设
数据级灾备建设完成后，按照总体规划进行建设异地灾备的应用级灾备升级完善工作。
### 5.2.1	应用级灾备拓扑

![微信图片_20180509105520.png](/home/attachment/201805/09/9781_152583454952090.png)

**应用级灾备需在异地灾备中心追加部署与外联单位连接的相关设备，并实施各分支行网点及外联单位的链路接入。**

异地灾备中心使用接入路由器H3C MSR上的2块ATM板卡上的155M端口，分出不同的时隙与各分支行（4M）进行单线路连接。

考虑到安全管理要求，与人行等外联单位接入需单独采购网络设备及部署单独线路。同时以上设计可满足各分支行经过异地灾备中心路由至生产中心的网络需要，即当各分支行和生产中心的专线发生故障时，可先通过异地灾备中心再到达生产中心。

**数据级到应用级灾备是平滑过渡的，应用级灾备是在数据级灾备基础上扩展的，没有重复投资，不会对数据级灾备实施的资源造成浪费，在保证其合理灾备成本的同时，保证异地灾备中心建设的可连续性。**

异地容灾数据保护容灾备份方案数据备份

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！