银行应用级灾备建设方案

合集下载

银行灾备方案

银行灾备方案

银行灾备方案近年来,随着科技的不断发展,金融行业的信息系统也越来越复杂和庞大。

然而,随之而来的是与之相伴的各种灾难风险。

无论是自然灾害、网络攻击还是人为失误,这些威胁都可能对银行的正常运营和客户的资金安全造成严重影响。

因此,制定健全的银行灾备方案,成为保障金融体系安全运转的重要措施之一。

一、灾备体系的建立银行灾备方案的首要任务是建立一个完备的灾备体系。

该体系应包括两个关键的要素:一是远程数据备份系统,二是灾备数据中心。

远程数据备份系统可以实现实时数据备份,确保即使在发生灾难的情况下也能保持数据的完整性。

而灾备数据中心则是一个被动式应急中心,可以在系统遭受破坏或无法正常运行时发挥作用。

二、数据保护与备份数据是银行最宝贵的财富之一,也是信息系统的核心。

因此,科学合理的数据保护与备份策略至关重要。

银行应该设立专门的数据备份中心,每天定期对核心数据进行备份,以防数据丢失。

此外,定期测试备份数据的可用性也是非常必要的,只有在真实的演练中,才能真正检验备份系统的可靠性。

三、恢复计划的制定一旦银行遭受灾害,恢复计划将变得至关重要。

恢复计划是指一套行之有效的步骤和方法,以保证银行能够在灾难发生后尽快恢复正常运营。

在制定恢复计划时,银行应充分考虑各种可能的灾难情景,制定应对措施,并对关键的业务和系统进行优先级排序。

四、灾害演练与评估灾害演练是为了模拟真实的灾难情景,检验灾备方案的有效性。

灾害演练应包括两个阶段:内部演练和外部演练。

内部演练主要针对银行内部员工,通过模拟灾难情景,检验员工的应急反应和合作配合能力。

而外部演练则是与其他金融机构、监管机构等进行合作,以检验不同机构在灾害情景下的应对能力。

五、定期更新与改进灾备方案并非一劳永逸的,随着科技的不断更新和体系的变化,方案也需要进行定期的更新和改进。

银行应建立一个固定的审查机制,每年至少进行一次灾备方案的评估,并根据评估结果进行相应的修订和改进。

结语银行灾备方案是保障金融体系安全运转的重要保障措施。

银行应用系统灾难备份系统设计方案

银行应用系统灾难备份系统设计方案

银行应用系统灾难备份系统方案1、概述随着计算机技术和通讯技术的高速发展,以计算机和通讯技术为基础的金融电子化系统得到了飞速发展。

**银行**省分行为了发挥计算机城市综合网系统的最大优势,在市场竞争中保持**银行现有的科技优势,能够给大行业大企业提供全省范围内的优质服务,加强城市综合网系统的安全运行。

规划将**银行**省分行全省范围内的客户数据帐务信息,集中到省分行运行中心统一处理,这是计算机应用技术发展的必然,也是**银行**省分行业务发展的需要。

随着数据集中处理的实施,可以预计,**的业务运作、经营管理将越来越依赖于计算机网络系统的可靠运行。

**银行所提供金融服务的连续性以及业务数据的完整性、正确性、有效性,会直接关系到我们**的生产、经营与决策活动。

一旦因自然灾害、设备故障或人为因素等原因引起计算机网络系统停顿导致信息数据丢失和业务处理中断,将会给**银行**省分行造成巨大的经济损失和声誉损害,受到致命的打击。

将全省客户帐务数据集中统一处理,因数据集中处理伴随而来的运行风险将因为灾难发生大大增加。

生产运行主机系统及其配套设备一旦发生故障,就会导致在全省**银行范围内所有营业柜台停止营业的风险。

会计、储蓄、信用卡等**银行的三大主营业务的停业,**银行**省分行面临的将是灾难性打击。

因此,生产运行系统的灾难备份系统就显得格外重要。

我们认为,一旦实施全省数据集中,灾难备份系统应该与生产运行应用系统(全省集中)同步投入使用,保证全省数据集中处理系统的运行安全。

根据**银行**省分行数据集中处理领导小组的统一安排,1999年10月10日到10月20日,分行科技处组织人员在**市龙泉,进行封闭式工作,制定城市综合网系统全省数据集中处理规划,本应用系统灾难备份系统**规划是其中很重要的分部。

1.1 计算机系统灾难备份概念简介1.1.1 计算机系统灾难定义计算机系统灾难是指造成重要业务数据丢失,使业务中断了不可忍受的一段时间的计算机系统事故,这些事故导致银行丧失了全部或部分业务处理能力,引起企业营业收入下降、信誉降低和形象受损,甚至威胁其生存。

XX银行灾备系统建设

XX银行灾备系统建设

银行灾备系统建设在建设灾备系统的过程中,XX银行遵循国际灾备组织的科学方法论,在风险分析、业务影响、灾备策略、技术方案、业务连续性等灾备建设的各环节,借力专业服务商的能力与经验,在较短的时间内快速、高效地完成XX银行灾备系统的建设工作。

近年来,随着业务的高速发展,XX银行信息化建设的力度也越来越大,各类系统和数据逐步实现大集中,IT对业务的整体覆盖率达到84%。

IT的大集中也带来了系统风险的集中。

作为银行业务连续运行的保障,灾备系统建设一直都是科技部门的一项重要工作。

XX银行十分重视这项工作,其灾备系统建设经历了数据异地备份、灾备系统外包和自建灾备中心等几个阶段。

本文将对XX银行的灾备系统建设进行回顾和思考,并探讨了下一步的建设思路。

一、建设灾备系统的必要性1.银行业务发展的需要相关资料表明:金融行业在灾难停机两天内所受损失为日营业额的50%,如果在两个星期内未能恢复信息系统的正常运作,75%的公司将出现业务停顿,43%的公司可能再也无法开业,没有实施灾备系统措施的企业60%将在灾难后的2~3年间破产。

由此可见,灾备和业务连续性建设直接关系银行生死存亡和可持续性发展的关键问题。

2.监管合规性的要求一直以来,监管部门对银行信息科技风险管理给予了高度重视,近期也已连续发布了一系列的监管指引和要求。

银监会下发的《商业银行数据中心监管指引》中明确要求:商业银行应于取得金融许可证后两年内,设立生产中心;生产中心设立后两年内,设立灾备中心;总资产规模一千亿元人民币以上且跨省设立分支机构的商业银行应设立异地灾备中心,灾难恢复等级达到《信息安全技术信息系统灾难恢复规范》中的第5级实时数据传输及完整设备支持。

业务的发展和监管,都要求必须建立起完善的灾备体系和业务连续性保障体系。

二、灾备系统建设思路如何建设灾备系统需要周密规划:除了要考虑技术实现外,还要考虑各类业务的不同需要;除了考虑资源投入外,还要考虑产出和利用;除了考虑通用的灾备模式,还要考虑自身的情况和能力。

2024年银行自然灾害防洪防汛应急预案

2024年银行自然灾害防洪防汛应急预案

2024年银行自然灾害防洪防汛应急预案____年银行自然灾害防洪防汛应急预案第一章:灾害概述和背景1.1 灾害概述____年,全球气候变化导致的极端天气事件频发,各地银行面临着越来越多的自然灾害风险。

其中,洪水是一种常见的自然灾害,对银行的运营和资产安全带来了巨大的威胁。

因此,银行需要建立一套完善的防洪防汛应急预案,以减轻自然灾害对金融机构的影响。

1.2 预案背景银行是金融系统的重要组成部分,负责存储和管理大量资金和客户信息。

然而,银行机构普遍位于市中心或重要交通要道旁边,容易受到洪水的影响。

一旦发生洪灾,银行可能面临的风险包括:金融资产丢失、系统瘫痪、设备损坏、客户数据泄露等。

因此,建立一套完善的防洪防汛应急预案对于银行的可持续发展至关重要。

第二章:预案目标和原则2.1 预案目标本预案的目标是确保银行在洪水发生时能够快速、有序地应对,并最大限度地减少损失和对金融系统的影响。

具体目标包括:- 保障员工和客户的人身安全;- 保护金融资产和设备的完整性;- 尽快恢复业务运营和系统功能;- 保护客户隐私和数据安全。

2.2 预案原则本预案的制定遵循以下原则:- 安全第一:员工和客户的人身安全是最重要的。

- 效率优先:在保障安全的前提下,尽可能快速地恢复业务运营和系统功能。

- 防范为主:通过提前的防洪措施和预警系统,最大限度地降低洪水带来的损失。

- 综合应对:预案要涵盖各个环节和部门,实现协同应对和资源共享。

第三章:组织架构和应急响应体系3.1 预案组织架构为了实现灾情应对的快速和高效,建立一个科学合理的组织架构是必要的。

预案组织架构主要包括指挥部、应急小组和后勤保障组。

- 指挥部:由高层管理人员组成,负责决策和指导应急工作。

- 应急小组:由具备相关专业知识和技能的人员组成,负责具体的应急工作,包括灾情分析、救援行动、业务恢复等。

- 后勤保障组:负责提供应急物资和保障应急工作的物质条件。

3.2 应急响应体系应急响应体系是指在灾害发生时,按照一定的程序和步骤进行应对和处理的体系。

银行双活容灾建设方案技术手册-规划篇

银行双活容灾建设方案技术手册-规划篇

银行双活容灾建设方案技术手册——规划篇目录1、应用层数据复制架构选型规划 (3)2、存储层数据复制架构选型规划 (10)3、整体架构各功能层分解规划设计 (16)4、核心系统双活基础架构规划设计 (19)随着全球IT产业的飞速发展,金融行业的IT建设逐步成为主导金融企业业务发展的核心驱动力,基于金融行业IT系统建设的各种行业标准以及监管标准也相应提高。

IT系统架构的扩展性、灵活性以及容灾能力就成为衡量企业IT建设很重要的标准。

本手册以某银行同城双数据中心建设过程为背景,详细从系统架构集成、资源云化、存储整合以及数据容灾等多个关键方面阐述其规划思路以及建设过程,旨在为同业在此类项目规划和建设过程中提供一些启示和帮助。

1、应用层数据复制架构选型规划1.1 应用事务日志回放技术下图是Oracle数据库层面的数据复制技术(ADG)的架构原理图。

对于该架构原理图,本文从其实现的基本条件、数据复制原理、数据复制的模式以及数据复制的关键因素等几个方面来进行深度剖析。

Oracle Active Data Guard1.1.1 前提条件容灾站点之间需要有三层以太网连通,软件层面需要数据库的集群软件模块(Oracle Active Data Gurard)或者是db2 purscale hadr。

服务器层面需要至少两套服务器系统分别部署于两个数据中心。

存储层面需要两套存储空间分别部署于两个站点作为主库存储和备库存储,他们互相之间独立。

1.1.2 复制原理对于主站点的数据库来讲,客户端的数据更新请求首先要由日志写入进程写到重做日志当中,然后由数据写进程再周期性地写入数据文件当中。

重做日志当中以SCN为数据库独有的时间搓序列来记录所有数据库更新的先后顺序,从而保障数据库恢复能够按照正确的顺序执行保障数据一致性和完整性。

那么对于配置了Active Data Guard的数据库读写的完成在以上所述过程中,日志写进程在本地日志文件写入过程的同时,日志传输进程会将缓存里面的重做日志通过ADG传输给灾备站点的备库实例,备库实例的日志接收进程根据接受到的重做日志在备库上重新执行数据库的更新操作,从而保证主库和备库的事务性更新行为一致性,最终保证数据的一致。

同城应用级灾备建设项目可行性报告

同城应用级灾备建设项目可行性报告

江苏长江商业银行同城灾备建设调研及可行性报告我行科技信息部在项目启动后,主要完成了以下几个方面的工作:一是学习了监管机构对于业务连续性和灾备中心建设的相关要求和规范。

二是先后与省内多家金融机构进行了沟通交流,取得了其它金融机构在灾备中心建设中的成熟经验和做法。

三是与国内多家较大的系统服务商和云计算服务商进行了技术交流沟通,了解当今主流容灾技术、云计算技术和虚拟化技术的现状和发展趋势。

四是和省内多家数据中心外包服务商进行了沟通交流,了解数据中心基础环境设施、外包服务资源、运维服务能力,调研结果及项目可行性报告如下:一、我行同城灾备中心建设必要性(一)、不断提高的业务连续性要求信息系统安全运行是企业正常生产的基础,随着我行规模的逐步扩大,各种金融应用、支付手段、服务渠道不断增加,对业务连续性的要求也越来越高,任何重要交易系统的非正常停运,都会对企业的声誉产生非常严重的影响,甚至可能造成无法预测的重大损失。

由此可见,信息系统的安全及业务连续性直接关系到客户和切身利益和银行生死存亡。

所以,建设切实有效的同城应用级灾备中心对我行极为必要的。

若生产中心发生不可恢复故障或灾难,同城灾备中心可迅速恢复接管生产运行并实现业务办理,能极大地提高业务持续运行能力,降低信息系统安全风险。

(二)、监管机构对灾备建设的要求监管机构对我行的业务连续性风险管理非常重视,。

2015年江苏省法人银行金融机构信息科技风险管理指导委员会全体会议中,银监局指出的辖内金融机构信息科技现存的问题,列举了各家金融机构科技信息建设和风险管理方面的不足。

并且,省银监局潭局长要求我行务必于2016年启动同城灾备系统建设,全面提高我行信息科技抗风险能力,要及时启动构建同城灾备中心,发挥其接管业务、延续业务和双活运行的作用。

我行高管层组织了科技部门负责人,认真学习了省银监局潭局长在会议上的讲话,根据省我行董事会和高管层非常重视监管领导提出的同城灾备中心建设意见,已把同城灾备中心建设列为我行全年的重点项目之一。

商业银行灾备体系建设方法分析

商业银行灾备体系建设方法分析

商业银行灾备体系建设方法分析(发表于《金融电子化》2010年10月刊)2012-03-23 16:26阅读(31)评论(0)商业银行灾备体系建设方法分析随着金融业务对信息系统的依赖性日益增强,商业银行越来越重视生产中心信息系统的高可用性,投入了大量资源和人员。

但是,在灾备体系建设方面,一方面由于起步较晚,另一方面由于我国还没有发生过导致银行生产中心瘫痪的灾难性事件,所以各家商业银行的经验并不是很丰富。

本文在分析并明确灾备工作定位的基础上,归纳设计了灾备体系框架,并介绍了建设灾备体系的基本步骤,以供参考。

一、灾备工作定位对企业来说,造成关键业务功能或流程中断的时间超过企业最大容忍程度的突发事件,都可以认为是灾难。

对商业银行来说,由于几乎所有金融业务都依赖于信息系统的支撑,所以灾备管理通常是指信息系统的灾难备份与恢复管理,目的是为了应对生产中心信息系统发生严重故障或者瘫痪,已不能在可接受的时间内在生产中心本地恢复,通常需要将信息系统切换到灾备中心运行的情况。

灾备管理、应急管理、业务连续性管理和风险管理是经常容易混淆的几个概念。

根据巴塞尔协议,商业银行风险管理包括对市场风险、信用风险和操作风险的识别、评估、监控、缓释和控制。

业务连续性管理主要针对可能导致业务中断的风险或者已经发生并导致业务中断的事件进行管理。

应急管理主要关注对各种突发事件的应急处置,该突发事件不一定会导致业务中断,但一定会对业务造成影响。

可见,业务连续性管理和应急管理都是风险管理的组成部分,并且业务连续性管理与应急管理之间存在一部分交集,这个交集就是对导致业务中断的突发事件的管理。

灾备管理是业务连续性管理和应急管理交集中的一种极端特殊情况,是专门针对IT灾难的。

上述各个概念之间的关系及举例如下图所示:二、灾备体系参考框架灾备体系建设是一项庞大而复杂的系统工程,必需在清晰、合理的框架指导下,协调有序地开展工作。

灾备体系建设需要从管理技术、管理和业务三个方面进行,三者之间相辅相成,是灾备体系不可或缺的有机组成部分。

商业银行应用级灾备规划和建设经验

商业银行应用级灾备规划和建设经验

商业银行应用级灾备规划和建设经验1 、灾备定义灾备顾名思义,就是灾难备份,对于银行业来说,无论是监管机构的规定,还是出于银行重要业务的可靠性要求,都是一件必须要考虑的事情。

银行业的灾备建设,从原始的灾难备份要求,逐渐演变为灾难快速响应及快速切换要求。

通俗来讲,就是从数据级灾备过渡到应用级灾备的需求。

灾备建设主要有以下几个要点。

数据:无论是哪种灾备建设要求,都是基于数据出发的,数据保护是灾备建设的基本。

数据级灾备是要求灾备数据的存在性,当然,还需要定期的验证计划来保证这部分数据时可用的。

应用级灾备就要求在保证数据存在前提下,向灾备数据持续可用性转变的过程。

相对地对系统建设的要求和成本,也就要高很多。

数据同步:保证数据同步的一致性和实时性才能使灾备应用的接管有效。

目前主要的数据同步方式有两种,应用层同步和存储阵列同步。

考虑到目前城商行规模和实际场景,大部分都已经实现了共享的开放平台存储,所以基本上都采用了各存储厂商提供的数据复制技术来实现(同步异步可选),如 EMC 的 SRDF、IBM 的 metro mirror、HDS 的true copy 等,使用下来可以说同步复制技术几乎没有差别,都是基于一致性写实现的;异步复制技术区别也不大。

存储:简单来说,存储是所有数据的载体,是现在灾备建设基础设备。

实践经验告诉我们,对于有建设同城灾备甚至两地三中心需求的机构,尽量能够采用各型存储中的高端型号,避免在中端存储的复制稳定性和 license 限制上受局限。

网络:网络环境是灾备建设最底层的需求。

灾备网络需要满足这么几个要点:生产隔离+网络联通性,网络对称性+适量冗余,安全访问+自动分发。

2 、灾备建设原则2.1、数据一致性。

实时检验数据复制的状态,保证数据传输链路的稳定。

并建立应用校验机制,定期验证数据的一致性2.2、完善的流程。

建设灾备,就必须同步建设相应的灾备切换流程和应用同步流程,这有助于降低日常灾备维护压力,提高灾备中心规范化同步,保证双中心的系统能够同步上线。

银行灾备实施方案

银行灾备实施方案

银行灾备实施方案一、前言。

随着信息技术的不断发展,银行业在日常运营中越来越依赖于信息系统。

然而,信息系统的稳定性和安全性往往受到各种自然灾害和人为因素的威胁,一旦发生灾害,可能对银行业务造成严重影响。

因此,建立健全的银行灾备实施方案显得尤为重要。

二、灾备方案的重要性。

银行作为金融机构,其业务具有高度的复杂性和敏感性,一旦遭受灾害,将对客户的资金安全和日常交易产生重大影响。

因此,建立完善的灾备实施方案,可以最大程度地减少灾害对业务的影响,保障银行业务的持续稳定运营。

三、灾备方案的内容。

1. 风险评估与规划。

首先,银行需要对可能影响业务的各类灾害进行风险评估,包括自然灾害(如地震、洪水等)和人为灾害(如网络攻击、恶意破坏等)。

在风险评估的基础上,制定相应的灾备规划,明确各类灾害发生时的处置流程和责任人,确保在灾害发生时能够迅速有效地应对。

2. 数据备份与恢复。

银行业务的核心是数据,因此数据备份和恢复是灾备方案中至关重要的一环。

银行需要建立完善的数据备份体系,包括定期备份和异地备份,确保数据的安全性和可靠性。

同时,需要建立快速、高效的数据恢复机制,以便在灾害发生后能够迅速恢复业务数据,保障业务的正常运营。

3. 硬件设施与应用系统。

除了数据备份外,银行还需要对硬件设施和应用系统进行灾备规划。

这包括建立备用的数据中心和服务器设备,以及制定应用系统的灾备恢复方案。

在灾害发生时,可以通过切换到备用设施和系统,确保业务的连续性和稳定性。

4. 人员培训与演练。

最后,银行需要对员工进行灾备意识培训,确保员工能够在灾害发生时迅速有效地应对。

同时,需要定期组织灾备演练,检验灾备方案的可行性和有效性,及时发现和解决存在的问题,保障灾备方案的实施效果。

四、总结。

银行灾备实施方案是保障银行业务持续稳定运营的重要保障措施。

通过对各类灾害进行风险评估和规划,建立完善的数据备份和恢复机制,以及对硬件设施和应用系统进行灾备规划,银行可以有效应对各类灾害,保障业务的连续性和稳定性。

银行灾备方案

银行灾备方案

云存储项目大数据平台解决方案目录1概述21.1建设背景21。

2设计范围21。

3总体设计原则22云存储系统平台设计42.1项目需求52。

2设计思想62。

3云存储系统方案72。

4系统优势和特点73系统架构83.1系统基本组成93。

2系统功能描述94系统安全性设计124.1安全保障体系框架124。

2云计算平台的多级信任保护134。

3基于多级信任保护的访问控制164。

4云平台安全审计185工作机制215。

1数据写入机制215.2数据读出机制216关键技术216.1负载自动均衡技术216.2高速并发访问技术226.3高可靠性保证技术226。

4高可用技术236.5低功耗存储技术236.6分布式、分级、动态存储技术237接口描述257。

1POSIX通用文件系统接口访问257。

2应用程序API接口调用258本地容错与诊断技术268.1 cStor高可靠性268.2 cStor数据完整性268。

3 cStor快照技术279异地容灾与恢复技术279。

1cStor数据备份与恢复系统功能279。

2cStor异地文件恢复289。

3cStor数据迁移归档281概述1.1建设背景随着银行数据集中处理的实施,银行业务运作、经营管理将越来越依赖于计算机网络系统的可靠运行。

银行所提供金融服务的连续性以及业务数据的完整性、正确性、有效性,会直接关系到银行的生产、经营与决策活动.一旦因自然灾害、设备故障或人为因素等原因引起计算机网络系统停顿导致信息数据丢失和业务处理中断,将会给银行造成巨大的经济损失和声誉损害,受到致命的打击.生产运行系统的灾难备份系统就显得格外重要。

我们认为,一旦实施银行数据集中,灾难备份系统应该与生产运行应用系统同步投入使用,保证银行数据集中处理系统的运行安全。

1.2设计范围本技术解决方案针对海量数据集中存储与共享,提供从系统软硬件技术架构、原理、硬件选型、网络接入以及软件与应用之间的接口等方面的全面设计阐述。

1.3总体设计原则针对本次工程的实际情况,充分考虑系统建设的建设发展需求,以实现系统统一管理、高效应用、平滑扩展为目标,以“先进、安全、成熟、开放、经济”为总体设计原则.1.3.1先进性原则在系统总体方案设计时采用业界先进的方案和技术,以确保一定时间内不落后。

商业银行灾备体系建设方法分析

商业银行灾备体系建设方法分析

商业银行灾备体系建设方法分析一、需求分析商业银行灾备体系建设的首要任务是进行需求分析。

首先要明确银行所面临的灾备需求,包括业务持续性需求和数据安全性需求。

其次,要考虑灾备体系的规模和范围,例如是否需要建设多个数据中心或灾备中心。

同时还需要分析银行的业务流程和数据流动,确定关键业务、关键数据和关键系统,以便有针对性地进行灾备体系建设。

二、风险评估在灾备体系建设之前,商业银行需要进行风险评估,确定可能会遇到的各种灾害和紧急情况,并评估对银行业务和数据的潜在影响。

这些风险包括自然灾害、人为事故、设备故障等。

在评估的基础上,商业银行可以制定相应的预防和应急措施,以减轻潜在的风险。

三、架构设计灾备体系的架构设计是商业银行灾备体系建设的核心环节。

架构设计应该符合银行的业务需求和风险评估的结果,确保在灾害或紧急情况下能够实现业务的持续性运行和数据的安全性。

架构设计应该包括数据中心的布局、灾备设备的选择和配置、网络拓扑设计、灾备流程的设计等。

四、设备选型灾备体系的设备选型是商业银行灾备体系建设的重要环节。

在设备选型过程中,商业银行应该考虑设备的可靠性、性能、扩展性和兼容性等因素。

同时还要考虑设备的投资成本和运维成本,以确保投资回报率。

设备选型应该综合考虑商业银行的业务需求、架构设计和风险评估的结果。

五、数据备份商业银行灾备体系建设的关键环节之一是数据备份。

商业银行需要制定完善的数据备份策略,包括备份的频率、备份的存储介质、备份的存储位置等。

同时还要考虑数据备份的恢复性和可靠性。

商业银行还需要定期测试数据备份方案,以确保备份的完整性和可恢复性。

六、应急响应商业银行在灾备体系建设之后,还需要建立完善的应急响应机制。

这包括灾备演练、应急预案的编制、人员培训等。

商业银行需要定期进行灾备演练,以验证灾备体系的有效性和可行性。

应急预案应该涵盖各类灾害和紧急情况的应对措施和流程,并确保相关人员熟悉和掌握应急预案。

七、监控与管理商业银行灾备体系建设完成后,需要建立健全的监控与管理系统。

银行应用级灾备建设方案

银行应用级灾备建设方案

银行应用级灾备建设方案目录1项目背景及建设需求 (3)2各系统数据备份概况 (4)3灾备端应用部署规划 (5)4灾备网络通信系统 (7)5各业务系统应用级部署工作计划 (8)6各业务系统应用部署工作分解 (9)6.1系统部署 (9)6.1.1AIX平台 (9)6.1.2虚拟机平台 (9)6.2FTP环境构建 (10)6.3系统验证 (11)6.3.1验证前准备 (11)6.3.2单系统验证 (15)6.3.3系统集成验证 (16)7项目主要风险点 (17)1项目背景及建设需求目前,我行灾备项目已完成核心业务域和城商业务域数据级同城备份,通过两台IBM中端磁盘阵列实现了两大业务域关键数据从生产中心到灾备中心的同城复制。

其中:✧DS5100承载ESB、加密平台、图形前端数据库三个系统数据复制,未实现数整报表系统的数据复制✧DS5020承载PCSP(综合前置)、ATMP、虚拟化平台数据复制,未实现财务系统(NC)数据复制按山东省银监局相关要求:2013年三季度,需要完成国际结算、信贷、图形前端、票据、手机银行、NC、ATMP、数整报表、加密平台、综合前置、ESB等十一个重要业务系统的应用级灾备建设。

2各系统数据备份概况十一个业务系统数据存储及异地备份概况统计如下表:从上表可知,ESB、加密平台、图形前端、ATMP、综合前置(PCSP)等五个系统数据通过磁盘阵列实时复制到灾备端,数整报表、国际结算、信贷、票据、手机银行、财务系统等六个系统数据则通过每日全备、定时FTP传送至灾备端。

3灾备端应用部署规划目前,灾备中心网络链路已就绪,各业务系统应用服务器硬件已完成上架、加电测试等相关工作。

各系统部署规划如下表:系统名称系统平台数据库应用灾备端服务器配置ESB AIX6100-07 DB2 9.1 P740一台加密平台AIX6100-07 P720一台SQLServer虚拟机图形前端Windows20082008ATMP AIX5300-12 Oracle10g P720一台综合前置AIX6100-07 P720一台数整报表AIX6100-07 DB2 9.1 P740一台国际结算Windows2003 虚拟机信贷系统Windows2003 虚拟机票据系统SLES10 虚拟机手机银行SLES11 虚拟机财务系统AIX5300-12 P720一台(NC)其中:✧虚拟机平台物理服务为四台IBM 3850 X5✧图形前端数据库服务器、应用服务器均部署在虚拟机平台✧国际结算、信贷、票据、手机银行四个系统也部署在虚拟机平台上✧加密机为独立硬件✧加密平台、ATMP、PCSP、NC四个系统分别部署在4台P720小机内✧ESB、数整报表两个系统分别部署在两台P740小机内4灾备网络通信系统网络通信系统详见《我行灾备中心建设方案》。

银行异地灾备建设方案-NBU5220

银行异地灾备建设方案-NBU5220

Your Infrastructure. Your Information. Your Interactions. Only Symantec Protects Them All.XX银行异地三期系统灾备建设方案赛门铁克软件(北京)有限公司2013年3月目录第1章现状与需求 (3)1.1 综述 (3)1.2 灾备建设目标 (3)1.3 系统信息 (3)第2章方案描述 (8)2.1 设计规划 (8)2.2 整体架构 (8)2.3 配置说明 (9)第3章技术要素 (11)3.1 备份数据自动复制(A.I.R) (11)3.2 SAN-Client架构 (11)第4章 NetBackup 5220产品介绍 (13)第1章现状与需求1.1 综述本方案涵盖XX银行灾备建设异地三期,灾备等级为1-3级的31个系统,共有各类型主机约110台,总数据量7.5TB。

这些系统部署在西三期和Site2两个同城机房,方案目标是实现所有系统本地数据集中备份和苏州灾备中心的异地数据容灾。

1.2 灾备建设目标本方案要实现的灾备建设目标为:3级重要系统异地灾备恢复能力RTO,RPO小于24小时;其余的1、2级系统RTO为1-2天;RPO为1-7天。

1.3 系统信息下表是31个系统的详细信息,包括系统名称、服务器类型、数据量等:第2章方案描述2.1 设计规划本方案针对三期系统灾备异地建设,建议采用在同城两个生产中心建立一套备份系统,将数据集中备份,然后再由专用设备自动复制备份数据至苏州灾备中心的设计思路,来实现异地容灾。

专用备份设备需具有对备份数据实时重复数据删除能力,同时有良好的数据重删比率。

这样备份数据经过优化缩减,可更好的适应网络远程传输。

备份系统在整个IT框架中,是位于生产系统体系架构以外的一套独立系统,它与处于核心位置的生产系统(如应用系统服务器、应用数据库、生产数据存储)是一种松耦合关系。

这一特点使得我们在部署备份系统、完成基于备份系统的数据复制时,不会对生产系统造成任何影响,也几乎不需要生产系统做任何改动,这会大大降低灾备建设可能会给生产系统带来的负面影响。

银行双活容灾建设方案技术手册-分析篇

银行双活容灾建设方案技术手册-分析篇

银行双活容灾建设方案技术手册——分析篇目录1、双活数据中心的驱动力 (3)2、定义符合自己的双活模式 (4)3、实现双活需要考虑的关键因素 (14)随着全球IT产业的飞速发展,金融行业的IT建设逐步成为主导金融企业业务发展的核心驱动力,基于金融行业IT系统建设的各种行业标准以及监管标准也相应提高。

IT系统架构的扩展性、灵活性以及容灾能力就成为衡量企业IT建设很重要的标准。

本手册以某银行同城双数据中心建设过程为背景,详细从系统架构集成、资源云化、存储整合以及数据容灾等多个关键方面阐述其规划思路以及建设过程,旨在为同业在此类项目规划和建设过程中提供一些启示和帮助。

1、双活数据中心的驱动力近年来,随着互联网金融的快速发展,金融企业数据中心建设面临着新的挑战。

那就是对RTO和RPO的极限追求。

从而也就诞生了近年来的热点话题——双活数据中心建设。

那么我们为什么要建设双活数据中心,它能给我们带来什么样的价值?什么样的数据中心架构叫做双活数据中心?如何认识适合自己业务模式的双活模式?建设阶段我们应该以什么样的原则来指导我们的建设工作?具体的建设思路以及具体的建设方案应该如何把握?基于这些问题,本文将进行深入研究并展开探讨。

从科技工作层面来讲,其实双活数据中心并不是一个行业标准或者规范。

行业的标准是对RTO和RPO约束,银监局和中国人民银行对商业银行业最严格的要求标准是5级容灾标准,RPO=15分钟,RTO=30分钟。

而根据国际标准share78,六级容灾标准是RPO=0,RTO=分钟级;七级容灾标准是RPO=0,RTO近似为0。

双活的概念也就由此而来,为了达到国际最高标准。

那么决策是否建设双活数据中心的依据也就在于此,首先确定自己企业合适的目标,是不是要必须追求7级标准?是不是所有业务都必须追求这个目标?如果不是,那么首先要对企业业务进行细分并详细规划每一个业务的容灾目标。

这将决定要不要建设双活数据中心以及建设什么样的双活数据中心。

银行同城灾备中心建设方案-网络

银行同城灾备中心建设方案-网络

(一)网络2、网络技术方案2.1建设背景随着社会的发展和科技的进步,金融行业越来越依赖于数据处理来进行业务运营,对IT系统的依赖性也随之增加。

然而,灾难就像灰尘一样伏击在企业周围,您的业务可能正在一个充满风险和威胁的世界里运行:无法预知的IT 硬件设备的损坏、断电、火灾、自然灾害、恐怖袭击等,造成数据丢失或业务的突然中断;系统人员误操作造成意外宕机或关键数据丢失,无法避免;手段频多的黑客攻击、病毒入侵、垃圾邮件、网络与系统的漏洞,造成网络瘫痪、系统崩溃。

如果不能对风险采取有效治理,一旦数据由于上述某种原因丢失,就有可能造成整个银行在运营上的重大不便和经济损失,银行的信誉也将受到影响。

如果核心数据丢失,严重时完全有可能造成整个银行的瘫痪。

由此可见,保证银行的业务连续运营及数据处理的高可靠性和高可用性,已经成为所有IT人员在建设IT基础架构中首先要考虑的问题。

与此同时,我们需要考虑建立和加强银行的业务恢复能力,缩短业务恢复的时间,以便在发生系统灾难后能够从容应对风险。

故此,银行对IT系统提出了以下要求:1)网络系统的高可用性,保证数据7X24 小时的连续访问;??2)将现有的网络技术集成,建设高效、可靠、可自恢复并且安全的骨干网络,为未来发展奠定良好的基础。

? 3)需要能够支撑对银行现有的数据以及各种应用系统进行集中化、自动化的基于策略的保护;??4)需要一套成熟度高,业内应用广泛的网络整体解决方案,一旦发生灾难(洪水、地震、火灾等),或者人为灾难(用户失误、磁盘失效等)导致数据丢失或者业务中断时,能够快速、及时地恢复数据,保证业务的连续运行。

为进一步推进某银行信息化建设,以信息化推动某银行业务工作的改革与发展,需要在抚顺本地建设某银行的同城灾备中心,建设新一代绿色高效能数据中心网络。

同时主中心需进行适当的扩容以配合此次同城灾备的实施。

此次建设的重点是数据中心,数据中心(英文拼写Data Center,简写DC)是数据大集中而形成的集成IT应用环境,它是各种IT应用服务的提供中心,是数据计算、网络、存储的中心。

银行灾备方案

银行灾备方案

银行灾备方案一、引言随着现代金融业务的不断发展和数字化的加速推进,银行系统的高可用性和数据安全性成为重中之重。

为了确保持续的服务和保护客户利益,银行需要建立完备的灾备方案。

本文档将详细介绍银行灾备方案的设计和实施。

二、灾备需求分析2.1 灾备目标1.数据可靠性:保证数据的完整性、一致性和可恢复性。

2.业务连续性:确保银行业务在灾难事件后能够持续运行,降低中断时间。

3.系统可用性:提供高可用的系统和网络基础设施,确保服务的稳定性。

4.安全性:保护客户敏感信息和关键业务数据的安全性。

2.2 灾备策略1.数据备份和恢复策略:定期备份和存储关键数据,确保数据可靠性。

同时,建立快速恢复机制,实现数据的快速恢复。

2.冗余策略:通过建立冗余系统和设备,提高系统可用性。

包括主备站点的建设、冗余网络设备、电力设备等。

3.灾难恢复策略:制定针对各类灾难事件的应急预案,包括火灾、地震、网络攻击等,确保业务的持续运行。

4.安全保障策略:建立完善的安全体系,包括网络安全、数据安全和设备安全等方面,保护客户信息和关键业务数据。

三、银行灾备方案设计3.1 灾备组织结构为有效实施银行灾备方案,需要建立灾备组织结构。

组织结构包括:1.灾备总负责人:负责统筹规划和决策灾备工作。

2.灾备团队:由各部门的专业人员组成,负责具体的灾备工作。

3.灾备委员会:定期召开会议,讨论重大决策和问题。

3.2 灾备设施建设1.主备站点建设:在不同地理位置建立主备站点,实现数据的实时同步和服务的快速切换。

2.电力和网络设备冗余:建立冗余的电力和网络设备,确保系统可用性。

3.数据备份和存储:建立定期备份和存储机制,确保数据的可靠性和可恢复性。

4.灾备测试环境:建立灾备测试环境,定期进行灾备演练,确保应急预案的可行性。

3.3 灾备计划制定和调整1.灾备计划制定:根据灾备目标和策略,制定详细的灾备计划,包括数据备份计划、灾难恢复计划和应急预案等。

2.灾备计划调整:定期评估灾备计划的有效性,并根据需求和技术发展情况进行相应的调整和优化。

农业银行防灾减灾工作预案

农业银行防灾减灾工作预案

一、总则1.1 编制目的为提高农业银行应对自然灾害、事故灾难等突发事件的能力,最大限度地减少灾害损失,保障员工生命财产安全,维护银行正常运营,特制定本预案。

1.2 编制依据《中华人民共和国突发事件应对法》、《中华人民共和国银行业监督管理法》、《银行业金融机构突发事件应急预案》等相关法律法规。

1.3 适用范围本预案适用于农业银行各级机构在应对自然灾害、事故灾难等突发事件时的应急管理工作。

二、组织机构及职责2.1 应急指挥部成立农业银行防灾减灾应急指挥部,负责组织、协调、指挥防灾减灾工作。

2.1.1 指挥长:由农业银行行长担任。

2.1.2 副指挥长:由农业银行分管副行长、各部门负责人担任。

2.1.3 成员:各部门、各分支机构负责人。

2.2 应急指挥部办公室设立农业银行防灾减灾应急指挥部办公室,负责日常防灾减灾工作的组织、协调、指导和监督。

2.2.1 主任:由农业银行安全保卫部负责人担任。

2.2.2 副主任:由农业银行各部门、各分支机构负责人担任。

2.2.3 成员:各部门、各分支机构相关人员。

2.3 应急小组根据不同类型的灾害,成立相应的应急小组,负责具体实施防灾减灾工作。

2.3.1 防灾减灾应急小组:负责组织、协调、指挥灾害发生后的应急救援工作。

2.3.2 通讯联络小组:负责灾害发生后的信息收集、报送和通讯联络工作。

2.3.3 安全保卫小组:负责保障灾区安全,维护秩序,防止盗窃、抢劫等犯罪行为。

2.3.4 后勤保障小组:负责灾区生活、医疗、物资供应等工作。

三、预防与预警3.1 预防措施3.1.1 建立健全防灾减灾组织体系,明确各级机构职责。

3.1.2 加强防灾减灾宣传教育,提高员工防灾减灾意识。

3.1.3 定期开展防灾减灾演练,提高员工应急处置能力。

3.1.4 加强安全设施建设,提高抗灾能力。

3.2 预警信息3.2.1 及时收集、分析国内外灾害信息,预测可能发生的灾害。

3.2.2 建立灾害预警机制,及时发布预警信息。

建行防灾害预案方案模板

建行防灾害预案方案模板

一、预案概述1.1 编制目的为提高中国建设银行应对自然灾害、事故灾难、公共卫生事件和社会安全事件等突发事件的能力,保障员工生命财产安全,确保业务连续性和金融稳定,特制定本预案。

1.2 适用范围本预案适用于中国建设银行各级机构在应对各类突发事件时的应急响应和处置工作。

1.3 工作原则(1)以人为本,生命至上;(2)预防为主,常备不懈;(3)统一领导,分级负责;(4)快速反应,协同应对;(5)信息公开,社会参与。

二、组织机构及职责2.1 预案领导机构成立中国建设银行应急领导小组,负责全行应急工作的组织、领导和指挥。

2.2 预案管理部门设立应急管理部门,负责预案的制定、修订、培训和演练等工作。

2.3 预案实施机构各级机构应设立应急小组,负责本机构的应急响应和处置工作。

三、预警与监测3.1 预警信息收集建立预警信息收集网络,及时获取各类突发事件预警信息。

3.2 预警信息发布根据预警信息,及时向各级机构发布预警信息,并指导开展防范工作。

3.3 监测系统建立健全监测系统,对可能引发灾害的各类因素进行实时监测。

四、应急响应4.1 响应级别根据突发事件的影响范围、严重程度和危害程度,将应急响应分为四个级别:一级响应、二级响应、三级响应和四级响应。

4.2 响应程序(1)启动预案:接到突发事件报告后,立即启动预案,启动应急响应。

(2)应急响应:各级机构按照预案要求,采取相应的应急措施。

(3)信息报告:及时向上级机构报告突发事件情况及应急响应措施。

(4)应急结束:突发事件得到有效控制后,宣布应急结束。

五、应急处置5.1 人员疏散与安置(1)根据突发事件情况,制定人员疏散和安置方案。

(2)确保员工和客户的生命安全。

5.2 资产保护(1)采取必要措施,保护银行资产安全。

(2)确保业务设施和信息系统安全。

5.3 业务保障(1)确保银行正常营业,维护金融稳定。

(2)采取应急措施,保障客户利益。

六、恢复重建6.1 恢复重建计划制定恢复重建计划,明确恢复重建的目标、任务和措施。

灾后重建 银行工作方案

灾后重建 银行工作方案

灾后重建银行工作方案
灾后重建银行工作方案主要包括以下几个方面:
1. 资金支持:银行可以向受灾地区提供紧急资金支持,包括救灾、修复基础设施、重建住房等方面的资金。

同时,银行可以为受灾群众提供低利率的贷款,帮助他们重建家园和恢复生产。

2. 信贷支持:银行可以为受灾地区的企业提供灵活的信贷支持,帮助他们渡过难关并恢复生产。

银行可以为受灾企业提供优惠贷款利率、延期还款等措施,帮助他们度过灾后重建的困难期。

3. 保险服务:银行可以加强对受灾地区的保险服务,包括提供保险产品、快速理赔等方面的支持。

银行可以与保险公司合作,推出适合受灾地区需求的保险产品,并为受灾群众提供保险投保、理赔等方面的指导和帮助。

4. 金融教育:银行可以通过开展金融教育活动,帮助受灾地区的居民提升金融素养和风险意识。

银行可以组织金融知识培训班、发放教育宣传材料等,帮助受灾地区居民了解金融产品、风险管理等方面的知识,提高他们的金融能力。

5. 社会责任:银行可以积极履行社会责任,通过捐款、捐物等方式向受灾地区提供帮助。

此外,银行还可以参与灾后重建的规划和实施过程中,提供专业的金融咨询和支持,为受灾地区提供更可持续的发展方案。

总之,灾后重建银行工作方案应以提供资金支持、信贷支持、
保险服务、金融教育和履行社会责任为核心内容,通过各种方式支持受灾地区的恢复和重建工作。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

银行应用级灾备建设方案目录1项目背景及建设需求 (3)2各系统数据备份概况 (4)3灾备端应用部署规划 (5)4灾备网络通信系统 (7)5各业务系统应用级部署工作计划 (8)6各业务系统应用部署工作分解 (9)6.1系统部署 (9)6.1.1AIX平台 (9)6.1.2虚拟机平台 (9)6.2FTP环境构建 (10)6.3系统验证 (11)6.3.1验证前准备 (11)6.3.2单系统验证 (15)6.3.3系统集成验证 (16)7项目主要风险点 (17)1项目背景及建设需求目前,我行灾备项目已完成核心业务域和城商业务域数据级同城备份,通过两台IBM中端磁盘阵列实现了两大业务域关键数据从生产中心到灾备中心的同城复制。

其中:✧DS5100承载ESB、加密平台、图形前端数据库三个系统数据复制,未实现数整报表系统的数据复制✧DS5020承载PCSP(综合前置)、ATMP、虚拟化平台数据复制,未实现财务系统(NC)数据复制按山东省银监局相关要求:2013年三季度,需要完成国际结算、信贷、图形前端、票据、手机银行、NC、ATMP、数整报表、加密平台、综合前置、ESB等十一个重要业务系统的应用级灾备建设。

2各系统数据备份概况十一个业务系统数据存储及异地备份概况统计如下表:从上表可知,ESB、加密平台、图形前端、ATMP、综合前置(PCSP)等五个系统数据通过磁盘阵列实时复制到灾备端,数整报表、国际结算、信贷、票据、手机银行、财务系统等六个系统数据则通过每日全备、定时FTP传送至灾备端。

3灾备端应用部署规划目前,灾备中心网络链路已就绪,各业务系统应用服务器硬件已完成上架、加电测试等相关工作。

各系统部署规划如下表:系统名称系统平台数据库应用灾备端服务器配置ESB AIX6100-07 DB2 9.1 P740一台加密平台AIX6100-07 P720一台SQLServer虚拟机图形前端Windows20082008ATMP AIX5300-12 Oracle10g P720一台综合前置AIX6100-07 P720一台数整报表AIX6100-07 DB2 9.1 P740一台国际结算Windows2003 虚拟机信贷系统Windows2003 虚拟机票据系统SLES10 虚拟机手机银行SLES11 虚拟机财务系统AIX5300-12 P720一台(NC)其中:✧虚拟机平台物理服务为四台IBM 3850 X5✧图形前端数据库服务器、应用服务器均部署在虚拟机平台✧国际结算、信贷、票据、手机银行四个系统也部署在虚拟机平台上✧加密机为独立硬件✧加密平台、ATMP、PCSP、NC四个系统分别部署在4台P720小机内✧ESB、数整报表两个系统分别部署在两台P740小机内4灾备网络通信系统网络通信系统详见《我行灾备中心建设方案》。

网络拓扑示意图如下:本次应用级备份建设仅涉及到系统验证层次,不启用灾备中心网络开展实际业务切换。

系统验证时的网络使用需求及操作步骤见本文“6.3系统验证”部分。

5各业务系统应用级部署工作计划✧第一阶段:1、完成全部服务器操作系统调研2、进行系统兼容性测试a)由于原生产系统版本较低,灾备中心均配置为Power7处理器,不能支持生产系统版本,需要进行版本兼容性测试。

3、完成全部服务器操作系统安装✧第二阶段:1、协调各应用系统厂商,逐步完成除ESB外其余10个系统的数据库和应用部署2、生产端ESB升级后,完成灾备端数据库和应用部署✧第三阶段:1、依次完成国际结算、信贷、票据、手机银行、NC、数整报表FTP传输及数据恢复测试2、逐系统完成ESB、加密平台、图形前端、ATMP、综合前置灾备系统验证测试3、完成灾备端应用系统封闭切换联合测试4、操作手册整理6各业务系统应用部署工作分解6.1系统部署6.1.1AIX平台ESB、加密平台、ATMP、综合前置(PCSP)、财务系统(NC)、数整报表六个系统均安装在AIX平台内。

其中:ATMP和NC两个系统使用AIX5300-12版本,其余系统使用AIX6100-07版本。

✧时区设置:BEIST-8✧最大进程数设置:4096✧Paging Space设置:≥4GB此外,ESB、数整报表还需要配置HA。

各系统数据库、应用部署由行方技术人员及开发厂商协助完成。

6.1.2虚拟机平台1、ESX Sever在灾备端x3850上安装Vmware ESX Server、VCenter等组件;2、虚拟机在Vmware环境下依次部署图形前端服务器(Windows2008,SQLServer 2008)、图形前端APP1(Windows2008)、图形前端APP2(Windows2008)国际结算(Windows2003)、信贷(Windows2003)、票据(SLES10)、手机银行(SLES11)。

为保证部署质量,虚拟机部署过程不使用Vmware的P2V功能;需要注意各虚拟机的虚拟网卡及网络地址配置。

各系统数据库、应用部署由行方技术人员及开发厂商协助完成。

6.2FTP环境构建本工作阶段中,数整报表、国际结算、信贷、票据、手机银行、财务系统等六个系统数据通过每日全备、定时FTP传送至灾备端。

其中:数整报表全备数据在每日批处理完成后触发TSM实现备份,其余系统由值班员定时备份。

为便于操作和管理,避免未来的系统验证工作影响备份数据FTP传送,建议在灾备端架设专用FTP服务器,统一实现备份数据的上传下载。

各系统不同时间的备份数据文件采用相同文件名,允许当日备份数据文件覆盖前日文件。

FTP服务器IP地址、客户端用户账号(分生产端上传用户账号和灾备端下载用户账号)、FTP服务器磁盘空间大小由行方统一分配管理,备份数据文件命名规则由行方确定。

考虑到数整报表备份数据量巨大,为避免资源征用,保证备份数据传输效率,建议FTP服务器使用具有Qos保证的专用IP通道。

使用过程中,建议分时、顺次执行各系统备份数据上传,数据上传顺序及时间窗口由行方确定。

6.3系统验证6.3.1验证前准备考虑到我行灾备端各系统使用与生产端相同的IP地址,在执行灾备端系统验证前,必须确保不出现IP地址冲突问题。

具体方法如下:1、单系统验证:(以ATMP为例)数据中心:(1)需要物理断开该系统与接入交换机的连接线路或手工将接入交换机连接ATMP端口关闭;(如图1-1)本地支行外地分行图1-1数据中心与灾备中心:(2)将数据中心接入交换机与灾备中心接入交换机二层通信建立(如图1-2),此阶段需检查线路连接情况避免环路产生;本地支行外地分行图1-2灾备中心:(3)将灾备中心ATMP系统与灾备中心接入交换机进行连接(如图1-3)。

本地支行外地分行图1-32、多系统验证:(已ESB、加密平台、图形前端、ATMP为例)数据中心:(1)需要物理断开该系统与接入交换机的连接线路或手工将接入交换机连接ATMP、ESB\加密平台、图形前端端口关闭;(如图2-1)本地支行外地分行图2-1(2)将数据中心接入交换机与灾备中心接入交换机二层通信建立(如图2-2),由于生产网段与联盟网段不属于同一段IP地址,故此时需将广域网链路进去区分,不同IP地址连接至不同广域网交换机。

此阶段需检查线路连接情况避免环路产生;本地支行外地分行图2-2灾备中心:(3)广域网交换机与生产接入交换机、联盟接入交换机进行互联,将ATMP系统接入生产交换机;ESB、加密平台、图形前端接入联盟接入交换机。

本地支行外地分行图2-36.3.2单系统验证1、基于备份/恢复的系统验证对于数整报表、国际结算、信贷、票据、手机银行、财务系统等六个系统,可按照FTP下载、数据恢复、启动数据库、启动应用的顺序执行。

以虚拟机方式部署的应用,验证前需要确保ESX物理服务器所在的接入交换机上联链路物理断开。

数据恢复、数据库启停、应用启停操作由行方或应用开发商支持人员负责。

2、基于磁盘阵列复制的系统数据验证根据我行城商业务域的业务依赖关系,ESB、密码平台、图形前端三个应用位于DS5100上的数据属同一个写一致性组,三个业务系统的验证工作需要一起进行。

ATMP、综合前置(PCSP)两个系统数据位于DS5020上,卷组相互独立,系统验证可分别执行。

由于DS5100和DS5020上均采购了FlashCopy软件授权,本次验证灾备端各应用服务器将通过挂载快照卷进行,避免复制关系断开、解除等操作带来验证后生产端数据重新执行初始复制的情况。

数据恢复、数据库启停、应用启停操作由行方或应用开发商支持人员负责。

3、单系统切换网络环境验证为保证未来行方的单系统切换需求,需要行方协调一条准备生产中心至灾备中心的独立IP专线备用或复用现两条WDM线路。

如申请专线,该专线平时在生产端和灾备端均不做任何连接。

切换验证时,选定的待验证业务系统,将该系统灾备端服务器下线,同时将该系统接入交换机上联链路替换为专线,生产端接入核心交换机相应端口。

调整两端网络参数,网络可达即验证成功。

6.3.3系统集成验证为验证各应用间数据交互效果,根据行方要求实施系统集成验证。

集成验证期间,需要断开灾备中心对外的全部网络连接。

各业务系统按本文“6.3.3系统集成验证”要点操作完成系统拉起,由行方科技信息部及业务部门人员验证数据及系统的可用性。

7项目主要风险点由于应用及系统验证均使用可丢弃的数据执行,应用部署及验证过程基本不会对生产系统产生影响。

项目主要执行风险集中在以下两方面:1、六个系统备份数据FTP传输安排本阶段,FTP传输是一项日常工作,一要考虑在规定的时间窗口内完成全部系统备份数据的FTP传输,二要避免验证期间数据下载过程与数据上传发生冲突。

2、灾备端单系统验证及联合测试期间的网络管理网络管理要求详见本文“6.3验证前准备”。

考虑到整个验证过程周期较长,每次验证结束后的现场恢复工作需要安排专人查验,避免因网络冲突导致生产端事故。

相关文档
最新文档