金融行业集中备份平台建设难点与坑点 | 干货总结
前言
有效管理金融核心数据日益成为银行业重中之重工作。综合考虑数据备份现状及监管要求，启动集中备份平台建设迫在眉睫。
本文由社区专家程祖桥根据社区交流汇编，不仅包括数据备份项目难点坑点，还探讨了备份产品技术实现及特点、数据恢复与数据重删技术、海量数据备份需求以及快照技术、易混淆的备份相关概念。
一、建设数据备份项目时的难点、坑点
【Q1】在建设备份系统时，如何对备份平台建设进行选型？
@chengzuqiao：
可以从以下几方面选型：一是从备份平台扩展性，公司实力及后期研发力度，这可以保证备份平台后期维护及发展不落后。二是从备份平台对系统与数据库的支持，支持的越多越好。三是从备份平台行业案例，案例数越多，代表该产品越成熟越稳定。四是从备份平台压缩比技术、备份恢复速度与容灾实现便利性进行考虑，毕竟压缩比越高，备份恢复速度越快，工作效率就更高，因为备份数据是海量的，像我们行都有200T数据了。五是如果是金融行业，需要考虑下监管要求，毕竟监管也是很头疼的事。六是备份维护便利性等
【Q2】银行业建设备份系统过程中，需要考虑哪些问题？
@chengzuqiao：
根据我行实践，个人认为需要考虑这几方面，第一生产系统有哪些数据库类型、操作系统类型，选型的备份产品是否都支持。第二需要备份的数据量有多大，以根据最高性价比选择合适的存储。第三备份产品容灾技术实现以及是否能满足监管部门对数据备份要求，第四有哪些数据库较大，通过传统备份不能一天内完成，需要通过传统备份与快照结合实现，以评估备份平台对快照兼容性。第五备份产品的监控如何实现，是否能集成到现有的监控平台，因为在后期维护中，面对几百套甚至几千套系统，不可能每天去看，需要有一套完善的监控机制。第六对虚拟化平台备份的支持，因为现在大部分系统都是虚机。第七数据备份产品的海量小文件备份如何实现
【Q3】贵行在建设数据备份系统过程中，经过哪些阶段以及碰到过哪些技术问题？
@chengzuqiao：
我行在建设备份系统过程中，经过了备份项目两期建设，刚开始系统数量小，只是手工备份到磁带库中，后来系统不断增多，并且物理磁带由于是磁性读写容易坏，经常要若挪驱动器，很不方便，就开始建设集中数据备份平台一期，替代了带库与手工时代，针对不同系统实际需要，制定了详尽的备份策略，由备份平台统一调度，统一备份。后来随着移动互联及大数据时代冲击，作为数据备份的Nas存储基于IP网络读写不能满足我行备份速度需要，将Nas替换成华为存储，并通过SVC异步复制技术实现备份数据容灾，同时配合ECM实现海量影像切片数据备份与调阅。
上集中备份平台之前，碰到问题较多，比如数据备份失败了，没有及时发现，备份的数据有时也恢复不了，磁带经常报错等等
【Q4】建设备份系统，有哪些误区? 哪些坑点？
@chengzuqiao：
数据备份系统，在平时工作中，是很少通过数据备份系统恢复生产数据，一般作为测试使用。这很容易造成人们认为数据备份不是很重要，其实这是相当危险的，不管在那个行业，数据是最重要的资产，而数据备份是最后一套数据安全防线，一旦那天数据出现了不可预测的故障，需要通过数据备份系统来恢复，而此时你又不做数据备份，可想而知后果多严重。所以做好数据备份是非常重要的。
数据备份情况一定要做好监控，特别是全行级的数据备份，因为系统众多，你不可能每天去巡检，像TSM就可以tivoli监控产品进行结合，做到实时监控。这样可以保证每天数据备份正常完成。
数据备份一定要做好数据备份策略控制与备份存储池划分，做好数据备份节点命名，要不然随着系统增多，你都不知道那些系统是干什么的，策略是怎样的，很杂乱，不便于管理。
备份数据校验这一块，我觉得是TSM备份产品考虑不周全的地方，每次监管来检查，他们都问我们有没有定期恢复，由于我们行系统众多，不可能每台系统做定期恢复，其实只要TSM提供个校验功能，我就可跟监管部门解析，尽管我们解析，只要TSM备份完成没有报错，数据就是完整的，是客恢复的，可人家不信啊，我们现在都是通过DB2数据库db2chkrst命令定期自动校验以满足监管要求。
二、备份产品的运维、容灾及技术实现及特点
【Q1】备份产品自身的容灾如何去考虑？
@huijx：
灾备中心重建备份系统，将生产中心的备份catalog以及备份数据实时同步至灾备中心。灾备中心catalog需定期导入。恢复数据时候需注意IP地址和主机名的变化。
@chengzuqiao：
备份产品不像核心应用系统，不建议在本地搭建，一般在同城搭建，主要保障数据容灾，当然如果成本允许的话，当然多重保障更好。同城容灾的话，一般在同城搭建一套同样的备份产品，备份数据及备份产品数据库信息通过存储的异步复制技术传输至同城实现。
@louyf：
TSM 支持多个TSM服务器之间互传备份数据及控制信息，TSM服务器之间的IP网络联通即可。灾难发生后，TSM客户端可从存活的TS服务器恢复数据。
【Q2】一部分通过TSM备份至DCS3700，另一部分通过TSM备份至NAS存储，是怎么具体实现的？
@louyf：
TSM服务器通过SAN连接DCS3700, 将3700的LUN 划给TSM服务器，TSM服务器上做一个文件系统，定义一个file device class指向这个目录，或新版本定义一个容器池指向此目录。
TSM服务器通过IP网络挂载NAS存储，将挂载的目录在TSM服务器上如上所述定义为另一个备份池。
TSM服务器上制定不同的策略，分别指向如上定义的两个备份池，即可分别备份数据到两个存储。
【Q3】DB2、Oracle、MySQL等主流数据库备份实现方式有什么区别？
@chengzuqiao：
db2备份是采用TSM调用db2 api接口实现，在tsm的api文件夹配置相关数据库IP信息就可。
Oracle 备份是采用TSM 调用oracle rman接口，安装TDP,配置tdpo.opt,dsm.opt。
mysql 备份通过mysqldump命令备份生成文件，然后备份至TSM中，并定时清理。
【Q4】数据备份运维方面如何去考虑？大量数据备份验证如何去解决？
@chengzuqiao：
一定要做好数据容灾建设，因为你的数据集中了，相当于数据风险也集中了，一旦你的存储某一个阵列坏了可能造成你整个数据都不可用，这是很危险的。
数据备份情况一定要做好监控，特别是全行级的数据备份，因为系统众多，你不可能每天去巡检，像TSM就可以tivoli监控产品进行结合，做到实时监控。这样可以保证每天数据备份正常完成。
数据备份一定要做好数据备份策略控制与备份存储池划分，做好数据备份节点命名，要不然随着系统增多，你都不知道那些系统是干什么的，策略是怎样的，很杂乱，不便于管理。
备份数据校验这一块，我觉得是TSM备份产品考虑不周全的地方，每次监管来检查，他们都问我们有没有定期恢复，由于我们行系统众多，不可能每台系统做定期恢复，其实只要TSM提供个校验功能，我就可跟监管部门解析，尽管我们解析，只要TSM备份完成没有报错，数据就是完整的，是客恢复的，可人家不信啊，我们现在都是通过DB2数据库db2chkrst命令定期自动校验以满足监管要求。其他文件备份，这个我们只能通过TSM备份机制去保证。
三、数据恢复与数据重删技术
【Q1】几大主流数据库的备份，除了双机热备，有没有好的办法在恢复时尽量减少数据丢失？
比如SQLServer中的备份策略，Mysql中的sqldump、Oracle中的exp或者rman，db2的tsm备份等等。所有这些数据库的备份，按照正常一般企业的现有条件，大都是一天一备为主，备份时间一般都是选在晚上，在没有双机的条件下，这几种主要的数据库如果真发生服务器故障或者数据库不可逆的故障时，在恢复数据时，如何保证数据恢复的完整性？因为平时我们备份也是把c盘的数据库数据备份到d盘或者其他盘。如果服务器坏了即使备份也没有用。各位仁兄有什么好的备份方法吗？平时你们单位都是怎么实现数据库备份的？
@ytskfzj：
首先，双机热备本身只是应用的高可用，对数据丢失没啥帮助。
其次，数据丢的少，靠定时备份的效果是比较差的。
建议是“实时备份”+定时备份，例如MySQL的mgr、Oracle的adg、mssql的镜像/AlwaysOn作为“实时备份”，文中提到的部分按照策略作为定时备份。或者使用第三方软件（以商用软件居多），使用CDP或者OGG类的方式作为实时备份， 并结合定时备份。
@libai21：
从减少数据丢失的角度看，方法还是很多的，不同的实现方法，成本相差也很大。
最省钱的方案，定时的截断数据库日志，然后传送到另外一台机器或者另外一个机房，那么最大的数据损失就是两次日志截断的时间产生的日志。
第二种方法是利用数据库的高可用功能，比如DB2 HADR，Oracle Dataguard，SQL SERVER Always On等，这些功能都可以达到秒级的日志损失。
第三种方案是利用存储的复制功能，这个相对更加复杂，投入和维护也比较麻烦，需要专业服务。
@chengzuqiao：
你说的双机热备如果指数据的话，可以通过基于数据库日志实现读写分离，数据库可以同时读，但写只能写一边，只要其中任何一边出现问题，就可以切换至另一边，以保障数据正常访问。像DB2 HADR，Oracle Dataguard都可以实现数据热备。
回答你第二个问题，数据备份是要实现数据隔离的，起到数据保护作用。而贵方设计的数据备份在同台机器上，是不符合数据备份要求，你需要把你的数据备份至其他机器上，这也就是建设独立的数据备份平台很有必要。我行是建设了独立的集中数据备份平台，对数据进行了隔离，并且备份了数据与日志，而不像贵方只备份了数据，没有备份日志，这样一旦数据出现逻辑错误，只能恢复至备份时间点，如果备份日志，就能避免你说的这些问题，可以恢复任何一个时间点，只是RTO长一点。
【Q2】如何设计数据恢复速度？
@chengzuqiao：
影响数据恢复速度关键因素有三个：存储设备的读写速度、带宽速度、CPU处理速度、恢复环境因素。
首先，从存储设备读写速度来说，假如你采用san网络进行恢复，san网络带宽充足，预算充足，就可以考虑源端和目标端采用好一点的存储或者带库，读写速度上去了，数据恢复速度自然就会提高。
第二，从带宽速度来说，理论上备份产品恢复速度一般都会大于IP网络带宽速度，所以采用san网络带宽进行恢复，速度肯定比IP网络带宽快。
第三，从CPU处理速度来说，最好不要集中对数据库进行恢复，特别是数据量较大的数据库，可以错开进行恢复。
第四，从恢复环境来说，由于我们数据大多存放在生产环境，如果要恢复至测试环境，涉及到跨网络，并且考虑到安全因素，一般我们生产环境与测试环境进行隔离，如果网络不打通，这就给我们恢复增加了流程，对小数据恢复来说还好，对数据量大的数据库那是非常影响速度，可以考虑对数据量大的数据库与备份平台打通，控制好安全，还是可行的。
【Q3】数据重删技术在源端，还是在目标端进行，或者采用数据库本身的重删技术，如何去考虑？
@chengzuqiao：
各有优点吧，如果在源端进行压缩的话，将会减少网络带宽压力，提升数据传输速度，但可能会消耗部分客户端性能，如果才用目标端压缩，对数据量大的数据库，网络带宽压力较大，同时对目标端服务器性能提出高要求，因为有可能同时备份多个数据库。一般建议在客户端进行压缩。至于是否采取数据库压缩技术还是备份本身压缩技术，据我行实践来看，采用数据库压缩技术较好，毕竟数据库对本身的压缩技术兼容性应该是最好的。但是不支持压缩技术的数据库，还是要采用备份产品的压缩技术。
【Q4】重删技术在块存储中如何实现？和文件的重删有什么区别？
@chengzuqiao：
文件的重删是基于一定算法实现，比如MD5算法、Sha算法、hash算法，进行文件哈希值计算，对重复的数据只记录一份，其他的重复数据保留一个地址引用。块存储重删一般采用定长重删或变长重删技术，定长重删就是把写入的数据按照固定长度进行切片，切片后进行hash计算，然后进行写入处理，非重复数据就单独写入，重复数据就写入引用即可。反之变长也类似，但变长重删对性能和算法要求都比较高，对CPU内存消耗较大，影响了数据的实时处理效率。
四、海量数据备份需求以及快照技术
【Q1】快照技术最近很火，比如CDP或者类似产品，能否代替传统的数据库备份技术？
@chengzuqiao：
快照尽管快，但是也是有局限性的。就拿CDP技术来说吧，你要不断监控我的IO，万一你那天不高兴了，突然对我的IO进行干预下或者中断下，那我的生产就惨了，得不尝试，还有你要监控我的IO，肯定涉及到IO兼容与代理安装，作为金融行业的生产业务来说，不希望你有太多风险因素的。同时对于一些小文件备份，难道你也要用CDP吗？那是杀鸡用牛刀，没有多大必要，并且CDP成本高。对一些测试类或者管理类的海量数据建议可以采用CDP技术进行数据备份。生产我还是稳步开展。所以在近期，是不可能替代传统备份的，并且生产上应用CDP的案例还真不多，而使用传统备份技术的肯定100%
@louyf：
快照可以用于快速恢复，测试数据库导入等场景，但是不能代替传统备份。因为快照数据仍旧在同一套存储上，存储故障时快照也不可用，还是需要传统的备份恢复。
@huijx：
快照和CDP是前几年的事，要代替传统数据库备份还差点意思。这里不讨论快照和CDP技术对性能空间各种资源等要求和影响，最关键的是快照难以保证数据库数据的一致性
【Q2】面对互联网冲击特别是大数据时代，传统备份如何去应对海量数据备份？
@chengzuqiao：
确实，在大数据时代，数据都是呈指数级别增长，包括结构化数据与非结构化数据，是不是面对海量数据，传统备份真的是无力施展昵？其实也不见得，需要具体问题具体分析。比如我行的影像系统，主要存放图像切片，数据量至目前有120T左右，都是有海量的小图片组成，面对如此数据，传统备份TSM是不是就做不了呢，当然可以做，我们是采用TSM+ECM+GPFS实现的，7天内的数据保存在GPFS文件系统中，超过7天的通过ECM归档迁移至TSM，以保障前台调阅任何时间的影像需要。还有我们大数据平台，数据库也是巨大的，我们是采用TSM+SVC快照实现，通过TSM调用SVC接口，定期备份，备份策略通过TSM控制，以保障数据统一存放与隔离。
【Q3】选择CDP容灾技术需要注意哪些事项？
@chengzuqiao：
CDP技术是提供持续数据保护，是基于数据块级的快照，对事务性的数据很难保证一致性。CDP技术说了很多年，但就是应用不广，主要是CDP技术需要持续捕获IO，并且存在不同存储或主机、磁盘IO兼容性问题，如果生产数据量变化大的话，会对整个生产IO构成压力，CDP技术也出现过一些生产问题，并且有的CDP技术需要安装代理或者结合LVM技术实现，这势必会对生产系统产生性能影响，因此CDP技术使用时需要慎之又慎。
总的来说，需要考虑你的生产变化IO，如果你IO变化很多，那你产生快照时间就要拉长，有可能影响你的生产。需要考虑快照个数，如果快照个数太多，对生产带宽开销是否能承载。需要考虑第一次数据全量与后期数据变化量传输情况，如果在规定的时间内，没有传输完毕，如何处理，是否会影响生产。需要考虑是否安装代理或者采用系统LVM技术，因为这会对系统性能产生压力。需要考虑与其他存储产品IO兼容性，要不然以后出了问题，存储与CDP厂商都扯皮。需要考虑事务性数据如何保障一致性等等。
【Q4】国内主流CDP软件？
请教各位大神，国产软件中有哪些比较好的CDP软件呢，类比EMC RecoverPoint；同时和双机热备技术对比的话，有哪些具体的差异点呢。
@chengzuqiao：
https://wenku.baidu.com/view/df3e96630b1c59eef8c7b411.html 这篇文章列举了几大主流CDP技术，也进行了详细对比，可以参考下，各有优缺点，CDP技术说了很多年，但就是应用不广，主要是CDP技术需要持续捕获IO，并且存在不同存储或主机、磁盘IO兼容性问题，如果生产数据量变化大的话，会对整个生产IO构成压力，CDP技术也出现过一些生产问题，因此CDP技术使用时需要慎之又慎。
CDP技术是提供持续数据保护，是基于数据块级的快照，对事务性的数据很难保证一致性。因此它是和双机热备是不同的概念，前者主要是容灾保护或数据逻辑错误，而双机热备主要是保障应用、数据库连续性，应用可以通过负载均衡采用集群技术，数据库可以结合主机高可用软件或基于日志方式实现数据库高可用。
@EndlessRain：
直接面对你的问题，再加一些科普：
国产软件的CDP产品，大部分和RecoverPoint，飞康IPstor，DataCore Symphony有本质的区别。
他们的普遍做法是“在应用层”来实现整个周期，当一个“文件”落盘后进行复制到目标存储，复制结束后给当前“文件”打上时间戳。这里有一个关键的焦点——“文件”。
上述列举的(RecoverPoint，飞康IPstor，DataCore Symphony),他们普遍方式是，这个捕捉的流程在存储底层来做，针对的焦点——则是写入的"I/O"。
区别是什么？：例如，复制目标磁盘1个10GB ISO文件，复制周期是50秒钟，在这50秒周期内观察目标磁盘容量属性，也确实目测到容量实时更新。当进行到30秒时中断复制进度(模拟事故)。
最终尝试恢复数据时候两类产品会大致会有两种不同的结果：
其一，由于中断了复制进度，目标磁盘没有看到此“ISO 文件”，没有触发CDP，固然无法提供恢复的"点"。
其二，提供之前30秒时间区间的“数据状态”的“点”，当恢复之后你能目测到目标磁盘有一个"ISO文件"，只不过此文件损坏了，体积当然也不是10GB，但是这个结果却有更深远的意义，较之上述。
你的第二个问题，这不是传统的“双机热备”，但是理解上可以等效为“双存储热备”。
在2000年之前，这类容灾技术匮乏，昂贵，我能想到的也就是IBM PPRC，EMC SRDF，HDS TrueCopy，而且也没有下放到低端存储。中小企业只能选择带有CDP产品：用于备份/容灾，且可以手动按照时间点恢复，当时也是不错的(只不过对主机或原数据磁盘带来额外性能开销)。
现如今来看，很多具有CDP技术的厂商已然不会单独推荐用CDP做高可用了，而CDP技术本身一些副作用也得到了规避。所以你也无需用CDP与“双存储热备”两种类型产品进行比较了。
具备CDP技术厂商推荐的架构？
EMC推荐VPLEX+CDP(RecoverPoint)，DataCore软件推荐HA+DR(开启CDP)，飞康则是NSS。
他们架构相似：两台独立存储进行实时热备，提供存储节点之间的数据持续高可用。然后，增加单独一个装置进行CDP持续捕捉，把可用性扩展到应用层，即：逻辑成为，病毒入侵，网络攻击，恶意损害等逻辑层方面。这个过程完全可以在存储层做，与应用无关。通过代理软件在应用主机，为每一次缓存落盘做标记，提供类似OLTP等关键业务数据的一致性。
PS，这三个产品我比较熟悉，熟悉程度是参与过项目安装和配置，而不是简单看看彩页，所以用他们举例。别的厂商也许同样具备，但我没深入接触，不敢妄言。然后就是这三个产品具备True CDP，而不是基于连续的快照Near CDP，这点可以参照SNIA权威解释。
五、几个容易混淆的数据概念
【Q1】数据备份与数据容灾常常被混淆，它们之间到底有什么区别？
@hp1979：
1.容灾、备份的区别
容灾 （Disaster Tolerance）：就是在上述的灾难发生时，在保证生产系统的数据尽量少丢失的情况下，保持生存系统的业务不间断地运行。
容错 （Fault Tolerance）：指在计算机系统的软件、硬件发生故障时，保证计算机系统中仍能工作的能力。
区别 ：容错可以通过硬件冗余、错误检查和热交换 再加上特殊的软件来实现，而容灾必须通过系统冗余、灾难检测和系统迁移等技术来实现。当设备故障不能通过容错机制解决而导致系统宕机时，这种故障的解决就属于容灾的范畴。
什么是灾难恢复 （Disaster Recovery）：指的是在灾难发生后，将系统恢复到正常运作的能力。
区别 ：容灾强调的是在灾难发生时，保证系统业务持续不 间断地运行的能力，而灾难恢复强调的灾难之后，系统的恢复能力。现在的容灾系统都包含着灾难恢复的功能，所以本文的讨论除了包括容灾方面的内容，还包括了 灾难恢复的部分内容。
容灾系统在企业中给与数据安全系数相当高的保障，但是容灾系统倒是是什么，他们是什么意思？恐怕连正在使用容灾备份的网络管理人员都不能解释。本文用最浅显的语言给大家解释容灾备份到底是什么。
2．容灾和备份的目的不同
容灾系统的目的在于保证系统数据和服务的“在线性”，即当系统发生故障时，仍然能够正常地向网络系统提供数据和服务，以使系统不致停顿。
而容灾备份技术的目的与此并不相同，备份是“将在线数据转移成离线数据的过程”，其目的在于应付系统数据中的逻辑错误和历史数据保存。
所以，在各种容错技术非常丰富的今天，备份系统仍然是不可替代的。
2．备份是基石
备份是指为防止系统出现操作失误或系统故障导致数据丢失，而将全系统或部分数据集合从应用主机的硬盘或阵列复制到其它的存储介质的过程。
备份是数据高可用的最后一道防线，其目的是为了系统数据崩溃时能够恢复数据。
3．容灾不可少
那么建设了备份系统，是否就不需要容灾备份系统？这还要看业务部门对RTO（恢复所需的时间指标）/RPO（能够恢复到的最新状态）指标的 期望值，如果允许1TB的数据库RTO＝8小时，RPO＝1天，那备份系统就能满足要求。同时，备份的目的在于应付系统数据中的逻辑错误和历史数据保存。只能够满足数据丢失、数据破坏时的数据恢复目的，而不能提供实时的业务接管功能。
因此容灾系统对于某些关键业务而言也是必不可少的。人们谈及容灾备份往往是针对当生产系统，不能正常工作时，其业务可由容灾系统接替这些业务，继续进行正常的工作。
能够提供很好的RTO和RPO指标。同时远程容灾系统具备应付各种灾难，特别是区域性与毁灭性灾难的能力，具备较为完善的数据保护与灾难恢复功能，保证灾难降临时数据的完整性及业务的连续性，并在最短时间内恢复业务系统的正常运行，将损失降到最小。
4．容灾不能替换备份
容灾系统会完整地把生产系统的任何变化复制到容灾端去，包括不想让它复制的工作，比如不小心把计费系统内的用户信息表删除了，同时容灾端的 用户信息表也会被完整地删除。如果是同步容灾，那容灾端同时就删除了；如果是异步容灾，那容灾端在数据异步复制的间隔内就会被删除。这时就需要从备份系统 中取出最新备份，来恢复被错误删除的信息。因此容灾系统的建设不能替代备份系统的建设。
5．规划企业安全保障体系考虑的因素
对于企业而言到底应该如何建设自己的灾备系统，是只建设备份系统、还是只建设容灾系统、还是需要二者同时建设、或者是分步骤的建设，谁先谁后等问题，主要根据业务的需求而定：
（1）需要防范的灾难类型：
企业信息系统可能遇到的灾难类型及其发生的比例如下：
对于“人为错误”、“软件损坏和程序错误”加上“病毒”等这些都称为逻辑错误，占总故障的 56%，这些错误只能通过备份系统才能防范；
对于“硬件和系统故障”以及“自然灾难”等故障可以通过在容灾系统（或者异地备份）来防范，占总故障率的44%。
（2）允许的RTO和RPO指标
从技术上看，衡量容灾系统有两个主要指标：RPO（Recovery Point Object）和RTO（Recovery Time Object），其中RPO代表了当灾难发生时允许丢失的数据量；而RTO则代表了系统恢复的时间。
一般而言：容灾系统能够提供较好的RTO和RPO指标。
（3）系统投资
总的说来，建设备份系统的投资远比建设标准意义的容灾系统的投资小得多：
备份系统的投资规模一般在几百万；
而最节省的一套容灾系统投资都将上千万；
6．常用的灾备组合方式
基于以上原因，业界在灾备系统的建设上一般按照以下几种方式：
建设机房内的本地备份系统
建设异地的备份系统
该方式可以备份系统的价格满足备份和异地容灾功能，能够避免主生产中心由于地震、火灾或其他灾害造成的数据丢失。
备份系统＋异地容灾系统
这是一个较为理想化的容灾系统一体化解决方案，能够在很大程度上避免各种可能的错误
【Q2】最近经常提到数据大集中，关于数据大集中和集中备份平台之间，有什么联系？集中备份平台是否是数据大集中后保证数据安全的一种方式？
@chengzuqiao：
数据大集中与集中备份平台是两个不同的概念，数据大集中大集中是指将分布在各个分支机构和营业网点的业务数据及其他一些相关的数据实现统一集中管理，比如建立数据中心，将各个分支机构数据统一至数据中心，各分支机构不再存放数据，只是终端设备。数据大集中是依靠科技手段，实现数据的集中和数据的整合，通过对数据深层次的挖掘，对银行的客户数据、业务数据进行系统分析和评价，推动商业银行向决策科学化方向迈进，提高银行的管理水平和工作效率。而集中备份平台是指数据大集中后，为防范数据逻辑风险及数据保障需要，对所有生产交易数据进行备份。
资料推荐：
TSM实施完全教程
http://www.talkwithtrend.com/Document/detail/tid/405269
基于TSM集中备份和容灾设计方案
http://www.talkwithtrend.com/Document/detail/tid/414449
IBM TSM详细的安装配置与维护手册
http://www.talkwithtrend.com/Document/detail/tid/414523
银行业集中备份平台建设需求与实践经验总结
http://www.talkwithtrend.com/Document/detail/tid/418057
点击阅读原文关注社区 备份技术主题 ，将会不断更新优质资料、文章，您也可以前往提出疑难问题，与同行切磋交流：
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”