这可能就是银行需要的开发测试架构？

今天在TWT社区看到一个问题，在这里分享一下

问题描述

银行业数据库（以Oracle为例）备份以及依赖备份的开发环境数据恢复架构应该如何建设？

目前我行现有的架构为：

生产定时通过数据泵（EXPDP）备份出压缩DUMP——放至多个FTP服务器（采用超大容量廉价硬盘PC，40T-120T）——开发环境从FTP服务器取DUMP——脱敏——使用。

但是现有架构，其实在现今银行数据量越来越大的情况下早已捉襟见肘，主要问题反应在以下几点：

（1）数据库数据大后，expdp导出的时间较长，一些OLAP数据库已经无法在非业务时间段完成备份。

（2）导出时对生产IO影响较大，会影响夜间一些批处理工作的。

（3）对于大库的开发环境恢复，导入+脱敏的时间非常长，会造成开发人员的无意义等待。请问，目前是否有哪家银行有好一点的备份、利用备份开发环境恢复的方案？还望不吝赐教。

之前也有了解过一些解决方案，但是有以下几点顾虑，也不知道诸位在实际使用中是否有遇到：

（1）如果使用专业备份设备、软件，如NBU、EMC DD，即利用rman+archive log的方式备份，那么归档的过大，是否会造成大量浪费？

（2）利用rman+archive log的备份片，如果想在开发环境恢复，应该较为麻烦，如何解决？我行生产数据库可能有近10个系统，如果仅仅想恢复一个系统数据到开发环境，如何实现？

（3）利用存储快照进行备份，开发环境使用快照。这种情况我不清楚对于存储的要求有多高，但假设要保留近3年的数据，我想这个成本应该是非常大吧？不知道有无银行是这种架构，使用感如何。感谢，感谢。

问题分析

当前存在的问题有以下几个：

1、备份时间长原因：一方面是由于数据量大；一方面是由于备份方式不得法！

2、备份方式问题：采用expdp方式，这个问题我觉得比较大，这么大的数据量，备份频率不可能太高，一旦出现问题丢失的数据量可能是不能承受的；

开发环境准备时间长，这个问题很明显，数据量大，全部靠人工导入、导出，时效性肯定不行；另外这也造成开发测试环境数据的新鲜度不够；

3、脱敏只是一个功能性的要求，这个没什么问题，所需要考虑的就是如何和所需的要求实现高度的集成，形成自动化操作；

解决办法

分析问题，结合现在市面上在备份容灾方面各种解决方案，窃以为只有CDM是最为合适的解决方案；

CMD的优势如下：

1、能够实现永久增量备份，每天只备份增量变化数据，能够大大减少备份时间，减少对生产系统的资源占用；数据库越大越合适；

2、备份数据的保存是原始格式，备份数据可以从CDM直接挂载使用；

像搭建测试环境这种事情，能够直接把备份数据挂载到测试服务器使用，不涉及数据的导入导出，不占用额外的存储空间；既能很快的搭建测试环境，又能保证测试数据的新鲜度；同时节省大量的存储空间，性价比极高；

3、一份备份数据，可以虚拟挂载成多个出来，不占用实际存储空间；满足搭建多测试环境的要求；

4、针对脱敏环境，可以直接将备份数据挂载至脱敏服务器进行脱敏，同时可以将脱敏后的数据再保护，受保护的脱敏数据可以再次的多次挂载给别的测试服务器使用；

解决方案拓扑

解决方案拓扑结构如下：