银行灾备双活怎么建：从规划到演练

银行做灾备，不是买个设备那么简单

2025年某城商行核心系统宕机4小时，因为存储阵列控制器故障，备库没切过去。银保监会罚了120万，行长被约谈。这件事在金融IT圈传开后，至少有6家城商行和农商行在2026年启动了灾备升级项目。

我们参与其中两个项目的交付。发现一个普遍问题：很多银行IT部门把灾备等同于"买两套存储+拉条专线"，规划阶段就埋了坑。这篇文章把同城双活灾备从规划到演练的完整过程拆开讲，给正在做或准备做灾备的金融IT团队一个参考。

一、需求拆解：先定RPO和RTO，再看技术

灾备建设的起点不是选产品，是定指标。银保监会《商业银行信息科技风险管理指引》要求：

• 核心系统RPO（恢复点目标）≤5分钟，RTO（恢复时间目标）≤30分钟
• 重要业务系统RPO≤30分钟，RTO≤2小时
• 一般业务系统RPO≤4小时，RTO≤4小时

实际操作中，城商行/农商行的核心系统通常按RPO=0、RTO≤15分钟来规划，也就是数据零丢失、15分钟内恢复业务。这个指标直接决定了技术选型：

指标要求	技术方案	大致成本（万元）
RPO≤30分钟	异步复制+定时备份	80-150
RPO≤5分钟	准实时同步+CDP	200-400
RPO=0（零丢失）	同城双活+存储同步镜像	350-800

成本差异主要在链路、存储设备和软件授权上。350万到800万的区间看着大，实际取决于两个因素：数据量和链路距离。

某农商行核心数据量12TB，两机房相距18公里，双活方案总投入410万。另一个城商行数据量45TB，两机房相距35公里，总投入680万。数据量翻3倍，成本只增67%，因为基础链路和人力成本是固定的。

二、架构选型：三种同城双活方案对比

银行核心系统的同城双活，目前主流有三种架构：

方案A：存储层双活（华为OceanStor / 深信服EDS双活）

两套存储设备通过专线实时同步，主机通过多路径软件同时读写两个存储。存储层做双活，应用层主备或双活。

优点：对应用透明，改造量小。缺点：存储设备要同型号，链路带宽要求高。

方案B：应用层双活（Oracle RAC跨机房 / 数据库层同步）

数据库在两个机房各跑一套实例，通过存储层同步或日志同步保持一致。应用两边同时提供服务。

优点：真正业务双活，切换无感知。缺点：数据库授权费贵，Oracle RAC跨机房方案授权费可能在200万以上。

方案C：超融合双活（深信服HCI双活集群）

两机房各部署超融合节点，虚拟机在集群内跨机房迁移和故障切换。存储是分布式架构，数据多副本跨机房分布。

优点：建设快，运维简单，成本相对低。缺点：适合中小银行，超大规模核心系统可能撑不住。

实际选型看三个因素：

维度	方案A存储双活	方案B应用双活	方案C超融合双活
数据量上限	500TB+	200TB	100TB
切换时间	30秒-2分钟	0-30秒	1-5分钟
建设成本	中高	高	中低
运维复杂度	中	高	低
适合银行类型	股份行/大城商	股份行	城商行/农商行

我们交付的两个项目都是城商行，选了方案C超融合双活。原因很简单：数据量不到50TB，运维团队8个人，Oracle RAC授权费比整个超融合集群还贵。

三、链路规划：带宽和延迟是生死线

同城双活的核心不是存储，是链路。

两个机房之间的光纤链路要同时满足带宽和延迟要求：

• 带宽：核心数据同步带宽 = 峰值写入吞吐 × 1.5（留50%余量）
• 延迟：同步写入要求单程延迟≤2ms（35公里以内）
• 抖动：链路抖动≤0.5ms，否则同步写性能波动大

某城商行峰值写入吞吐约200MB/s，规划链路带宽用了300MB/s（约2.4Gbps），租了两条10Gbps裸光纤（主备），年租金28万。

链路距离对延迟的影响：

距离	光纤延迟（单程）	是否支持同步写
10km	0.05ms	✅
20km	0.1ms	✅
35km	0.17ms	✅（临界）
50km	0.25ms	⚠️（需评估）
100km	0.5ms	❌（用异步）

35公里是个实际分界线。超过40公里，同步写的延迟叠加会开始影响核心交易性能。如果两个机房距离太远，建议改为异步复制，RPO从0变成秒级。

踩坑提示：链路别只拉一条。我们有个项目机房在高新区和经开区之间，市政施工挖断光纤两次，每次3小时。双活必须有主备链路，而且最好走不同物理路由。

四、成本测算：城商行双活灾备预算参考

以某城商行核心系统12TB数据量、双机房18公里为例，整个双活项目预算清单：

项目	规格	金额（万元）
超融合节点（主机房）	6节点，每节点256GB内存/4×3.84TB NVMe	96
超融合节点（备机房）	6节点，同上	96
网络设备	两机房各1套Spine-Leaf	38
专线链路	2条10Gbps裸光纤，年租金	28/年
灾备软件授权	跨机房集群+自动化切换	22
实施服务	规划+部署+调优+演练	45
后续运维	年度服务费	15/年
首年总计		约330万
次年起		约43万/年

这个预算对城商行来说算中等偏上。如果数据量更大或选Oracle RAC方案，首年投入可能到500-800万。

省钱建议：灾备建设可以分阶段。第一阶段先做异步复制+定时备份（80-150万），保证RPO≤30分钟。第二阶段再升级到双活。某农商行就是这么做的，分两年投入，每年预算压力小很多。

五、灾备演练：建了不练等于没建

银保监会要求银行每年至少做一次灾备演练，实际执行中很多银行流于形式——选在周末半夜，停掉主库，切到备库，10分钟切回来，发个通报说演练成功。

这种演练发现不了真实问题。我们建议客户做三种演练：

1. 桌面推演（每季度）

不实际切换，模拟故障场景，让运维团队按流程走一遍。重点检查：联系人是否更新、切换脚本是否最新、审批流程是否通畅。每次推演通常能发现3-5个小问题。

2. 计划内切换演练（每半年）

在维护窗口实际切换业务到备机房，运行1-2小时后切回。重点验证：切换时间是否达标、备机房性能是否够、应用是否兼容。某城商行第一次计划内演练，切换花了8分钟（目标15分钟），但切回花了42分钟——因为回切流程有bug，主库和备库数据同步状态不一致。

3. 无通知演练（每年一次）

不提前通知运维团队，模拟真实故障。这个演练争议大，很多银行不敢做，但最能暴露问题。某城商行做无通知演练时发现：备机房的空调功率不够，所有服务器同时跑起来5分钟后温度告警。这个问题平时根本发现不了。

六、几个踩过的坑

坑1：DNS切换没自动化

灾备切换时DNS解析要跟着切，很多银行DNS切换靠人工改记录，光找DNS管理员就花15分钟。建议用DNS智能解析（GSLB），切换时自动改解析。

坑2：备机房没人值班

主机房有运维团队，备机房可能只有保安。切换过去后发现需要物理操作（比如重启服务器），人赶过去要40分钟。备机房至少要有1人值班或30分钟内能到场。

坑3：监控没覆盖备机房

很多银行监控只看主机房，备机房的CPU、内存、存储状态是盲区。等切换过去才发现备机房存储快满了。监控必须双机房全覆盖，告警统一到一个平台。

坑4：灾备环境配置漂移

主环境改了配置（比如数据库参数、防火墙规则），灾备环境没跟着改。时间一长两边配置不一致，切换后应用报错。建议用配置管理工具（Ansible / SaltStack）统一管理，变更自动同步。

写在最后

银行灾备建设最大的误区是重建设轻运维、重设备轻流程。花几百万买设备，但演练不做、文档不更新、人员不培训，真出事的时候照样手忙脚乱。

如果正在规划灾备项目，建议先做一次灾备能力评估——看看现有架构的RPO/RTO实际能做到多少、运维团队的切换能力如何、流程文档是否齐全。评估完再决定建什么、买什么。如需方案评估或技术交流，可以联系华南腾飞科技，我们在金融行业有多个灾备交付案例。

相关阅读：

• 超融合和分布式存储有什么区别？五个维度拆解
• 超融合采购逻辑变了，怎么选？