一、传统灾备：

金融行业一般都已经基于传统技术体系实现了灾备，分别是应用级别灾备，和基于FC网络的数据库灾备。具体形态：

（1）应用级别灾备，在本地和同城机房部署相同应用，访问主中心的数据库；

（2）存储级别灾备，特点是平时灾备中心不启动，例如EMCSymantec，IBM的PPRC，华为的Hypermetro

（3）数据库级别灾备，比如DB2HADR技术

（4）数据库级别的双活，需要数据库双活+文件系统双活+存储双活。比如Oracle的RAC或ADG+GPFS文件系统+存储的Vplex、SVC或Hypermetro

（5）网络方面:使用二层延伸的方法，本地系统和同城灾备在一个网段内，灾备切换中，需要将灾备中心的IP修改为生产中心IP。

二、云环境下的灾备：

思路与提升：

（1）大量使用IP存储网络替代FC存储网络，IP比FC网络组网个灵活，使用更方面，扩容更容易

（2）使用DNS实现大二层。这样切换IP更容易

（3）通过智能DNS实现了应用双活，基于域名的灾备切换

（4）使用虚拟机、容器替代实体机。出现了通过Vmware的SRM实现的整体系统在灾备，并实现了灾备调度系统

（5）基于CDP技术，实现数据同步和灾备

（6）分布式数据库，替代传统数据库，通过一主多从实现数据库级别灾备。

局限与待改进探讨：

（1）分布式架构下，系统更范围，节点更多，急切需要实现云平台在发布资源时整套环境

（2）SRM的基于IP的数据传输，默认是15分钟，RPO太长

（3）SRM是整个虚拟机的同步，不能像SAN存储那样实现只同步一个卷的数据（4）分布式存储，目前还不能像SAN存储那样实现可靠的存储级别的灾备

（5）分布式数据库分库分表、同城灾备后，交易一致性是一个难点，数据备份和数据恢复是一个难点。

希望听听金融行业的朋友们你们在云灾备和传统灾备建设下的思路、提升与局限？

几点想法，不妥的地方请指正：

1.传统灾备：您在文中提到的应用级别灾备，存储级别灾备，数据库级别灾备，我觉得用应用系统灾备，存储系统灾备保护，数据库系统灾备保护，这种说法歧异性小，更为合适。

2.SRM您提到的是VMware的SRM产品吧，实际上还是做作业流程管理的系统，这个产品并不能替代灾备复制技术或产品。

云计算现在已经不是新潮的技术了，但是金融机构应用系统上云的步伐相对缓慢。个人观点，应用上云会有几个阶段，初期阶段是为了上云而上云，传统架构上的应用系统移动到云环境中，中级阶段部分应用组件适应于云环境部署，终极阶段符合云环境的云原生应用真正在云上生根。每个阶段所涉及不同的灾备技术。

对于这个问题，我觉得可能需要从以下几个方面去分析：

首先，传统灾备建设和云环境下的灾备建设不能去比较，在金融行业当中，什么样的系统需要在传统环境下去运行，什么样的系统需要在云环境下去运行，这个是完全根据业务的特点来决策的，并不能以基础架构技术的所谓先进性来决策。不能简简单单说容器技术一定会优于IAAS技术，也不能简简单单说分布式数据库一定优于关系型数据库。根据业务的特点选择最适合的架构，选择最适合的灾备架构。

其次，灾备的建设目标根据不同的业务连续性要求，会有很大的区别。如果我的RTO要求是15分钟，RPO要求是0，这是一种建设方案。如果我的RTO要求是60分钟，RPO可以容忍15分钟，那么灾备方案是另外一种模式。金融行业在云环境下可以运行的应用，相信和自己传统资源池当中的应用系统的要求一定不一样，所以呢云环境下的灾备个人觉得主要的