下载文档原格式
住房公积金管理中心容灾中心建设项目设计方案建设单位：住房公积金管理中心编制单位：编制日期：目录1 项目简介 (1)1.1 项目名称 (1)1.2 项目建设单位和负责人、项目责任人 (1)1.3 项目建议书编制依据 (1)1.4 项目概况 (2)1.5 主要结论与建议 (2)2 项目建设单位概况 (3)2.1 项目建设单位与职能 (3)2.2 项目实施机构与职责 (3)3 项目建设的必要性 (4)3.1 项目建设的背景和依据 (4)3.2 现有信息系统装备和信息化应用状况 (7)3.3 现有信息系统存在的主要问题和差距 (8)3.4 项目建设的意义和必要性 (9)4 需求分析 (12)4.1 与政务职能相关的社会问题和政务目标分析 (12)4.2 信息量分析与预测 (13)4.3 存储系统分析 (12)5 项目建设方案 (15)5.1 建设目标与主要建设内容 (15)5.2 设计原则 (18)5.3 远程容灾系统建设 (18)5.4 机房的改造与建设 (30)5.5 方案价值 ......................................................... 错误!未定义书签。
5.6 容灾方案效果 ................................................. 错误!未定义书签。
6 项目组织机构和人员 (38)6.1 项目领导、实施和运维机构及组织管理 (38)6.2 人员配置 (38)6.3 人员培训需求和计划 (38)7 项目实施进度 (40)8 投资估算和资金筹措 (41)9 效益与风险分析 (43)9.1 效益分析 (43)9.2 项目风险与风险对策 (46)9.3 结论 (47)10 附表 (48)10.1 一期项目投资估算表 (48)10.2 工程费投资情况 (49)1 项目简介1.1 项目名称项目名称：住房公积金管理中心容灾系统项目项目周期：年月至年月投资估算：万元1.2 项目建设单位和负责人、项目责任人项目建设单位：住房公积金管理中心单位负责人：项目责任人：1.3 项目建议书编制依据本项目建议书编制依据以下国家、省及相关的政策、技术、经济资料。
XX住房公积金服务高效办成一件事实施方案为深化“放管服”改革，助推住房公积金行业数字化转型发展，实现更多住房公积金业务“高效办成一件事”的政务服务创新,全面促进XX住房公积金服务提质增效,根据《国务院关于加快推进政务服务标准化规范化便利化的指导意见》（国发（2022）5号）和《住房和城乡建设部关于加快住房公积金数字化发展的指导意见》（建金（2022）82号）等文件精神，持续提升住房公积金服务标准化、规范化、便利化水平，打造住房公积金服务升级版，结合我区实际，制定本实施方案。
一、总体要求从服务企业和群众“高效办成一件事”出发，全面梳理住房公积金缴存、提取、贷款三大业务共X项服务事项,对其中关联性强、办事需求量大、跨部门协同的X项服务事项，优化业务流程、打通业务系统、强化数据共享，按年度分批次实现“全链通办”，最大程度利企便民，服务房地产市场平稳健康发展工作大局。
二、工作目标20XX年，基本建成XX住房公积金服务一体化信息平台。
贯彻落实国务院“一件事一次办”和“高效办成一件事”要求，统一X项住房公积金服务事项的办事流程和要件材料，建立“全链通办”业务办理模式，开展全区住房公积金个人住房贷款业务“全链通办”试点工作，完成首批IX项住房公积金服务事项“全链通办”。
20XX年，全面建成XX住房公积金服务一体化信息平台。
推动住房公积金综合业务与相关部门业务深度融合，构建业务数据多方共建共享的业务协同机制。
完成第二批7项住房公积金服务事项“全链通办”，全面推行住房公积金服务事项按“全链通办”模式实现智慧审批及“不见面”办理。
20XX年,全省住房公积金数字化发展新模式基本确立,数据资源共享体系和平台支撑体系更加健全，打造全系统业务协同、全方位数据赋能、全业务线上服务、全过程智能监管的住房公积金数字化服务新体系，推动住房公积金事业高质量发展。
三、重点任务（一）建立XX住房公积金服务“高效办成一件事”任务清单。
根据现有全国住房公积金服务事项和我区住房公积金业务实际，建立“1+N”（即贷款业务“不见面”审批+多项住房公积金业务）的“高效办成一件事”任务清单（详见附件），按年度分批次实施，为企业和群众提供集成化办理服务，提高办事效率，降低办事成本。
住房公积金管理中心容灾系统项目建议书目录1 项目简介 (1)1.1 项目名称 (1)1.2 项目建设单位和负责人、项目责任人 (1)1.3 项目建议书编制依据 (1)1.4 项目概况 (2)1.5 主要结论与建议 (2)2 项目建设单位概况 (4)2.1 项目建设单位与职能 (4)2.2 项目实施机构与职责 (4)3 项目建设的必要性 (5)3.1 项目建设的背景和依据 (5)3.2 现有信息系统装备和信息化应用状况 (5)3.3 现有信息系统存在的主要问题和差距 (7)3.4 项目建设的意义和必要性 (7)4 需求分析 (9)4.1 与政务职能相关的社会问题和政务目标分析 (9)4.2 信息量分析与预测 (9)4.3 存储系统分析 (11)5 项目建设方案 (13)5.1 建设目标与主要建设内容 (13)5.2 设计原则 (13)5.3 远程容灾系统建设 (14)5.4 机房的改造与建设 (16)5.5 方案价值 (17)5.6 容灾方案效果 (18)6 项目组织机构和人员 (20)6.1 项目领导、实施和运维机构及组织管理 (20)6.2 人员配置 (20)6.3 人员培训需求和计划 (20)7 项目实施进度 (22)8 投资估算和资金筹措 (23)9 效益与风险分析 (25)9.1 效益分析 (25)9.2 项目风险与风险对策 (25)9.3 结论 (26)10 附表 (27)10.1 一期项目投资估算表 (27)10.2 工程费投资情况 (29)1 项目简介1.1 项目名称项目名称：住房公积金管理中心容灾系统项目项目周期：年月至年月投资估算：万元1.2 项目建设单位和负责人、项目责任人项目建设单位：住房公积金管理中心单位负责人：项目责任人：1.3 项目建议书编制依据本项目建议书编制依据以下国家、省及相关的政策、技术、经济资料。
[1]《关于抗震救灾中做好住房公积金工作》（建房资监通[2008]271 号）[2]《国家突发公共事件总体应急预案》[3]《市长在二届二次管委会上关于加强住房公积金信息化建设的讲话》[4]《信息安全技术信息系统灾难恢复规范》GB/T 20988-2007[5]《重要信息系统数据灾难恢复指南》[6]《国际Share78标准》[7] GB/T8567-2006 计算机软件文档编制规范[8] 中华人民共和国国家标准《计算机信息系统安全保护等级划分准则》（GB 17859-1999）1.4 项目概况住房公积金管理中心（以下简称“中心”）是根据国务院《住房公积金管理条例》规定，经人民政府同意，于2003年7月11日正式挂牌成立的直属市人民政府，不以营利为目的的正县级事业单位。
住房公积金管理中心管理信息系统建设方案住房公积金管理中心新一代住房公积金业务管理信息系统项目项目建议书建设单位：住房公积金管理中心编制单位：编制日期：联系人：目录1 项目简介 (1)1.1 项目名称 (1)1.2 项目建设单位和负责人、项目责任人 (1)1.3 项目建议书编制依据 (1)1.4 项目概况 (2)1.5 主要结论与建议 (2)2 项目建设单位概况 (5)2.1 项目建设单位与职能 (5)2.2 项目实施机构与职责 (5)3 项目建设的必要性 (6)3.1 项目建设的背景和依据 (6)3.2 现有信息系统装备和信息化应用状况 (7)3.3 现有信息系统存在的主要问题和差距 (8)3.4 项目建设的意义和必要性 (9)4 需求分析 (11)4.1 与政务职能相关的社会问题和政务目标分析 (11) 4.2 业务功能、业务流程分析 (14)4.3 系统功能和性能需求分析 (15)5 项目建设方案 (19)5.1 建设原则与建设目标 (19)5.2 总体架构 (21)5.3 模块功能概述 (22)5.4 系统功能模块初步划分 (25)5.5 银行的数据接口 (30)5.6 数据要求 (31)5.7 数据移植需求 (31)5.8 数据文档安全解决方案 (31)6 项目组织机构和人员 (37)6.1 项目领导、实施和运维机构及组织管理 (37) 6.2 人员配置 (37)6.3 人员培训需求和计划 (37)7 项目实施进度 (39)8 投资估算和资金筹措 (40)9 效益与风险分析 (41)9.1 效益分析 (41)9.2 项目风险与风险对策 (41)9.3 结论 (42)10 附表 (43)10.1 项目投资估算表 (43)10.2 工程费投资情况 (45)1 项目简介1.1 项目名称项目名称：住房公积金新一代管理信息系统项目周期：年月至年月投资估算：万元1.2 项目建设单位和负责人、项目责任人项目建设单位：住房公积金管理中心单位负责人：项目责任人：1.3 项目建议书编制依据本项目建议书编制依据以下国家、省及相关的政策、技术、经济资料。
![福州住房公积金管理中心关于接入省住建厅公积金灾备系统的应急处置预案-榕公积综[2014]50号](https://img.taocdn.com/s1/m/6b59f50a53d380eb6294dd88d0d233d4b14e3f1d.png)
福州住房公积金管理中心关于接入省住建厅公积金灾备系统的应急处置预案正文：---------------------------------------------------------------------------------------------------------------------------------------------------- 福州住房公积金管理中心关于接入省住建厅公积金灾备系统的应急处置预案（榕公积综〔2014〕50号）为规范省住建厅公积金灾备系统运行过程的突发故障应急情况管理，确保灾备系统与福州住房公积金业务系统运行的连续性、稳定性，应付系统突发事件，快捷、高效地处理发生的问题，最大限度降低故障影响，保障业务正常开展。
现结合中心实际，制定本预案。
一、适用范围本预案适用于省住建厅公积金灾备系统及其监控的福州住房公积金业务系统中各类相关突发故障的处置。
突发故障是指，福州住房公积金管理中心业务系统及省住建厅公积金灾备系统在使用过程中突然发生，无法正常进行灾备工作或影响中心正常的业务办理，需要立即采取应对措施加以妥善处理的紧急事件。
突发事件分为以下几类（一）I 级故障：灾备系统运行中断，但不影响中心业务系统的业务运行。
（二）II 级故障：灾备系统运行中断，导致中心业务系统的运行缓慢但未发生运行中断。
（三）Ⅲ级故障：灾备系统运行中断，导致中心业务系统运行中断故障。
二、明确职责在灾备系统运行期间技术人员应密切跟踪系统运行状况。
保障系统正常运行，确保业务的正常开展，一旦系统出现故障，技术人员应立即上报相关领导，启动业务系统故障处理程序，做到问题定位准确，处理及时。
三、故障处理程序（一）I级故障处理措施1、由信息处技术人员确定问题故障级别。
2、上报处室领导，并联系城东建行科技部技术人员暂时关闭灾备系统的运行程序。
3、中心技术人员到达城东建行现场并联系省建设厅信息中心协助我中心定位及解决问题。
住房公积金风险防控整改方案范本一、背景分析住房公积金是一项重要的社会保障制度，旨在提供住房补贴和保障住房的合理消费。
然而，近年来，一些住房公积金系统存在一些风险问题，如资金管理不规范、信息安全风险、不合理的贷款风险等，亟需采取相应的防控措施。
二、风险问题分析1. 资金管理风险：由于住房公积金涉及大量资金的管理与运作，存在资金流出不可控、滥用资金等问题，给资金安全带来潜在风险。
2. 信息安全风险：住房公积金系统中存储着大量个人身份信息和财务数据，如果未能采取有效的信息安全措施，容易引发信息泄露和数据被盗风险。
3. 不合理的贷款风险：住房公积金贷款存在一定的信用风险，尤其是在贷款审核和发放过程中，如果没有严格的审核制度和风险评估机制，可能会导致贷款违约和不良贷款增加。
三、整改方案为了有效防控住房公积金的风险，保护参与者的合法权益和公积金基金的安全，提出以下整改方案：1. 加强资金管理1.1 建立健全资金监管制度：制定资金监管规范和流程，明确资金流向和使用要求，加强对资金使用情况的监督和管理。
1.2 强化内部控制：建立内部控制制度，明确资金管理的责任和权限，加强对资金操作的审核和审计，确保资金使用的合理性和安全性。
2. 提升信息安全保障2.1 完善信息安全措施：加强对住房公积金系统的信息安全管理，包括数据加密、访问控制、系统漏洞修复等，防止潜在的信息泄露和数据被盗风险。
2.2 建立信息安全管理体系：建立信息安全管理制度和流程，包括信息安全培训、风险评估和事件应急预案等，提高对信息安全风险的预防和应对能力。
3. 加强贷款风险防控3.1 建立贷款审核机制：建立贷款审核流程和准入标准，严格审核借款人的还款能力和信用状况，防止贷款违约和不良贷款增加。
3.2 强化风险评估机制：建立贷款风险评估模型，综合考虑借款人的还款能力、贷款用途等因素，科学评估贷款风险，保持贷款风险在可控范围内。
4. 健全监管机制4.1 加强内部审计：定期开展内部审计，发现并纠正存在的问题和风险，及时采取有效措施保障住房公积金的安全和稳定运行。
容灾项目方案设计目录第 1 章容灾技术规 (6)1.1 容灾的总体规划 (6)1.1.1技术指标RPO、RTO (6)1.1.2国际标准SHARE 78 (7)1.1.2.1Tier 0 (8)1.1.2.2Tier 1 (9)1.1.2.3Tier 2 (9)1.1.2.4Tier 3 (10)1.1.2.5Tier 4 (10)1.1.2.6Tier 5 (10)1.1.2.7Tier 6 (11)1.1.3界定灾备系统的适用围 (11)1.1.4界定灾备建设的目标 (12)1.1.5界定灾备系统的总体架构 (12)第 2 章主流容灾技术说明 (14)2.1 数据备份 (14)2.2 实时数据保护 (14)2.2.1数据镜像（Mirroring） (15)2.2.2数据复制（Replication） (15)2.2.2.1软件复制（卷复制） (15)2.2.2.2硬件复制 (16)2.2.2.3数据库复制 (19)2.2.2.4IBM SVC (20)2.3 应用系统恢复 (20)2.4 网络系统恢复 (20)2.5 容灾切换过程 (21)2.6 消防演习 (21)第 3 章主流容灾技术分析与对比 (22)3.1 数据备份 (22)3.2 实时数据保护 (23)3.2.1数据镜像（Mirroring） (23)3.2.1.1硬件镜像 (23)3.2.1.2软件镜像 (24)3.2.1.3镜像技术在容灾中的利用 (24)3.2.2数据复制（Replication） (24)3.2.2.1软件复制（卷复制） (25)3.2.2.2硬件复制 (27)3.2.2.3数据库复制 (28)3.2.2.4数据库双活 (29)3.2.3瞬间快照(Instant Snapshot) (30)3.3 应用系统恢复 (31)3.4 网络系统恢复 (32)3.5 容灾切换过程 (33)3.6 消防演习 (33)第 4 章某容灾方案主要技术介绍 (33)4.1 某N ET B ACKUP数据备份技术 (34)4.1.1无限可伸缩性 (34)4.1.2平台独立性 (34)4.1.3基于策略的集中式管理 (34)4.1.4无与伦比的性能 (34)4.1.5透明的不间断备份 (34)4.1.6支持最新存储硬件 (34)4.1.7可伸缩三/四层体系架构 (35)4.1.7.1NetBackup Master Server (36)4.1.7.2NetBackup Media Server (36)4.1.7.3NetBackup Client (36)4.1.7.4全球管理与实时报告：NOM (36)4.1.7.5先进报表：NetBackup Advanced Reporter™ (37)4.1.7.6数据库在线备份：Database Agent (38)4.1.7.7数据库归档：NetBackup Database Archiver (38)4.1.7.8块级增量备份：Block-Level Incremental Backup (39)4.1.7.9系统灾难恢复：Bare Metal Restore (39)4.1.7.10高速闪备份：NetBackup FlashBackup™ (41)4.1.7.11打开文件备份：Open Transaction Manager (42)4.1.7.12磁带库动态共享：Shared Storage Option™ (42)4.1.7.13无主机备份：NetBackup Server－Free Agent (43)4.1.7.14磁带容灾和管理：NetBackup Vault (43)4.1.7.15网络存储备份：NetBackup™ for NDMP (44)4.1.7.16备份数据加密：Client Encryption Option (45)4.1.7.17磁带库驱动：Tape Library Support (45)4.1.7.18其它功能 (45)4.2 某S TORAGE F OUNDATION (46)4.2.1某 Volume Manager™ (47)4.2.1.1更高的系统与应用性能 (47)4.2.1.2数据完整性提高，停机时间缩短 (47)4.2.1.3硬件与软件投资保护 (47)4.2.2某 File System™ (48)4.2.2.1用户与管理员工作效率提高 (48)4.2.2.2可靠的系统数据带来可靠的业务解决方案 (48)4.2.2.3简单而强大的系统管理功能 (48)4.2.3某 Storage Foundation解决方案说明 (48)4.2.3.1性能、可用性与安全性 (49)4.2.3.2可扩展性 (50)4.2.3.3集中式管理 (51)4.2.3.4异类环境支持 (52)4.2.3.5优异的集成性能 (52)4.2.4逻辑卷快照 (53)4.2.5snapshot快速重镜像(FastResync) (53)4.2.6动态拆分和重组（Dynamic split and Join） (54)4.2.7逻辑卷快照技术的特点 (54)4.2.8Snapshot 如何工作 (54)4.2.9瞬间快照(Instant Snapshot) (56)4.3 领先的企业级高可用性应用软件解决方案 (56)4.3.1某 Cluster Server特征 (57)4.3.2领先的异构平台HA解决方案 (57)4.3.3可伸缩性 (58)4.3.4可定制 (58)4.3.5补充保护 (58)4.3.6灾难恢复解决方案的重要组成成分 (58)4.3.7某 Cluster Server特性优势 (59)4.3.7.1全面的高可用性特性 (59)4.3.7.2最广泛的应用支持 (59)4.3.7.3异构平台和存储器支持 (59)4.3.7.4行业最具伸缩性的解决方案 (60)4.3.7.5多种存储支持 (60)4.3.7.6用于集群管理，基于JAVA的直觉图形用户界面（GUI） (60)4.3.7.7通用原子广播机（GAB） (60)4.3.7.8自动集群传播 (61)4.4 集群的集群 (61)4.4.1Global Cluster Option的特点 (61)4.4.2Global Cluster Option运作过程 (62)第 5 章系统详细设计方案 (64)5.1 第一步，深化数据备份系统 (64)5.2 第二步，存储、应用整合 (65)5.2.1存储整合 (65)5.2.2应用整合 (65)5.3 第三步，实现远程实时数据卷保护 (66)5.4 第四步，建立远程切换消防演习机制 (66)5.5 第五步，建立远程切换机制 (67)5.6 O RACLE 数据库切换详解 (67)第 6 章数据容灾的性能分析 (69)6.1 同步数据容灾的性能分析 (69)6.1.1带宽 (69)6.1.2距离 (69)6.1.3中间链路设备和协议转换的时延 (70)6.2 异步数据容灾的性能分析 (72)6.3 有关半同步 (77)6.4 容灾技术对照 (78)第 7 章系统预算 (79)第 8 章主要技术的应用实例 (80)8.1 中国联通 (80)8.2 ICON C LINICAL (80)8.3 B LUE S TAR (81)第 9 章应急预案的编制 (82)9.1 某技术力量 (82)9.2 某项目组成员 (83)第 10 章定期灾难性恢复测试计划及检验 (84)第 11 章售后服务方式、方法 (84)11.1 某中国技术支持服务中心 (84)11.2 技术支持服务介绍 (84)11.3 提供支持的流程： (85)11.4 某公司向用户提供如下支持服务： (85)第 1 章容灾技术规作为风险防系统，灾备系统建设本身在总体规划、方案选择和投产实施后的管理运行，以及真正面对灾难时的切换操作等方面也存在着潜在的风险。
千里马招标网大连市住房公积金管理中心存储扩容及杀病毒软件采购项目招标文件（项目编号：TLCG-）招标人：大连市住房公积金管理中心招标代理人：大连通利项目管理有限公司日期：二〇一八年七月大连市住房公积金管理中心存储扩容及杀病毒软件采购项目招标文件项目负责人：吴晓红编制人：吴晓红审核人：李俊儒目录投标邀请函…………………………………………………………………第一章投标人须知及前附表……………………………………………第二章合同条款及合同格式……………………………………………第三章项目需求及技术要求……………………………………………第四章投标文件格式……………………………………………………附件开标一览表…………………………………………………………附件资格性审查表、符合性审查表……………………………………大连市住房公积金管理中心存储扩容及杀病毒软件采购项目投标邀请函大连通利项目管理有限公司受大连市住房公积金管理中心的委托，对大连市住房公积金管理中心存储扩容及杀病毒软件采购项目进行国内公开招标，欢迎符合资格条件的投标人报名参加投标。
一、项目编号：TLCG-二、招标内容：大连市住房公积金管理中心存储扩容及杀病毒软件采购（详细内容见招标文件）。
注：.招标文件中要求投标人须提供非进口产品，否则视为无效投标文件。
进口产品是指通过中国海关报关验放进入中国境内且产自关境外的产品。
.投标人不能只对本项目个别品目进行投标，否则将被视为非响应性投标而被拒绝。
.采购预算：万元（投标报价超出采购预算的，按无效投标处理）。
三、投标人的资格条件：（一）在中国境内注册的具有本项目完成能力的独立企业法人。
（二）本项目不接受联合体投标。
（三）经检察机关查询三年内有行贿犯罪记录的不得参加投标。
（四）截至年月日，被列入“信用中国”网站（）、“信用辽宁”网站（）失信黑名单、被“信用大连”（）大连市重大税收违法案件信息公示平台予以公示、“中国政府采购网”网站（）政府采购严重违法失信行为信息记录，被列入失信被执行人名录、重大税收违法案件当事人名单、政府采购严重违法失信行为记录名单的不得参加本采购项目。
异地容灾解决方案建议书XXXXXXXXX住房公积金管理中心容灾项目方案设计广州世安信息技术有限公司2011-07目录第 1 章现状与需求 (3)第 2 章容灾方案 (5)2.1容灾技术指标RPO、RTO (5)2.2容灾方案建设内容 (6)2.3方案拓朴 (7)2.4方案说明 (8)2.5容灾原理分析 (10)2.6方案优势分析 (14)第 3 章系统预算 (15)3.1所需要链路 (15)3.2所需硬件 (15)3.3所需的软件列表 (16)3.4软件LICENSE清单与报价 (16)第 4 章附SYMANTEC容灾方案主要技术介绍 (17)4.1S YMANTEC N ET B ACKUP数据备份技术 (17)4.2S YMANTEC S TORAGE F OUNDATION (30)4.3领先的企业级高可用性应用软件解决方案 (40)4.4集群的集群 (44)第 1 章现状与需求XXXXXXXXX住房公积金管理中心负责佛山全市住房公积金的建立、管理和运作，其保存的数据是非常重要的。
目前,XXXXXXXXX住房公积金管理中心本地数据中心使用了两台IBM小型机P550，并通过光纤交换机连接到大恒的磁盘阵列上，其核心业务主要为oracle 数据库,其数据量约为200G,平均每天的数据增量为150M/天左右，以后可能会增加至800M/天，具体拓朴如下图所示：目前用户针对本地数据的保护主要通过专业的磁盘阵列、存储网络等手段，保证了本地应用的正常运行；但是，这些手段无法完全承担应用系统发生灾难时业务系统的安全运行，如缺少必要的备份系统，无法保证灾难出现后数据的恢复；缺少必要的高可用系统无法保证应用24小时不停机。
同时，目前所有数据都保存的本地磁盘阵列一个位置上，在本地数据中心正常的情况下可以保证系统的正常运行，但当本地数据中心遭受灾难时，所有的应用和数据都会遭到损坏，也就无法继续提供服务了；一旦出现这种情况，所有数据将丢失，系统重建的时间也会很长，对于用户这种的政府部门的应用服务，这无疑会对产生巨大影响，严重的会造成对外信誉问题，而解决所有这些问题的最好方法则是建立异地容灾中心。
因此XXXXXXXXX住房公积金管理中心需要建立一套完善的数据容灾方案来保证所有写入数据库的数据零丢失。
第 2 章容灾方案2.1 容灾技术指标RPO、RTO衡量容灾技术的两个技术指标RPO、RTORPO(Recovery Point Objective): 以数据为出发点，主要指的是业务系统所能容忍的数据丢失量。
及在发生灾难，容灾系统接替原生产系统运行时，容灾系统与原生产中心不一至的数据量。
RPO是反映恢复数据完整性的指标，在同步数据复制方式下，RPO等于数据传输时延的时间；在异步数据复制方式下，RPO基本为异步传输数据排队的时间。
在实际应用中，考虑到数据传输因素，业务数据库与容灾备份数据库的一致性（SCN）是不相同的，RPO表示业务数据与容灾备份数据的SCN的时间差。
发生灾难后，启动容灾系统完成数据恢复，RPO就是新恢复业务系统的数据损失量。
RTO(Recovery Time Objective):以应用为出发点，即应用的恢复时间目标，主要指的是所能容忍的应用停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。
是反映业务恢复及时性的指标，表示业务从中断到恢复正常所需的时间。
RTO值越小，代表容灾系统的数据恢复能力越强。
各种容灾解决方案的RTO有较大差别，基于光通道技术的同步数据复制，配合异地备用的业务系统和跨业务中心与备份中心的高可用管理，这种容灾解决方案具有最小的RTO。
容灾系统为获得最小的RTO，需要投入大量资金。
不同容灾方案的RTO和RPO是不相同的。
企业需要根据其计算机处理系统中数据的重要性，以及需要恢复的速度和程度，来进行灾备系统建设的整体考虑和不同灾难对业务冲击的分析，并最终确定灾备系统建设的总体规划。
2.2 容灾方案建设内容作为一个重要的数据中心,一个理想的容灾方案建设应该包括以下三个步骤:➢第一步：数据备份(实现历史数据的不丢失):数据备份是最基本的容灾建议内容,其目的是保证历史数据的不丢失,不管是物理错误还是逻辑错误,是正常找出数据的最终手段. 通过对生产数据定时备份至磁带或磁盘，当系统发生故障和人为的错误时，可以通过恢复备份数据来保证生产.➢第二步：本地oracle应用的高可用需求(实现本地RPO=0)：对于用户来说，本地oracle应用，要求24小时不间断运行，不允许数据有任何丢失，即要求做到RPO=0因此建立用户在本地建立并发集群oracle RAC，其具体效果包括：正常运用时两台小机同时对外提供服务，但任意一台小机有故障时，所有的应用全部转到正常运行的小机上。
通过对关键核心数据oracle数据库服务器实现本地应用的高可用性，确保本地核心应用系统在双机环境下具有抗御任何单点故障地能力，一旦系统发生局部地意外(如操作系统故障、掉电、网络故障等)，高可用系统可以在最短地时间迅速确保系统地应用继续运行；➢第三步：异地数据实时同步需求(实现异地RPO=0)：前两步的解决方案都是针对本地数据中心的，在本地数据中心范围内可以保证系统的正常运行，但当数据中心遭受灾难时，所有的应用和数据都会遭到损坏，也就无法继续提供服务了，而且在这种情况下，系统重建的时间会很长，对于用户这样的政府部门的应用服务，这无疑会对产生巨大影响，严重的会造成对外信誉问题，而解决所有这些问题的最好方法则是建立异地容灾中心。
2.3 方案拓朴2.4 方案说明2.4.1 方案概述如上图方案拓朴所示，按以上步骤流程，本方案使用Symantec的两个软件来实现，包括：1、Symantec Netbackup 实现数据备份（实现步骤一）2、Symantec Storage Foundation 实现本地卷与文件系统管理、多路径、数据库应用高可用（可选）、异地实现同步。
（实现步骤二、三）2.4.2 具体说明2.4.2.1 对于NBU备份系统建议增加一台PC服务器，安装NBU 主服务器模块，同时在AIX小机上安装企业客户端模块与oracel数据模块，设定备份策略，按策略调度实现数据的定时备份，对于备份系统备份策略的规划，建议按照以下流程进行，详细的备份策略规划请参见附表：➢将数据备份任务按类型划分，为每个备份任务指定专用的介质集；➢根据各业务系统对备份的需求，以及系统的忙闲程度，为每个备份任务划定可以进行数据备份的时段。
➢合理的选择备份方式，备份的最终目的是为了进行数据恢复，在选择备份方式时，要在业务系统性能需求许可的情况下，最大程度的降低数据恢复时的复杂程度。
➢在确定以上内容后，对备份任务的调度策略进行统一规划，首先保证关键业务的数据备份；尽量使备份数量在一周内的每天平均分布，可以采用大小数据量相搭配，或关键业务与非关键业务相搭配等方式进行；➢根据业务需要确认备份介质保存周期。
如无特殊需求，则保存周期的设置应以保证每一次全备份完成以前，都有可用介质供数据恢复使用为准。
➢每个全备份映像，根据不同系统数据的安全标准，应保留两个或两个以上的全备份周期，保证两个或两个以上全备份周期以内的全备份数据的可恢复性；附录策略表：业务系统建议备份方式保存周期Oracle数据库全备份/2天1月Oracle归档日志全备份/6次/天1月2.4.2.2 对于SF的实现在两台AIX小机上安装SF后，使用SF的多路径软件重新识别生产中心与灾备中心的存储，并建立VxVM卷组，并建立本地生产存储与灾备存储的mirror关系。
初次同步时可能需要的时间量比较长，因此建议选择在空闲时间进行，当第一次同步完成后，以后当小机往生产中心存储写放任何一个数据时。
同时也把此数据写入到灾备中心的存储上，同时实现生产中心与灾备中心数据的实时同步，当生产中心的存储出现故障时，自动切换使用灾备中心的存储。
2.4.3 注意事项1、考虑到用户的实际需要，要实现数据零丢失，因此生产中心与容灾中心的数据复制方式必须为同步方式，因此本次选择SF VxVM mirror方式来实现同步2、 NBU备份的数据目标位置强烈建议与生产磁盘阵列分开，避免出现磁盘阵列出现故障时，其备份的数据也不可用的情况3、为了达到数据的远程复制时的实效性，达到RPO=0即数据零丢失，建议用户生产中心与灾备中心之间使用裸光纤，其距离不超过30KM，理想状况为10KM，此时选择的存储为FC存储4、如果需要灾备中心与生产中心更远的距离情况下，如超过100KM时，需要使用IP专线网络要求其带宽为100M/s，此种情况下，要求异地容灾中心的存储支持iscsi,即：本地使用FC-SAN,异地使用IP-SAN5、对于SF 与SF RAC两者的功能相差仅在是否支持本地高可用集群，考虑到Oracle数据库的维护方便与项目的集成性，建议oracle的集群由oracle专业服务商来完成。
数据容灾仅选用SF的卷管理、文件管理、多路径、VxVM mirror等功能，不配置RAC集群功能。
2.5 容灾原理分析如下图所示，通过SF软件，可以实现：•0停机时间，无系统停顿及数据损失。
•镜像快速恢复，对业务影响极小。
•支持在异构阵列间实现容灾。
免费提供阵列到主机的多光纤链路（DMP）控制管理软件。
要实现应用0停机、数据的0丢失，其原理如下图所示：平时所有数据同时写入到两个存储上，当生产中心存储出现问题时，主机的所有数据切换到容灾中心存储。
••如下图所示，正常情况下，其数据写入流程如下：• 1. 客户端向服务器发出写请求。
• 2. 数据由服务器同时写入生产中心及容灾中心阵列。
• 3. 生产中心阵列及容灾中心阵列先后向服务器确认数据写完。
• 4. 服务器向客户端确认数据写完。
如下图所示，当本地存储出现故障时，其数据写入流程：• 1. 客户端向服务器发出写请求。
• 2. 数据无法写入生产中心阵列，等待操作系统timeout, 确认生产中心阵列出错后，直接写入容灾中心阵列。
• 3. 容灾中心阵列向服务器确认数据写完。
• 4. 服务器向客户端确认数据写完。
• 5. 在操作系统检测到磁盘修复之前，以后的所有I/O将只从容灾中心阵列进行。
2.6 方案优势分析⏹支持异构环境高可用性⏹非硬件绑定,购买的存储可以是任意品牌⏹自带多路径软件,专门文件与卷管理，管理方便效率高，消除存储单点故障⏹方便扩容与迁移:Symantec提供一套完整的数据容灾到应用容灾与应用高可用的完整解决方案，可根据用户的需求扩展到不同的阶段。
⏹支持多节点集群节省服务器资源⏹支持自动化容灾演练第 3 章系统预算3.1 所需要链路类型要求功能光纤链路距离《30KM，建议使用裸光纤同步链路IP链路距离无限制，要求带宽100M以上同步链路注：与Symantec官方交流过，考虑到用户要求数据零丢失，同时灾备中心也无任何主机，因此只能选择VxVM mirror的同步方式进行数据容灾，因此与交流时的带宽有差别，IP链路带宽要求在100M（满足IP—SAN正常运行的基本要求）。
