欢迎关注原创公众号：
容灾（Disaster Tolerance）：就是在上述的灾难发生时，在保证生产系统的数据尽量少丢失的情况下，保持生存系统的业务不间断地运行。
容错（Fault Tolerance）：指在计算机系统的软件、硬件发生故障时，保证计算机系统中仍能工作的能力。
区别：容错可以通过硬件冗余、错误检查和热交换再加上特殊的软件来实现，而容灾必须通过系统冗余、灾难检测和系统迁移等技术来实现。当设备故障不能通过容错机制解决而导致系统宕机时，这种故障的解决就属于容灾的范畴。
什么是灾难恢复（Disaster Recovery）：指的是在灾难发生后，将系统恢复到正常运作的能力。
区别：容灾强调的是在灾难发生时，保证系统业务持续不间断地运行的能力，而灾难恢复强调的灾难之后，系统的恢复能力。现在的容灾系统都包含着灾难恢复的功能，所以本文的讨论除了包括容灾方面的内容，还包括了灾难恢复的部分内容。
x.1 BCM、RPO、RTO与灾备等级
灾备及应急管理体系的建设首先需要明确一个概念两个指标，即业务连续性管理BCM以及恢复点目标（RPO）和恢复时间目标（RTO）。
● BCM
业务连续性管理（Business Continuity Management，简称BCM），是一项综合管理流程，它使企业认识到潜在的危机和相关影响，制订响应、业务和连续性的恢复计划，其总体目标是为了提高企业的风险防范能力，以有效地响应非计划的业务破坏并降低不良影响。业务连续性管理(BCM)是每一个希望基业长青企业都需要考虑的战略问题。企业的核心系统已成为生产工具和核心资产，特别是核心系统中断以及数据问题对企业的影响愈发严重，故其应该纳入BCM管理范畴。BCM聚焦三个关键点：业务、连续性以及管理，即通过一些列度的管理方式、技术工具、流程制度等保障业务连续不中断。从实际上来说，包括应用系统及数据层面的不中断和业务层面的不中断，其二者的区别在于系统及数据层面的不中断是为业务不中断进行服务的，侧重于技术侧，如应用级别的灾备、数据级别的灾备等，业务层面的不中断还包括业务侧的备份应急措施。同时业务关键点倾向于价值较高的业务活动，而非所有，这也是降低成本，提高TCO的必要措施。
BCM涉及的整体工作范围应包括：
图：业务连续性管理
（1）基于CMDB分类分级中高价值的业务系统及数据（实际上“价值”也是CMDB分类分级的重要依据）；
（2）BCM聚焦于重大性、紧急突发性以影响全局性的事件，同时基于是事件的不同等级和属性，确定启动时间及方案；
（3）BCM包括事前、事中、事后三个阶段涵盖事件（灾难性时间）管理的全生命周期的PDCA闭环管理。事前侧重于风险识别、风险控制、灾备方案制定及实施、灾备流程机制制定、组织架构、培训以及应急演练等；事中包括灾备处理流程机制、业务恢复方案实时以及请示汇报等；事后包括的UI灾备应急处理的流程制度、处理方案以及组织机制等进行复盘分析，优化现有机制，提高同类问题的处理效率和成功率。
可能性中高 | 可能性中低 | 基本不可能 |
恐怖事件（炸弹威胁，爆炸，挟持人员等） | 气候灾难（暴风雪，严寒等） | 核战/战争 |
建筑物倒塌 | 城市事件（罢工，动乱等） | |
人为过失/故意破坏（对公司不满的员工，外部黑客，计算机病毒等） | 工作场所的环境紧急事件（化学污染等） | |
气候灾难（台风，洪水等） | 地震 | |
设备/硬件/系统故障 | 流行疾病 | |
业务应用软件故障 | 社会性恐慌 | |
火灾 | ||
基础设施故障（网络，通信，电力，空调，通风等） |
灾难种类 | 影响损失 | 影响范围 | 可能的业务中断或业务损失 | 抵御的方法 |
地震 | 高 | 高 | 数据中心全部业务中断，数据大量丢失 | 异地灾备站点 |
火灾 | 高 | 中 | 数据中心业务中断 | 远程灾备站点备份应用系统和冗余网络接入 |
停电 | 中 | 中 | 数据中心业务中断 | 冗余电源供应（UPS或者多电源接入） |
数据库崩溃 | 低 | 低 | 数据中心业务中断 | 数据库镜像技术，或者数据库备份中取回数据 |
部分硬件故障 | 中 | 低 | 数据中心部分业务中断 | 增加硬件冗余度，使用集群技术和数据复制技术等等 |
…… | …… | …… | …… | …… |
图：BCMS核心框架
ISO22301 BCMS的核心框架（图1）是一个双循环结构，外循环用于建立、实施和运行、监视和评审、保持和改进一个特定的管理体系，内循环则用于建立、实施、运行、监视、评审、保持和改进业务连续性。这两个循环结构，外循环是面向管理体系的；内循环是为了得到业务连续性能力，之所以把业务连续性管理（BCM，即内循环涉及的管理过程）外面套上一个管理体系，是为了让管理业务连续性的工作可控、可评估和可持续改进。
综上所述，业务连续性是一种组织能力，业务连续性管理（BCM）是实施和保持业务连续性的一整套管理过程，业务连续性管理体系（BCMS）是用于管理(即建立、实施和运行、监视和评审、保持和改进)业务连续性的一个特定的管理体系；换言之，业务连续性管理（BCM）和业务连续性管理体系（BCMS）都是用于管理业务连续性的方法。
（4）BCM平台统合灾备及应急体系的全流程、全周期的管理，包括组织机制及权限管控、灾备项目管理及实施跟进、灾备响应机制、应急处理方案等，同时监控平台也属于BCM平台的一部分，已达到提前发现、主动识别灾备事件的目的，进而提高问题处理的效率和准确率。
● RPO与RTO
衡量一个灾备系统建设优秀与否，或是否符合等级保护要求的两大关键指标是恢复时间目标（RTO）、恢复点目标（RPO）。恢复时间目标（RTO）∶Recovery Time Objective，即恢复时间目标，指的是用户业务系统所能容忍的业务停止服务的最长时间；恢复点目标（RPO）∶Recovery Point Objective，即数据恢复点目标，指的是业务系统所能容忍的数据丢失量。
图：RPO与RTO时间
恢复时间目标（RTO）指当业务发生中断后，从业务发生中断时开始，到将业务恢复到正常所需要的时间，此两点之间的时间段称为RTO。如业务在下午15点的时候发生故障，启动灾备处理措施，业务在18点恢复至可接受的级别，那么这之间的3小时则为RTO实际发生事件，实际上如果规定RTO的时间为2小时，则应在17点的时候恢复业务。RTO是反映业务恢复的及时性指标，表示业务从中断到恢复正常所需的时间，RTO数值越小，代表容灾系统的恢复能力越强。可以部署多站点容灾方案等等来获取最小的RTO，越小的RTO可能意味着容灾方案可能需要投入越多的资金。
RPO恢复点目标是指可接受的数据丢失的最大数据量，也就是容忍丢失的最大数据量。RPO表示为从丢失事件到最近一次备份的时间度量。以备份为例，一般备份都是一天做一次，通常是在凌晨业务空闲期，例如凌晨2点做了备份，如果白天出现系统故障或数据错误且无法修复，那从备份完成后到错误出现时所写入的数据都无法挽回了，这期间没有备份，数据就丢失了，一天备份这种情况下RPO就是24小时，实际上上述凌晨2点备份，如果10点出现故障，则实际RPO时间为8小时。如每天20点备份数据，在第二天20点前发现数据异常且无法修复，只能恢复前一天20点的备份数据，RPO就是24小时。如果定义了RPO为5小时，我们原则上则需要每5小时要进行一次备份。同时为了减少RPO，一味的增加备份的频率是不现实的，同时也是不可靠的（影响系统及数据本身的性能），需要根据业务实际的情况，结合相应的同步/异步/备份等技术，制定适合业务实际的方案。
RTO和RPO指标并不是孤立的，而是从不同角度来反映的容灾能力。RPO指标来自于故障发生前，而RTO指标来自故障发生后，两者的数值越小，就能有效缩短业务正常到业务过渡期的时间间隔，单一地提升RTO或RPO指标也可以缩减业务故障到过渡期的时间，具体从哪个指标上来改善，就要结合的实际情况分析，提升那个指标代价最小，效果更明显。当然完美的方案当然是RTO和RPO都为零，这表示当故障发生后，系统立即恢复，而且完全没有数据丢失，要达到这样的目标系统设计是及其复杂的，而且造价也是非常昂贵的，也不一定有这个必要。企业通常根据当业务不可用时对业务的实际影响（即前文所述的“价值”）来定义可接受的RTO和RPO,然后信息部门（一般需要联合业务部门一起）根据RTO、RPO的要求设计灾难恢复方案，在规划时同时要考虑方案的实现成本。可用性越高，RTO、RPO的值越低，可能实现成本就越高。
● 灾备等级
关于灾备等级的划分，可以参考两个标准，一个是国际标准Share 78,另一个是国家标准《信息系统灾难恢复规范》
Share78 容灾国际标准（也称SHARE 78 定义的七级业务恢复级别）分级原则：
（1）备份/恢复的范围
（2）灾难恢复计划的状态
（3）应用地点与备份地点之间的距离
（4）应用地点与备份地点如何相互连接
（5）数据是怎样在两个地点之间传送的
（6）允许有多少数据丢失
（7）怎样保证备份地点数据的更新
（8）备份地点可以开始备份工作的能力
根据上述8条原则，国际标准Share 78对容灾系统的定义有七个层次：从最简单的仅在本地进行磁带备份，到将备份的磁带存储在异地，再到建立应用系统实时切换的异地备份系统，恢复时间也可以从几天到小时级到分钟级、秒级或零数据丢失等。目前针对这七个层次，都有相应的容灾方案，所以，用户在选择容灾方案时应重点区分它们各自的特点和适用范围，结合自己对容灾系统的要求判断选择哪个层次的方案。
Share78 | |
灾备等级 | 具体内容 |
Tier 0 无异地备份 (No off-site Data) | 0等级容灾方案数据仅在本地进行备份，无异地备份数据，无灾难恢复计划。该方式是成本最低，但不具备真正灾难恢复能力。 |
Tier 1 实现异地备份 -PTAM 卡车运送访问方式 (Pickup Truck Access Method) | 第1级容灾方案是将关键数据备份到本地磁带介质上，然后送往异地保存，但异地没有可用的备份中心、备份数据处理系统和备份网络通信系统，未制定灾难恢复计划。灾难发生后，使用新的主机，利用异地数据备份介质（磁带）将数据恢复起来。 |
Tier 2 热备份站点备份-PTAM 卡车运送访问方式+热备份中心 (PTAM + Hot中心) | 第2级容灾方案是将关键数据进行备份并存放到异地，制定有相应灾难恢复计划，具有热备份能力的站点灾难恢复。一旦发生灾难，利用热备份主机系统将数据恢复。它与第1级容灾方案的区别在于异地有一个热备份站点，该站点有主机系统，平时利用异地的备份管理软件将运送到异地的数据备份介质上的数据备份到主机系统。当灾难发生时可以快速接管应用，恢复生产。 |
Tier 3 在线数据恢复 -电子链接 (Electronic Vaulting) | 第3级容灾方案是通过网络将关键数据进行备份并存放至异地，制定有相应灾难恢复计划，有备份中心，并配备部分数据处理系统及网络通信系统。该等级方案特点是用电子数据传输取代交通工具传输备份数据，从而提高了灾难恢复的速度。利用异地的备份管理软件将通过网络传送到异地的数据备份到主机系统。一旦灾难发生，需要的关键数据通过网络可迅速恢复，通过网络切换，关键应用恢复时间可降低到一天或小时级。这一等级方案由于备份站点要保持持续运行，对网络的要求较高，因此成本相应有所增加。 |
Tier 4 定时数据备份-活动状态的备份中心 (Active Secondary中心) | 第4级容灾方案是在第3级容灾方案的基础上，利用备份管理软件自动通过通信网络将部分关键数据定时备份至异地，并制定相应的灾难恢复计划。一旦灾难发生，利用备份中心已有资源及异地备份数据恢复关键业务系统运行。这一等级方案特点是备份数据是采用自动化的备份管理软件备份到异地，异地热备中心保存的数据是定时备份的数据，根据备份策略的不同，数据的丢失与恢复时间达到天或小时级。由于对备份管理软件设备和网络设备的要求较高，因此投入成本也会增加。但由于该级别备份的特点，业务恢复时间和数据的丢失量还不能满足关键行业对关键数据容灾的要求。 |
Tier 5 实时数据备份-Two-Site Two-Phase Commit | 第5级容灾方案在前面几个级别的基础上使用了硬件的镜像技术和软件的数据复制技术，也就是说，可以实现在应用站点与备份站点的数据都被更新。数据在两个站点之间相互镜像，由远程异步提交来同步，因为关键应用使用了双重在线存储，所以在灾难发生时，仅仅很小部分的数据被丢失，恢复的时间被降低到了分钟级或秒级。由于对存储系统和数据复制软件的要求较高，所需成本也大大增加。 |
Tier 6 零数据丢失 (Zero Data Loss) | 第6级容灾方案是灾难恢复中最昂贵的方式，也是速度最快的恢复方式，它是灾难恢复的最高级别，利用专用的存储网络将关键数据同步镜像至备份中心，数据不仅在本地进行确认，而且需要在异地（备份）进行确认。因为，数据是镜像地写到两个站点，所以灾难发生时异地容灾系统保留了全部的数据，实现零数据丢失。这一方案在本地和远程的所有数据被更新的同时，利用了双重在线存储和完全的网络切换能力，不仅保证数据的完全一致性，而且存储和网络等环境具备了应用的自动切换能力。一旦发生灾难，备份站点不仅有全部的数据，而且应用可以自动接管，实现零数据丢失的备份。通常在这两个系统中的光纤设备连接中还提供冗余通道，以备工作通道出现故障时及时接替工作，当然由于对存储系统和存储系统专用网络的要求很高，用户的投资巨大。采取这种容灾方式的用户主要是资金实力较为雄厚的大型企业和电信级企业。但在实际应用过程中，由于完全同步的方式对生产系统的运行效率会产生很大影响，所以适用于生产交易较少或非实时交易的关键数据系统，目前采用该级别容灾方案的用户还很少。 |
表：Share78灾备等级
实际上对于国内大部分国企事业单位以及大中型国企，多参考国家标准《信息系统灾难恢复规范》
《信息系统灾难恢复规范》 (GBT20988-2007) | ||||||
等级 | 第1级 | 第2级 | 第3级 | 第4级 | 第5级 | 第6级 |
基本支持 | 备用场地支持 | 电子传输和部分设备支持 | 电子传输及完整设备支持 | 实时数据传输及完整设备支持 | 数据零丢失和远程集群支持 | |
数据备份系统 | a) 完全数据备份至少每周一次； | a) 完全数据备份至少每周一次； | a) 完全数据备份至少每天一次； | a) 完全数据备份至少每天一次； | a) 完全数据备份至少每天一次； | a) 完全数据备份至少每天一次； |
备用数据处理系统 | — | 配备灾难恢复所需的部分数据处理设备，或灾难发生后能在 | 配备灾难恢复所需的部分数据处理设备。 | 配备灾难恢复所需的全部数据处理设备，并处于就绪状态或 | 配备灾难恢复所需的全部数据处理设备，并处于就绪或运行 | a) 备用数据处理系统具备与生产数据处理系统一致的处理 |
备用网络系统 | — | 配备部分通信线路和相应的网络设备，或灾难发生后能在预 | 配备部分通信线路和相应的网络设备。 | a) 配备灾难恢复所需的通信线路； | a) 配备灾难恢复所需的通信线路； | a) 配备与主系统相同等级的通信线路和网络设备； |
备用基础设施 | 有符合介质存放条件的场地 | a) 有符合介质存放条件的场地； | a) 有符合介质存放条件的场地； | a) 有符合介质存放条件的场地； | a) 有符合介质存放条件的场地； | a) 有符合介质存放条件的场地； |
专业技术支持能力 | — | — | 在灾难备份中心有专职的计算机机房运行管理人员。 | 在灾难备份中心有： | 在灾难备份中心7x24小时有专职的： | 在灾难备份中心7x24小时有专职的： |
运行维护管理能力 | a) 有介质存取、验证和转储管理制度； | a) 有介质存取、验证和转储管理制度； | a) 按介质特性对备份数据进行定期的有效性验证； | a) 有介质存取、验证和转储管理制度； | a) 有介质存取、验证和转储管理制度； | a) 有介质存取、验证和转储管理制度； |
灾难恢复预案 | 有相应的经过完整测试和演练的灾难恢复预案 | 有相应的经过完整测试和演练的灾难恢复预案。 | 有相应的经过完整测试和演练的灾难恢复预案。 | 有相应的经过完整测试和演练的灾难恢复预案。 | 有相应的经过完整测试和演练的灾难恢复预案。 | 有相应的经过完整测试和演练的灾难恢复预案。 |
RTO(某企业) | 2天以上 | 24小时以上 | 12小时以上 | 数小时至2天 | 数分钟至2天 | 数分钟 |
RPO(某企业) | 1天至7天 | 1天至7天 | 数小时至1天 | 数小时至1天 | 0至30分钟 | 0 |
表：GBT20988-2007灾备等级
容灾分类分级通用的划分方式还有如下：数据级、应用级和业务级。不同级别的容灾，实现的方案和达成的效果各不相同。数据级，是最底级，要保证数据副本可用，应用级主要是在应用程序层实现高可用，业务级需要通过访问接入控制等实现多活。
（1）数据级说明
数据级容灾在容灾的级别中，属于最基础层，一般通过建立一个异地容灾数据中心，使用各类备份技术，将主数据中心的数据进行远程备份，备份至灾备数据中心中。在数据级的备份有多种方式，如通过存储设备本身的远程存储复制功能，以及最基本的常规网络备份功能。在数据级容灾的级别下，单数据中心在灾难发生之后，其他数据中心的数据不会丢失或者遭到破坏，能够继续使用。数据级容灾实现的备份内容仅是文件，由于只考虑到了数据，所以这种方式费用比较低，构建实施相对简单。但是数据级容灾，有一定的缺陷，就是灾难发生时，应用还是会中断，业务访问使用会受影响，实际上数据级的容灾就是简单的远程的数据备份中心，不具备应用热备份和应用高可用的功能，这个时候出现灾难性问题就需要重新构建应用，因此数据级容灾的恢复时间比较长。
（2）应用级说明
应用级容灾是在数据级容灾的基础之上的，想要实现应用级容灾，必须依靠数据级容灾。所谓应用级容灾，就是要实现应用系统的高可用，既然是高可用，就需要有多套一样业务系统，相互协同进行对外提供服务，达成这样的效果话，就需要在灾备数据中心建立一套与主数据中心完全相同的应用系统。在存在多套相同系统的前提下，依靠数据级容灾实现数据的同步，同步方式有同步和异步两种方式，需要根据系统的实际情况进行设置。通常通过文件系统层面的数据同步程序实现远程复制，还有就是通过跨数据中心建立存储集群的副本卷，通过策略，保障不同副本卷数据落盘在不同的数据中心中，来配合应用实现容灾效果。这样可以保证关键应用在允许的时间范围内恢复运行，尽可能减少灾难带来的损失，省去了应用重建的时间，让用户基本感受不到灾难的发生。应用级容灾简单来说就是建立一个应用的备份系统，相比数据级容灾，它提供的服务是完整、可靠、安全的，确保了业务的连续性。但是在投入上需要的费用较高，需要更多的软件来实现，并且需要时时刻刻在灾备数据中心做好业务切换的准备。
（3）业务级说明
业务级容灾是全业务的灾备，它的前提是数据容灾和应用容灾，需要在这两者的基础上投入更多的硬件基础设施来实现。相比应用容灾，业务容灾需要保障在出现某机房故障的时候，用户可以无感知。因此需要保障业务的连续性，即应用实现双活或者多活，并且实现用户接入的高可用，接入高可用一般情况下通过智能DNS和负载均衡设备等实现，以实现智能检测和访问调度功能。业务级容灾完全保障了业务访问的连续性，但是费用很高，包括了软件、硬件、互联网线路等，还需要场所费用的投入，实施难度大。
图：灾备等级RTO与TCO关系
x.2 灾备管理体系
灾备管理体系的建设以运维基础数据CMDB为基础、按照分类分级思想建设不同等级应用系统及数据的灾备，主要内容包括：灾备技术方案、灾备分级建设以及恢复评价等内容。
灾备管理体系的建设要基于企业应用系统及数据的规模、重要性和架构，同时兼顾投入的经济成本和人力成本，确保所建设的企业灾备方案和体系在保障应用系统及数据稳定、安全的前提下，实现最佳投入产出比，实现经济效益的最大化。整个灾备体系方案设计围绕运维CMDB为基础，结合业务需求和系统属性，明确灾备对象、界定灾备建设的范围，同时依助技术架构、管理机制和组织保障完善灾备体系化建设，在确保安全、稳定的前提下实现灾备建设的最佳投入产出比。
图：灾备建设体系
x.2.1 灾备技术方案
（1）基础设施灾备
从基础设施层面，灾备建设方式有经典的两地三中心、多活数据中心和云灾备等几种形式：两地三中心的架构为公司所在地同城自建或是租赁两个数据中心机房，这两个机房之间以光纤打通，应用系统、文件及数据以实时同步的方式实现两个机房的实时热备、同城双活中心，同时在另一个300公里外的城市租赁或是自建机房，作为双活中心的异地灾备中心。异地机房跟同城的两个机房多采用延迟同步或是手动同步的方式存储IT系统、文件和数据等。一般异地机房是用作同城机房的系统冷备和备份集存储，原则上不与同城数据中心的数据实时同步，甚至每次同步采用主动模式，先建立连接、进行同步、完成后断开连接的方式，其目的在于避免同城机房数据、文件被删除、篡改、恶意加密或中勒索病毒等情况的发生导致异地机房实时同步数据也不可用的情况。异地灾备中心比较经济的方案是在异地租赁IDC机房及服务器，存储同城机房的备份集和核心系统的冷备。另外根据公司数据的保密程度有选择的采用云端服务器进行备份集存储或是系统冷热备。
多活数据中心为在双活中心基础上的扩展，通过网络专线的方式根据公司业务分布情况选择主干城市作为中心节点建设或租赁数据中心，并且与主机房进行二层网络打通实现应用系统及数据的实时多向同步，借助GSLB全局负载均衡技术，为公司系统用户提供就近区域方案、最佳运营商链路接入的方式，提高用户体验的同时，最大化规避单点故障的产生。多活数据中心作用于大型集团企业的核心业务系统，建设成本较高，特别是存储级别的实时同步，对网络带宽延迟要求高、网络投入大，另外设计3中心及以上应用、系统层面高可用实现较为复杂，有的情况需要业务系统进行改造以支持分布式事务的处理。多活数据中心解决了单点故障，但是不能解决勒索、数据删除、篡改等问题，故延迟状态下灾备中心仍需要进行设置。
云灾备借助于云平台资源池和云下、云上网络互通，实现应用系统及数据的高可用部署和备份存储，是目前经济价值较高的一种灾备方式，借助于云平台的快速便捷性可以快速构建起企业灾备中心，同时即需即供的云模式省去线下数据中心的建设、上架调试环节，实施难度和复杂度也大大降低。但是云灾备多基于应用和数据层面，存储级别的灾备造价较高（专线及1:1的存储），需要采用云平台独占模式，其难以充分发挥云平台的优势。
综合考虑，针对大中型的集团公司，基于两地三中心+云灾备的模式相对比较适合，云灾备中心与灾备中心同为异地灾备，但基于云的高效便利性，建议云灾备中心与双活数据中心建立单向或双向实时同步的方式，最大化提高云灾备中心的利用率。灾备中心的建设则原则上以延迟备份为主，同时建议灾备中心在保存备份集合的时候拉起最近一次的备份以节省备份恢复时间和恢复效率。
运营商介入方面遵循三网接入、负载均衡的机制，规避单一运营商的问题，同时提高不同运营商的最佳网络线路，提高访问性能。
（2）硬件高可用及备件
双活数据中心或主数据中心在硬件设计及实施上采用高可用或主备设计，具体表现在网络层面的双核心双链路架构、存储层面的存储双活或主备同步以及网络安全设备在整个网络链路上的旁路设计。
基于硬件设施设备的备件管理是在灾备管理的另一个重点，包括备份核心交换机、物理服务、边界防火墙等整体备机以及光模块、硬盘、主板、CPU、交换机背板等元器件内容。备件管理既不能出现大量的硬件过剩导致资源利用率低又不能过于紧张导致难以应对突发情况，所以基于备件资产管理要从备件类型、备件梳理、生产使用时长等多个维度综合考虑，一般可建议如下：
1-3年的硬件设备相关备件保留1-3件即可，如1-3年的核心交换机，可保留1块板卡备用，1-3年的物理机可保留2个CPU、3块硬盘等。数量上略微冗余，在满足一次故障处理的同时，仍有少了可在使用即可；3-5年的硬件设备相关备件保留5件左右；5年以上的硬件设备应该建立退出生产机制，如果仍持续使用，应有可随时替换的备机，备机包括同等或高于当前配置，并且相关策略预配置好。
由于备份集在生成、传输和存储过程中具有占用较大的带宽及存储、且使用频率低等特点，为不影响生产系统的正常使用，强烈建议设置专用的备份网络及备份存储。规划专有网络链路用于备份传输，在操作系统层面指定专用网卡用作备份或数据同步用。备份存储方面采用不同性能规格的存储按照备份集时间远近、数据冷热进行存储，近期、重要的备份集存储在高性能的存储介质中，归档备份集存储在NAS或磁带库中，基于生产系统及数据量进行压缩后计算备份存储容量，提前做好备份容量规划，整体上以求达到投产最佳比。
（3）应用及数据高可用与备份
基于两地三中心和云灾备中心的基础设施设计，应用系统及数据采用分布式高可用架构部署，实现应用级数据层面的多中心同步。高可用的架构分为集群和主备两种方式：集群中的各个节点均对外提供服务，提高了系统整体的吞吐量可实现更高的并发；主备模式为主节点对外提供服务、备节点作为主节点的备用，处于备用状态，主备模式未能实现吞吐和并发的翻倍扩容，但是可实现读写分离的功能，也是常用的高可用方案之一。集群或主备节点在部署时，应选择同一数据中心不同机柜、不同数据中心的方式部署。
相比存储级别的数据同步，应用系统及数据的高可用架构可以更加灵活、更细粒度的实现灾备需求，且应用系统和数据层面的高可用可以为性能带来提升，便于弹性伸缩。但存储级别的数据同步架构相对简单，控制粒度粗，只需要关注存储层面数据块同步即可，上层应用则依赖虚拟化层面的HA对网络专线依赖很高，而应用系统及数据的高可用则涉及内容较多，技术管理上存在一定的复杂度。
以应用、数据库和文件的高可用介绍，具体如下：
应用、数据库和文件总体来说采用集群或是主备方式部署，避免单点故障。另外负载均衡和反向代理的使用也可以减轻单节点的访问压力和提高内网服务器的安全。
● 应用高可用
很多企业可能直接把应用服务器如tomcat，weblogic等直接映射到外网ip,这样如果需要部署多台的话，需要做多个公网ip的映射，并且难以实现访问的负载均衡，由于出现故障需要手动切换，故不能算是实现了高可用。
采用反向代理服务器的方式如nginx,haproxy既可以实现反向代理，也可以实现负载均衡，并且可以节省公司的公网IP资源。每一组应用至少部署两台不同的虚拟机上，避免应用的单点故障。资源比较紧张的情况下，可以实现交叉部署，例如应用A1和应用A2部署在虚拟机VM1和VM2上，应用B2和应用B1也部署在与A1，A2相同的虚拟机上，统一虚拟机多应用，每个应用又在其他虚拟机有部署，避免单点故障还节省资源。但是要注意，一般业务量比较均衡的不同应用可以交叉部署，业务量比较大且核心系统还是要分开部署的。
● 数据库高可用
不管是Oracle还是Mysql或是Sqlserver都有较多且已在不同公司的生产正常运行的高可用和集群方案，这里简单介绍一下Oracle、Mysql和Redis。
Oracle高可用
Oracle比较常见的高可用方案主要是RAC+DG。其中RAC可以实现负载均衡和单点故障。一般部署方式RAC的两个节点挂载同一存储，存储方面存在单点故障的可能。由于RAC主要是做负载均衡，不太好实现读写分离。可以采用搭建RAC的DataGuard实现RAC的数据实时同步到standby数据库中。另外standby可以对外提供只读操作，实现读写分离，减少主库RAC的压力。另外OGG即Oracle GoldenGate是Oracle做数据同步的另一主要解决方案。OGG也可以实现异构跨平台的数据同步。
Mysql高可用
Mysql的高可用方案也比较多，比较常见的有主从复制，MHA，MMM等。另外不同的Mysql厂商也提供了不同的基于Mysql的集群Cluster方案且都有生产实施案例，如GaleraCluster、Percona的PXC和MySQL官方的Cluster等都可以实现mysql的高可用集群和读写分离。另外mysql也有众多的中间件如mycat,oneproxy等可以很容易的实现读写分离和分库分表、分布式等方案。
Redis高可用
一般IT系统架构使用Redis主要两大用途：共享session存储和缓存数据。Redis的高可用架构一般主要两种：哨兵模式的主从和cluster集群。
上图为redis的哨兵模式，通过哨兵监控，实现故障后自动推举master。Redis Cluster是Redis3.0以后推出的，截止目前生产应用的也已经比较多。
● 文件高可用
在系统架构中，一般文件服务器作为单独的服务进行部署，主要存放文件、图片、app应用上传的附件等。有的时候也把静态资源放到文件服务器中。有的公司会选择自建文件服务器，也有的会选择云服务，如阿里云的OSS等。我所在的公司主要考虑到数据和文件的保密性，采取了自建文件服务器的方式，主要采用了FastDFS这一开源框架进行搭建。
采用三台服务器交叉部署三组Tracker+Storage，为公司所有IT系统提供静态资源（主要包括文件、图片）读写服务。
● 其他中间件高可用
序号 | 类型 | 产品 | 当前部署方式 |
1 | 反向代理 | Nginx | Nginx+Keepalived集群部署 配置双向同步 |
2 | LVS | Nginx+Keepalived集群部署 配置双向同步 | |
4 | MQ | RocketMQ | 集群 |
5 | Kafka | 集群 | |
6 | 缓存 | Redis | 主备，哨兵模式 |
7 | 搜索 | ES | 主备/集群 |
8 | DB | MyCAT | 集群 |
9 | ShardingSphere | 集群 | |
11 | 文件 | FastDFS | 3节点集群 |
12 | MongoDB | 集群 | |
13 | 配置中心 | Zookeeper | 3节点集群 |
15 | 定时任务 | XXL-job | 集群 |
16 | LTS | 集群 |
x.2.2 备份管理策略
备份集管理在整个灾备体系建设上至关重要，备份也是灾备建设的底线，从灾备质量效果来看，要求备份集准确、完整且安全，及备份出来的备份集应该存储在安全的位置并且其应该是准确、完整、可用，并且应该有详细的恢复评估，以备随时可用。备份集管理主要在策略方面，备份策略总的大概分为：备份周期、存储位置、恢复策略、验证策略四大部分。
备份对象
备份策略首选要确定备份对象，并且按照备份对象的定级为优先级逐步开展实施。备份对象涵盖应用系统及数据的方方面面，从前端应用到后端数据库，从系统层面的虚拟机备份到服务器上的具体某一个文件，都是待备份的对象。一般来说备份虚拟机和备份应用是有重复的地方，但是多管齐下，做到最可靠，这样的代价就是在结果集存储上会出现重复备存储的情况，一定程度上提高了IT的存储成本。
备份周期
备份周期一般以周为单位，周三和周天全备，其他时间增量备份。全备+增量备份可以节省一部分资源，也提高了恢复的速度。虚拟机层面一般采用虚拟机全备的方式。另外将备份删除策略定在备份周期里。根据系统的重要性和要求，定期删除一些过期的备份集，释放存储资源。
存储位置
备份集的存放本着多处存放的原则。一般在本地服务器存放一份，机房内备份服务器或是NAS存放一份，异地机房存放一份，根据备份集对象数据的保密性，有选择的在云端存放一份。多地存放，降低了备份集丢失的可能性。同时本地服务器存储最近一次备份集，以便出现问题的时候可以快速恢复，省去备份集传输时间，异地灾备机房或云灾备中心在存储最近备份的同时，拉起最近一次备份集做恢复，既可测试备份结果的准确性又节省备份恢复时间。
恢复策略
恢复策略包括恢复方案、恢复脚本以及恢复评估三个主要内容。恢复方案和恢复脚本相结合，确保备份集能够按照预定方案进行准确性、高效性的恢复，恢复评估为对恢复方式的综合评价，包括备份恢复的方法、恢复时间、恢复后数据丢失或影响、备份存储位置及大小、传输速度等多方面内容，基于备份集的恢复评估可供运维人员在进行恢复决策的时候提供依据和预期，是备份管理工作的重要内容之一。
验证策略
有备份，就一定要验证，而且要制定计划、定期验证备份集中的每一个备份的可用性、准确性和完整性，并且通过验证收集恢复评估信息并逐渐完善。制定并实施持续完整的备份验证策略，是保证备份集可用的最佳途径，在验证备份集的时候，要根据恢复策略的脚本和方案进行恢复验证，并且记录验证时间。为后续的真实恢复做好前置准备和恢复预期。
x.2.3 组织架构与流程管理
灾备规划、设计、建设、管理以及切换恢复与业务部门和信息部门都有密切关系，企业层面广义上的灾备除了技术层面的建设还包括业务层面的备用方案手段，灾备设计及建设在实际过程中完全实现与生产环境1:1的映射很难，多有取舍，故在规划、设计和建设时就应该与应用系统及数据关联的业务人员、开发人员、项目经理等充分沟通达成共识，以便对应用系统及数据的灾备效果有共同的认识和预期。所以组织架构设计上可采用“虚拟小组”的方式联系各方干系人和关联部门，灾备的管理工作主要在运维部门，灾备效果以及备份集评估需要运维主动与业务级开发、测试等工程师一同推进，完成效果评估评价工作，同时在这一过程中也加深了对灾备建设的共同认识。灾备恢复的切换启用是灾备管理工作的核心关键点，需要基于灾备及备份的评估评价效果和当前灾难发生情况、影响范围及影响程度以及生产修复难度进行综合评定，既要结合既定预案又要充分考虑当前情况，灾备的启用、备份集的恢复需要虚拟小组共同决定并汇报责任领导，一致决定后，才可进行进一步的操作。从流程管理上，大致可参考如下：
图：灾备处理流程
灾难发生或是故障发生时首先进行汇报和紧急处理，汇报包括汇报至相关领导、业务部门等主要干系人，紧急处理指对当前灾备问题或故障情况进行初步的排查处理，并且结合应急预案进行应急临时处理或是业务层面的备用手段，对于较大、较复杂的问题，还需要及时对灾备中心系统、备份集进行综合评估，确认灾备启用或备份恢复的影响；根据故障处理情况及影响范围、影响情况进行进一步的汇报和联合排故等，并且根据影响范围、时间及影响度和故障处理情况等进行信息汇总以此决定是否启用灾备或是备份进行恢复；灾备环境启用或是备份进行恢复后要立即进行测试并投入使用，同时生产故障继续处理进行恢复，直至生产恢复后切换回至生产环境，灾备进入收尾工作。
灾备的收尾工作是灾备闭环工作的最后一环，其主要体现三个方面：一是切回至生产环境后，灾备环境产生的数据是自动还是手动同步回生产环境；二是灾备环境恢复为初试环境与生产环境进行同步、备份；三是对此次灾备或备份使用情况进行分析、总结，包括灾备启用条件、灾备启用手册及顺序、灾备测试及使用、备份恢复脚本及方案等全流程、全内容，对其中有缺陷地方进行整改、修复。
x.3 灾备建设案例
某公司隶属民航运输业，设有本地数据中心机房，其信息系统较多且与机场、空管站、航信等专线相连，架构相对错综复杂，但核心系统比较重要，原则上不允许中断以免出现公众事件和影响公司经营考核，故灾备建设至关重要，是运维工作的重要一环。
图：灾备建设案例
项目立项后，首先对公司信息系统及数据进行了全面的梳理，结合实际情况大致划分为四类系统：公共基础服务类、运行类系统、商务营销类系统和办公类系统，其中公共基础服务和运行类系统为核心关键系统，为公司航班正常运行提供系统支持和保障，灾备等级建设原则上不得低于国标5级；商务营销类系统主要面向票务销售和旅客服务，相比核心关键系统重要性略低，灾备等级原则上不得低于4级，OTA主要销售渠道系统不得低于5级；办公类系统围绕公司正常运行提供系统保障，灾备等级可进一步降低。不同类别、不同等级的系统，经过摸排梳理和沟通确认后，灾备需求大致如下：
系统类别 | 系统名称 | 系统等级 | 持续可用性指标 | 灾备等级 | RPO | RTO | 建设计划 |
公共基础服务 | 文件服务系统 | 5 | 99.99% | 5 | 30min | 30min | 灾备系统+备份 |
公共基础服务 | 数据缓存系统 | 5 | 99.99% | 5 | 30min | 30min | 灾备系统+备份 |
运行类系统 | 运行控制系统 | 5 | 99.99% | 5 | 15min | 15min | 灾备系统+备份 |
运行类系统 | 机务维修系统 | 5 | 99.99% | 5 | 30min | 30min | 灾备系统+备份 |
运行类系统 | 资质管理系统 | 4 | 99.99% | 4 | 2h | 1h | 灾备系统+备份 |
商务类系统 | 官网销售系统 | 4 | 99.99% | 4 | 2h | 1h | 灾备系统+备份 |
商务类系统 | 旅客管理系统 | 4 | 99.99% | 4 | 2h | 1h | 灾备系统+备份 |
商务类系统 | OTA销售系统 | 5 | 99.99% | 4 | 15min | 15min | 灾备系统+备份 |
商务类系统 | 在线客服系统 | 3 | 99.90% | 4 | 6h | 6h | 备份 |
办公类系统 | OA系统 | 3 | 99% | N/A | 1d | N/A | 备份 |
办公类系统 | 财务系统 | 3 | 99% | N/A | 1d | N/A | 备份 |
办公类系统 | 人事系统 | 3 | 99% | N/A | 1d | N/A | 备份 |
依据此计划开展灾备系统及备份建设工作，要点如下：
（1）灾备中心的建立以先云灾备中心为主，后建设备用机房，确保灾备中心可以快速交付，节省项目实施周期；
（2）应用系统、中间件以及数据库通过高可用集群部署的方式，在云灾备中心建立节点并且与本地主机房通过网络专线实时同步；
（3）应用系统的配置文件改为域名/hosts的方式进行链接，规避IP:端口的方式，以求做到本地主机房和云中心应用配置的便捷管理，云灾备中心应用连接云中心的配置，确保本地主机房故障可以独立运行；
（4）在云灾备中心资源池设置云桌面，以供本地主机房灾难性故障时，可以通过网络连接云桌面进行云上内网系统的操作；
（5）通过专业备份软件、备份脚本对应用、数据库、文件以及虚拟机等进行备份，备份存储在本地备份服务器的同时通过另一条专线与云中心备份资源池连接，存储备份结果集，实现第三方备份存储的监管要求；
（6）在资源池每日恢复最新一次备份集，确保备份集准确、可用，同时节省备份恢复时间；
（7）备用机房建设放在云灾备中心之后，整体计划优先建设核心关键系统的云灾备系统和备份工作，同时为备用机房的推进打下技术基础。备用机房与本地主机房计划通过裸光纤的方式实现存储级同步，降低技术难度和管理复杂度；
（8）建立和完善云灾备中心启用及维护手册，明确灾备中心及备份集恢复的前置条件和代价，同时制定本地主机房恢复后的切回和数据传回及再同步的策略。
整个灾备建设以项目制分批次推进，优先实现核心关键系统的持续可用性目标，并且建立起全系统及数据的备份作业，守住应用及数据的底线。建设进行的同时灾备运维管理工作同步进行，网络专线负载监控、备份存储容量评估以及备份集的评价等一并进行，结合应急演练、应急手册等应急管理机制，通过实战演练的方式全面评价灾备系统和备份的效果，逐步完成灾备工作体系化建设和运转，确保应用系统持续可用的同时，实现最大化的投入产出比例。
