讲真，灾备的内涵其实很丰富

讲真，灾备的内涵其实很丰富
深证云 今天

如果你愿意一层一层一层地剥开它的心，

你会发现，你会讶异，

灾备的内涵其实很丰富。

譬如下面这些问题，你能说出个123吗？

Question

灾备全称是什么？跟容灾一样吗？

CDP、HA、双活是什么？

与应用级灾备的区别在哪？

BCP、DRP、BCM又是什么？

它们之间的联系与区别呢？

灾备是服务还是产品

今天，我们就来咬文嚼字地说说这些问题，

剖开问题一探究竟。

01

灾备，英文全称Backup and Disaster Recovery，中文意思为灾难恢复和备份。也就是说灾备包括灾难恢复和备份两部分。先来说备份，因为备份是前提，是基础。按百度百科的解释，备份是指为应付文件、数据丢失或损坏等可能出现的意外情况，将电子计算机存储设备中的数据复制到磁带等大容量存储设备中。维基百科上英文的解释为：Backup refers to the copying and archiving of computer data so it may be used to restore the original after a data loss event.

解惑

中文和英文都提到了复制以及备份的原因和目的，不同的是在英文还提到了archiving归档技术。这也是复制和备份的主要区别，数据复制是实时将源端数据同步到目标端，源端和目标端拥有相同的数据版本。而备份的数据，可以归档，生成很多数据版本。当源端数据丢失时，可以用备份数据进行恢复。

如果实时备份，就是CDP (持续数据保护)，能精确到秒级，恢复至灾难前的任何一秒。听着很牛逼，数据几乎零丢失。但是，问题来了：

1）备份的数据是离线的、静态的，数据是否可用存在不确定性，当数据恢复时，没有信心保证应用可以正常启动和运行。

2）数据恢复取决于带宽和磁盘I/O性能，过程不可控。因为灾难发生后，网络可能中断，机房受损，异地的备份数据也无法及时恢复。

所以当前主流灾备方案是建立应用级灾备。

02

有人说，我们是双活了，而且是高可用双活，还需要建立应用级灾备吗？

好，先聊聊双活，打开双活来看看里面具体是什么。双活，是一个很宽泛的概念。广义上讲，双活是两个或多个数据中心，每个都具有独立运行生产应用所需要的所有资源。通过全局负载均衡将请求动态分配到不同的数据中心。当其中一个数据中心故障时，另外一个数据中心接管所有的应用请求。但实际上，在建设双活时，通常是指同城双活数据中心，目的是想充分利用灾备数据中心的价值。

具体的双活方案包括不同的层面：有的是数据库双活，如RAC、DB2 GDPC；有的是网络双活，如大二层打通；有的是存储双活，炒作比较多的方案，存储双活并不代表应用双活；有的是应用双活，在证券行业应用双活主要指读写分离；有的是业务双活或异地多活，但在证券行业无案例。

异地多活涉及应用开发，在互联网应用的某些核心功能模块上有一些异地多活的方案。业务级双活还没有成功案例，因为还在讨论“多活能不能战胜挖掘机”。证券行业双活多指同城双活，因为有距离要求。

而高可用(High Available)，似乎成了一个“修饰词”。只要是业务不中为断，或者中断时间在业务接受范围之内，都可以说高可用XXX。99%的高可用性意味着一年宕机时间不超过4天；99.9%的高可用性即为一年宕机时间不超过10小时；而99.99%的高可用性表示一年宕机时间不超过1小时；高可用性达99.999% 即一年宕机时间不超过6分钟。

所以下次别人讲双活时，一定要多问一句，是哪个层面的双活。每个层面的双活，都有不同的方案。现在的问题是缺乏整体的解决方案，在伟大的集成商出来之前，只好先从局部做起。

在金融行业也一样，双活多指同城双活。同城双活建设和运维成本较高，而且无法应对区域性重大灾难。所以在要求稳定、安全、合规的金融行业，建立应用级异地灾备是基本要求，也是比较经济的解决方案。

03

应用级灾备可以及时验证数据和系统的准确性、可用性。当执行灾难恢复时，不存在数据恢复步骤，直接切换，完成应用接管。这一套应用切换和应用接管流程就是常说的灾难恢复预案（属于应急预案范畴）。

应急预案指面对突发事件如自然灾害、重特大事故、环境公害及人为破坏的应急管理、指挥、救援计划等。它一般应建立在综合防灾规划上。其几大重要子系统包括：完善的应急组织管理指挥系统；强有力的应急工程救援保障体系；综合协调、应对自如的相互支持系统；充分备灾的保障供应体系；体现综合救援的应急队伍等。

灾难恢复预案是BCP（业务连续性计划）的重要组成部分。业务连续性计划是企业从业务运营角度，按照业务流程规范和管理要求，为不同级别的灾难，从人(部门)、技术(灾备)和流程(预案)三方面综合设计各项流程和不同级别的应急响应，使企业在突发事件面前能够迅速作出反应，确保关键业务功能可以持续，而不造成业务中断或业务流程本质的改变。

所以除灾难恢复预案外，BCP还包括：业务影响分析、非财务风险分析、灾难恢复策略和应急响应等内容。而DRP (灾难恢复计划)聚集技术方案、IT基础资源恢复和运营恢复，是在BCP之后的。

为什么灾难恢复预案属于BCP，而不是DRP呢？

因为BCP是面向业务，BCP的计划和制定需要业务部门参与。而具体的灾难恢复实施DRP由IT部门主导和执行。

有一个形象的比喻来说明DRP和BCP的区别：天塌了，考虑在天塌了的状态下做什么，怎么开展业务就是BCP；天塌了，考虑怎么把天撑回去，就是DRP。DRP+BCP+供应链管理+危机管理等就是BCM (业务连续性管理)。

关于BCM涉及很多内容，三言两语讲不清，本篇就不赘述了。有一点需要说明的是，BCM理念在国外比较普及，上至国家、下至企业和公民都很重视，如经历911之后的西方和位于太平洋地震带的日本和印尼。国内近半世纪以来都在稳定、繁荣、和平地发展，特别是一二线城市，以致BCM意识普遍还比较薄弱。

04

回到灾备基本概念，灾备是灾难恢复和备份。备份容易给人感觉是数据备份，停留在数据视角，灾备的最原始阶段，没有体现业务连续性的思想。而现在，灾备正在朝应用级方向发展。

因为客户需要的是一体化的灾备方案，不再是单纯的产品或技术组合，而是综合、多元化、集成的灾备服务，即DRaaS（灾备即服务）。结合云计算，可以让客户按需求配置各种灾备服务。只有通过各种灾备服务，才能保障灾备中心的可用性、切换的可行性。

灾备服务的内容包括：灾备建设前的规划——实施——灾备运维。从生命周期来看，灾备运维的时间占到了灾备中心生命周期的80%以上。灾备运维是一个泛称，具体的运维内容跟灾备中心级别有关，如下表所示：

灾备中心基础设施

灾备基础运维是灾备运维的基础，是保障灾备中心基础设施稳定运行的核心要素，也是金融业务得以安全稳定运行的根本。基础运维的核心是安全运维，需要在长期的基础运维过程中不断积累安全运维经验。

05

谈了这么多，似乎还没有提到容灾。容灾（Disaster Tolerance），顾名思义，容忍灾难，指发生灾难时，应用软件在数据尽量少丢失的情况下，能够继续保持不间断运行。容灾体现的是信息系统的灾难应对能力。

那灾备和容灾是同一个概念吗？答案是略有不同，相同在两者都包括灾难恢复和备份，不同在于容灾的能力可以体现在软件设计和开发层面，而灾备重点考虑灾难发生之后怎么应对，即what to do and how to do。