如何做到快速恢复，各个友行的恢复策略怎样部署？

回复 2# gilbert


    我理解快速恢复应该是通过灾备来解决，最快是建设应用系统双活，基本不影响业务；再一个就是建设应用层双活，数据库有灾备，切换时只切换数据库会把RTO降至最低。
如果是逻辑层面的操作失误非得恢复数据库的话，最好有历史库，始终保持联机库轻量级，或者把影响联机业务的数据放在独立的表空间中，以表空间恢复的方式尽快从备份中恢复数据从而恢复业务，否则现在的数据库动则几十T要恢复是灾难性的，收起

备份数据的目的是恢复数据，所以谈到恢复，个人觉得可以和备份入手，之前的经验是将数据备份到磁带或带库中，根据需求做出相关数量的份数，定期送至同城及异地灾备中心以备恢复使用，不要担心这样做会需要很长的时间，可以利用每天夜里账务批量处理之后进行。
仅供参考收起

双活数据中心肯定是恢复最迅速的，但同样和楼主提出的问题一样，带宽的需求会很大，如果是同城双活中心，可以通过DWDM多波聚合设备通过裸光纤连接方式，但这个一般都对距离要求比较大，一般不会超过50公里。这种情况一般没有带库的问题。如果是长距离传输，走专线形式，就会对带库有要求。比较适合做应用级的数据容灾，利用类似goldengate软件进行日志分析后传输，较少传输的数据量。节约带宽需求。收起

确实如上所述：
1.业务在数据设计上做分离，将需要用到的联机/近期数据尽量轻量，将历史类数据后置，通过数据复制增量到异地，这一步必须要做，带宽需求再大也不能异地没有必须的数据
2.恢复时则先联机再历史收起

数据库备份与恢复，从上线前就需要设计数据库表空间架构。可是对已经上线的系统。在修改架构难度就很大。大库轻量级涉及到表较多。调整周期也较长。比较头疼，有没有其他好的办法啊。收起

如果对RTO要求不高，可以做存储级的异地增量复制，速度快收起

邮政有superdone2哈收起

双活数据中心一定会存在性能上的瓶颈，早日考虑分布式多活才是最终解决办法。分布式多活的数据一致性又是银行系统最不放心的;P收起

忘记说了，如果需要快速恢复，肯定是双活的应用级恢复最快，但整个切换过程还是需要很好的切换流程和自动化脚本来实现快速切换，流程需要很好的业务流程梳理，做好切换演练是保证快速切换的基础。收起

比较关心邮政储蓄是怎么实现的，他们没有使用IBM小型机，用的全是x86服务器。收起