1.1.         DR（灾难恢复）对于大多数组织来说并不是一个可做可不做的选项，它是一个必须得到满足的需求

1.2.         认为自身受到灾害袭击的概率比较小

1.2.1.           如果是在自然灾害或恐怖袭击频发的地区，那么这种概率肯定会稍高一些

1.2.2.           许多组织都认为它们的运气足够好，不太可能遇到那种事故

1.3.         数据中心可能会让飓风摧毁

1.3.1.           在这种情况下，你实在没什么选择的余地，你只能把所有东西都重建一遍，这样才能恢复

1.3.2.           无论你花多少钱都无法改变基本的物理规律，而且总是需要由好几百个承包商通过各种渠道准备相关的材料，这样才能把数据中心重新建立好

1.3.3.           速度提得稍微快一点，但再怎么快都无法仅用两三天时间就把办公楼跟数据中心建好

1.4.         Disaster Recovery，灾难恢复；又称灾备

2.1.         勒索攻击是最近几年才出现的，然而它很快成为许多组织开始认真制定灾难恢复计划的头号原因

2.2.         必须把应对勒索攻击放在首位

2.2.1.           一种RTO足够短的计划，这样就可以在遇到勒索攻击时从容应对了

2.3.         如果你们没针对目前有可能出现的勒索攻击，制定出RTA（实际恢复时间，也就是让系统从灾难中复原所花的时间）较短的灾难恢复计划，那么在遭遇勒索攻击之后，你就会面临一种状况

2.3.1.           这种状况与那种遭遇自然灾害之后所面临的状况不同

2.3.2.           遇到这种攻击时，你必须尽快做出处理，每下线一天，你们的组织就要损失一天的钱

2.4.         你们的组织会遇到一个让人相当着急的问题，也就是要不要支付赎金

2.4.1.           如果决定不支付，那你们就可以把服务器全都清空，然后从头开始恢复

2.4.1.1.            根据备份与恢复系统的效率，这可能要花费几天到几个星期的时间

2.4.2.           如果你决定支付赎金，那可能会拿到一个密钥，让你能够用这个密钥来解密数据

2.4.3.           大多数组织在这种情况下都决定支付赎金，因为它们觉得这样处理起来比较快，而且花的钱要比不支付赎金少

2.5.         请别支付赎金

2.5.1.           许多组织都是因为这个而多次遭受勒索的

2.5.2.           对你们的品牌也产生长期影响，因为这意味着你们没有把客户数据适当地保护好

2.5.3.           可能因违反GDPR（通用数据保护条例）而遭到罚款，因为这表示你们没有按照这个条例的要求做好数据保护工作

2.5.4.           支付赎金并不能保证数据一定会得到恢复

3.1.         DR（灾难恢复）计划是一个流程，如果你们的计算环境里有很大一部分设施都无法运作了，那么你就需要启动该流程

3.2.         很有可能是要恢复整个数据中心或整个计算环境

3.2.1.           它可能会跨越多个数据中心或云平台

3.3.         启动DR计划的时机与地点，实际上取决于你所要保护的是什么类型的资源

3.3.1.           需要保护的可能是数据中心、IaaS/PaaS资源，也可能是你们的任何一款SaaS应用里所保存的数据

3.4.         数据中心

3.4.1.           如果你需要恢复的是数据中心，那可能是因为它遇到了火灾、水灾或其他自然灾害，也有可能是因为遭受了恐怖攻击

3.5.         IaaS/PaaS

3.5.1.           如果你们的组织用的是公用云（很可能是这样），那么你同样有可能会因为其中的资源丢失而启动灾备计划

3.5.2.           云不是万能的，使用云平台并不会减少其中的计算资源遭遇灾难的风险

3.5.3.           危机预防(anticipate failure)

3.5.4.           容错设计(design for failure)

3.6.         SaaS

3.7.         业务持续计划

3.7.1.           业务持续计划（Business Continuity Planning，简称BCP或BC计划）是一个相当大的流程，用来确保整个组织在遭遇灾难等重大事故之后，能够继续开展其业务

3.7.2.           COVID-19是一个让它们的BC计划必须经受考验的契机

4.1.         DR计划假设你必须从头开始做起

4.2.         问题

4.2.1.           你的计算资源、存储资源与网络资源从哪里获得？

4.2.2.           你打算如何保护你的替代环境？

4.2.3.           你们的恢复需求是什么？

4.2.3.1.            RPO（目标恢复点）与RTO（目标恢复时间）必须提前约定好

4.2.4.           按照什么样的顺序恢复？

4.2.5.           是不是必须先恢复某些部分，然后才能恢复其余部分？

4.2.6.           应该提前确定恢复顺序，并按照那样的顺序去恢复

4.2.7.           人员怎么安排？

4.2.8.           文档准备好了吗？

4.2.8.1.            DR计划的说明书（也就是DR手册）有没有充分地说明，某个不熟悉操作的技术人员能否在无人协助的前提下执行该计划

4.2.8.2.            DR计划里还应该有一套审核流程，以确保这份文档总是能及时得到更新审核流程

4.2.9.           DR手册里有多少东西是能够自动实施的？

4.2.9.1.            自动化是DR计划成功的关键因素

4.2.10.      DR计划经过测试了吗？

4.2.10.1.        不对备份系统与DR系统做测试，就容易在遇到灾难时手足无措

4.2.10.2.        要想保证DR计划有效，就必须经常做测试，以便及时了解其中有哪些地方做得还不到位，别等到必须真正执行恢复时，才发现平常根本就没有做过测试

4.3.         单凭一箱磁带是做不了DR计划的

4.3.1.           多年以来，大多数组织的DR计划都打算用一箱保管在离站地点的磁带来实现

4.3.2.           磁带从来都不是一种擅长做DR的东西，而且现在真的不适合这样做

4.3.3.           在做灾难恢复的过程中，这种单线程的恢复工作是磁带最不擅长的一种工作

4.3.4.           在大规模的灾难恢复过程中，你必须同时恢复十几或几百个服务器或虚拟机，而每一个这样的服务器或虚拟机，都需要用一种单线程的方式（也就是同一时间只能做一件事的方式）来恢复，而且这个恢复流程的进度还有可能因为写入数据的那种存储介质速度较慢而遭到拖延

4.4.         把备份复制到去重设备上也好不到哪里去

4.4.1.           真正的问题并非去重设备不好，而是在于恢复本身

4.4.2.           如果你的DR计划是在发生灾难之后才开始从某种备份系统里恢复原来的整个系统，那么你们在RTO（目标恢复时间）上可能就无法满足应对勒索攻击所需的水平，从而更有可能选择支付赎金

4.4.3.           问题其实出在如何将数据中的重复内容填补回来

4.4.4.           最好的DR计划是在灾难没有发生时就预先准备着恢复

4.5.         一切都是为了RTA

4.5.1.           要想抵住勒索攻击，关键就是你们要在还没遭受勒索时就先搞清楚本组织能够忍受的下线时间与数据损失量

4.5.1.1.            如果大家还没有对涉及这种大事件时的RTO与RPO达成一致，那现在就赶紧定下来