有奖讨论：你们公司真正做到了定期恢复演练吗？

一.灾备恢复的由来

   恢复演练在中国做的最多的就是银行。其实容灾恢复演练从90年代末到2000年初，各国都有规划，不仅仅是美国，中国的银行在建设大集中数据中心的时候也有规划。但是从什么时候国外开始重视的？911事件之后，美国变得异常重视容灾恢复演练，制定了针对于银行业的7000多个预案，也催生了一大批的容灾和业务连续性的公司。摩根斯坦利和德意志银行在911发生之后第二天就恢复了业务的运营，而纽约银行因为没有容灾和恢复计划，结果被迫清盘倒闭。中国从什么时候开始重视容灾恢复演练的？2008年5月12日汶川地震之后。四川很多银行、保险、电力的数据库遭受毁灭性打击，但是太平洋保险因为平时有恢复演练，13日就在总部恢复了四川的业务，被银监会重点表扬，呵呵。容灾恢复演练做的最好的是四大行，现金流充沛嘛，当然商业银行和区域银行这几年也开始了相关的容灾恢复演练，当然区域银行要在外地有分行才会做异地容灾恢复演练。

  恢复演练最早的形势是模拟演练，桌面演练，就是不动生产库的，对付对付。后来由于银监会和人民银行下了死命令，银行才开始玩真的了，当然也要随着银行的两城三中心的建设的进度开展不同级别的演练。最早的恢复演练是在生产中心内部，不同系统/主机之间的恢复演练。随着同城灾备中心的建设进展，也可以进行同城不同中心的恢复演练，要考虑业务连续性，以及分行和营业部的接入测试等。随着异地灾备中心建设（上海或者深圳）完毕，南北两大中心之间互为灾备，这样远程恢复演练也可以开展了。四大行总行数据中心级别每年都要搞一个灾备恢复演练（政策要求），分行的灾备恢复演练更有难度，也在一些区域逐步开展。

  恢复演练的目的是为了抗毁和业务连续性。这个如上面很多兄弟所说，包含了非常多的元素，是一个非常庞大的工程，技术只是很小的一个方面。
目前据我所知，银行、电力、电信行业、航空都进行过灾备恢复演练。

二. 灾备恢复演练的三点注意事项

第一，领导绝对要从第一次就开始重视

     在国企，银行领导要是不重视，你很多东西别想玩起来。这种重视是要在一开始建设数据中心的时候就要提醒领导重视起来，而不是在灾备恢复演练的时候重视，将很多问题和需求都在第一次的时候和领导讲清楚，讲明白，强调灾备的重要性，以及一些惨痛的教训，比你以后再提再改IT结构要省事的多，这是我的亲身体会。用华为的价值观来说就是第一次把事情做对。很多银行在一开始建设数据中心的生产中心的时候，同城灾备和异地灾备中心就同步建设，并物理同构，系统同构，使用不同的运营商的网络以及不同的电力支援系统。成功的灾备恢复对成本要求的非常之大，前面很多兄弟也提到过，灾备中心98%的时间都是闲置的，但是2%的时间出现问题，基本就会造成毁灭性的打击。现在银行领导已经不会不重视了，因为银监会，地方的银监局都会督促的。但是我们IT的兄弟们一定要在第一次就将问题讲足，讲透，让领导明白我们的roadmap规划。

    当然，区域银行在财力上有所不及，就只能考虑能力范围内的灾备恢复，比如重点数据，重点系统等。同构建设，异地建设就要量力而行。

第二，制定完善的规章制度和详尽具体的指导手册

    什么是规章制度，就是要所有人都知道你办事有据可查可依，而不是随意办事，就是要所有人都知道各自的角色和任务。规章制度绝对是非常有用的（我之前很轻视的，后来工作让我知道是非常重要）。中国人民银行和银监会对银行的灾备恢复有明确的政策文件，也有国家标准，但是不同企业也要根据各自的实际情况，具体需求，制定各自的规章制度，这就是企业标准（比行标具有更强的约束）。

   规章制度制定总体的灾备恢复要求，以及预案的启动，以及负责人，以及流程。比如我们要明确成员：灾备恢复领导小组（行长级别的），管理小组（信息科技，保卫，业务等方面的中层），执行小组（以IT为主，其他为辅）。我们还要明确每小组的职责，和每个人的任务。成员的名单要根据组织的变动不断刷新，比如北京，上海的数据中心的负责人，比如中间件，网络，业务的负责人，比如对外联络EMC, GDS,IBM等公司的联络人，和运营商，电力公司的联系人等，都要及时刷新保持最新。经常遇到在演练的时候，找到一个，不好意思，我调走了，或者离职了，这是不可接受的。还有相关权限的获取，流程审批的指导等。

   规章制度还要定义明白，业务要恢复什么程度，多长时间能恢复，RPO,RTO大家都很明白了，无需多言，总之要有明确的量化指标，不可随意更改。

   指导手册要有灾备恢复的具体技术指导。这个一般不能第一次就能确定最优的操作，要多次演练，或者参考别的银行或者公司的经验，厂商一般有一些原厂材料或者案例推荐（比如EMC,万国数据，飞康等），值得学习。指导手册一个重要的信息，就是现有系统的信息，以及灾备系统的信息。比如生产中心的拓扑，数据库的列表，主机的操作系统和软件配置等，IP地址列表，硬件信息，软件所在位置槽位等。现有系统的信息一定要准确和分门别类，比如案网络、操作系统、数据库、应用、动力等分类，也可以按业务进行分类，比如资金清算、信贷、信用卡等业务进行业务分类。现有系统的信息要有专人维护，并定期巡检。信息的变更要走流程，并报信息科技主管备案。当然灾备中心或者目标库的信息也一定要维护和刷新，根据不同公司的灾备恢复模式而变。

   指导手册的灾备恢复的技术指导就不用说了，要指明相关脚本位置，图形界面的操作方式，或者命令行的命令的指导等。相关的脚本位置，软件版本要严格指明，对于关键的动态参数，要有解释。现在一些厂家的灾备恢复做的已经足够简化了。但是如果是一个系统的完整搬迁，涉及不同的厂家和不同层面的系统。还要指明目标系统、网络的开启和重建，SAN的挂载，应用系统的重配等需要更复杂的工作。还要有营业系统的测试用例等。

   对于电信运营商，要选择话务的峰谷时间段，比如凌晨1点到3点。银行，业务一直是繁忙的，要选择一个相对事务较少的时刻。最开始可以先尝试的实验数据较少的生产库，之后，再整体切换上百个数据库的系统。演练或者真是恢复，一定要做好网页或者重点客户的通知，防止对重要业务的干扰，造成不必要的损失。曾经了解过，某运营商，机场选择在业务繁忙时间恢复演练的时候失败，导致整片区域都瘫痪的事件。灾备管理部门要结合业务部门预测好业务高峰期，以及突发时间等，更新容灾恢复的时间窗。

  还有对外宣传的指导详细流程，比如不成功会怎么样，成功会怎么样，都要有预案。

第三，容灾演练一定要各种场合都要考虑到。

  我们要有预案分类。比如网络断了怎么办，动力断了怎么办，数据库宕了怎么办，都要有完善的预案措施，平时技术团队没事的时候多研究，出事得时候就少花时间恢复。这个我国要向美国学习，7000多种预案，不是盖得。当然我们也没必要搞那么复杂。

  具体来说，数据损坏了怎么办，从备份硬盘恢复。主机系统损坏怎么办，HACMP,BCV?一般来说，同城容灾和异地容灾我们都应该演练一下。比如北京同城150公里，比如上次北京暴雨发大水，导致电力传输系统损坏，导致生产中心断掉。我们可以利用关闭掉光纤通路，或者关闭掉生产中心和灾备中心的连接来模拟。我们可以利用SRDF来恢复。观察清算系统的运转，恢复花了多少时间等。还有异地灾备恢复等。要考虑异地灾备中心负责人对北京数据中心的了解情况。谈到这里，各种规章制度，和技术指导手册最好要分角色来撰写，要充分考虑到负责人员得技术和系统的领悟能力，不要假设他什么都知道。

  从系统故障来首，我们应该测试和演练网络故障，主机故障，磁盘阵列故障，应用系统故障等（比如操作人员误操作），SAN网络故障等。我们要结合规章制度，以及现有情况，决定恢复的时间点和系统等，优先要保证最高优先级的系统的恢复。容灾恢复演练从来都不是仅仅是数据库的事情，而是全套系统的事情，而且涉及到很多操作系统和硬件平台。

  其实容灾演练的功夫在平时做好是最省事的。比如我们在架构设计的时候，为生产中心和同城容灾中心准备充足的带宽，比如FCoIP，带宽可以达到数百兆的速率，对于连接的交换机和存储系统主机最好采用双机冗余，互为备份。让生产中心和容灾中心之间的数据尽量做好同步，对于远距离的系统，采取存储层面的磁盘镜像比较合适，异步镜像就可以了。而且注意采取可以无需主机处理的交换机和存储技术，让平时的数据同步可以较少的占用系统的资源。在容灾系统上，SAN是当之无愧的选择。

三. 不同级别灾备恢复技术的选择

  我们一般会根据标准上不同的安全级别标准选择不同的灾难恢复技术。总共有7层

  0层 无异地备份。

  数据在本地备份恢复，无异地保存，没有灾难恢复计划。就是兄弟们熟练使用的各种全备，部分备份，增量备份等，这些备份都保存在本地。在生产中心被毁的时候，无法恢复数据。这是最惨的一种。恢复时间不可预测。

  这个是一般的小型企业，数据没那么关键的时候，可以选择。

  1层 有数据备份，无备用系统。

  将数据备份到磁带，然后护送到其他安全地方。这种层次，如果备份频率高，丢失的数据的少。如果备份的间隔较长，则数据丢失的时间较长。而且无专用备用中心，需要我们在目标机房重建相关系统，再将数据导入。这种是电信行业在1999年，2000年左右采用较多的灾备方式。但是，我在一些区域银行的数据中心迁移的时候，也见过这种方式：），在目标机房重建系统，然后通过存储层磁盘镜像将核心数据恢复。但是这种级别恢复时间可以预测。

  2层 有数据备份，有备用系统

  数据备份到磁带，运送到专门灾备中心。灾备中心有备用系统，可预测恢复时间。灾备中心有硬件和网络设备来安装系统。但是这种方式还需要我们将磁带运送到灾备中心。恢复时间比1层要短得多。

  3层 电子链接（Electric Vaulting，我个人感觉翻译的不是太好）

   在2层之上的优化是，将磁带上更改的数据通过电子链接记录，并通过数据链路传送到灾备中心，灾难发生后，只有少量数据需要重新恢复，恢复时间比以前都要短。前提是灾备中心要保持运转，生产中心和灾备中心的数据链路要保持畅通。比如某银行系统，下班之后将日志传送到灾备中心，灾备中心的数据进行replay，保持和生产中心重做。
  我们熟知的很多解决方案都在3层。在存储层，有IBM-ESS-PPRC,IBM-DS4000-RM,EMC-SRDF，还有HP，netapp的解决方案。操作系统层面有IBM的GEORM, veritas的storage replication/volume replicator等，在数据库层面大家都很了解了，DB2的HADR，informix的HDR（HADR前身），oracle的DG等。在应用层有Q复制等。


  4层 快照拷贝数据

   此层已经开始使用磁盘的方案。通过加快备份，最近时间点的快照恢复，一天内可以恢复。4层灾备恢复有两个中心同时active，并管理彼此备份数据。备份是双向的。备份数据接收方和生产中心在地理位置上分离。工作负载可以共同分担，互为备份。在线关键数据拷贝不停传送，应用的恢复可以在几小时内完成。IBM的HAGEO和veritias-global cluster mannger可以支持。

  5层 交易完整性

  生辰中心和灾备中心数据要一致。只允许少量数据丢失。除了4层技术，还要保证更新数据都要写入生辰中心数据库和灾备中心数据库，才算完成交易。生产中心和灾备中心用高速链路连接，关键的数据和应用一般在两个site运行，以防运行中生产中心down，这样只有正在进行的交易丢失。恢复时间相当的短，在5层较多的使用大家耳熟能详的数据复制功能，比如DB2的HADR，和oracle的replication。

  目前国内的大银行一般都能达到5级灾备标准

  6层 少量或无数据丢失

  生产和灾备中心的数据拥有最高的同步级别。这个适用于不允许数据丢失并能快速恢复的业务。依赖大量硬件技术和OS软件实现。从应用级别到硬件级别都要采取灾备措施。应用程序采用事务 transaction的方法开发，数据库采用db2的HADR，informix的HDR,oracle的DG。操作系统采用集群软件，如HACMP，veritas的global cluster manager。硬件层采取同步数据复制，IBM的PPRC，RM，EMC的SRDF，或者其他异步数据复制技术。

  7层 方案和业务结合，自主管理

   在6层得基础上，增加应用自动恢复能力，在数据一致的基础上，使得系统和应用恢复时间更短。在这一层，数据0丢失，是最高级别的灾难恢复。需要双重在线存储和冗余的网络接口。本级别对成本要求非常的高。


  随着2城3中心的建设，我国的四大行和主要商业银行在容灾恢复上一般都能达到5级的标准，少部分关键数据库可以达到6级标准。区域银行根据自己的能力一般在4级灾备上，也有达到5级得。国内的国有银行，商业银行，大部分的区域银行大部分都进行了容灾恢复演练。国家要求每年至少一次，香港要求每周六都要容灾演练一次。