1.1. 自行选购DR软件，意味着你可以把它安装到你自己所管理的服务器上

1.1.1. 服务器可能是实体机

1.1.2. 能是你所拥有的（或你向云平台购买的）虚拟机

1.2. 必须全面负责它们的安保工作

1.2.1. 任何一个安保疏失，都是你的责任

1.2.2. 必须确保硬件、操作系统、存储设备以及DR软件都已经把各种应该安装的补丁给安装过了

1.3. 勒索攻击之所以能够造成破坏，大多数都是因为系统管理员没有安装适当的安全补丁

1.4. 好处主要在于能够控制

1.4.1. 可以采用你们平常制定的那些信息安全原则来维护

1.5. 坏处则体现在成本上

1.5.1. 如果要自己购买并维护足够的基础设施来处理这项工作，那么必须提前准备额外的设备，而且还要考虑到这个过程中可能出现的各种负载较高的情况，并为此预留相应的设备

1.5.2. RTO与RPO越严，你们在这方面的开销就越有可能暴增

1.6. 主流的软件公司已经推出了基于订阅的收费形式

1.6.1. 不用一次就交纳一大笔费用

1.6.2. 其实这只是收费上的区别，并不意味着该方案的优点与缺点会因此而有所变化

2.1. 如果你是用DRaaS（DR-as-a-Service，灾难恢复即服务）式的产品来做DR的，那么一般来说，你只需要在适当的地方安装一个agent

2.2. 其实就是基于SaaS模式的DR服务

2.2.1. 真正的SaaS环境不需要让你去管理系统运作所需的那套基础设施。

2.3. 你不需要以管理员身份登录某个服务器或存储系统，因为这完全是由SaaS厂商负责的

2.4. 如果你还是得以超级用户的身份登录位于某地的某些服务器，那你用的就不是真正的DRaaS产品

2.5. 好处在于，你不用担心如何购买、配置并管理该服务背后的那套计算设施或存储设施了，因为那些都已经由服务提供商替你做了

2.5.1. 确保所有的DR资源都安排到位，完全是DRaaS提供商的责任

2.5.2. 它们会保证你总是有足够的资源做DR，并负责确保这些资源免受攻击

2.6. DRaaS方案会把那种自行管理DR软件的方案所没能做好的地方，全都做好

2.7. 即便采用了该方案，你也可能还是要自己管理恢复站

2.7.1. 你可能还是得负责管理这些用来在发生灾难时取代主计算环境的服务器

2.7.2. 把管理权限赋予这些计算机，让它们自己去管理自己

2.7.3. 采用公用云，这意味着在真正遇到灾难之前，不会出现相关的虚拟机或未经加密的卷

2.8. 缺点

2.8.1. 你无法施加控制

2.8.1.1. 要想把某件事做好，你就自己来吧

2.8.1.2. If you want something done right, you do it yourself.

2.8.2. 它通常需要经由云资源来提供，而在某些人眼里，云总是不如自己的数据中心安全

2.8.3. 某些人总觉得云不够安全，其中的资源更容易遭到网络攻击

2.9. 一般的云提供商所具备的安保水平，都要高于一般的数据中心

2.9.1. 对于大多数组织而言，IT部门本身并不是该组织的目标，它只是为该组织实现其目标提供支持而已

2.9.2. 云端产品则不然，对于许多云端产品来说，它的主要目标就是把IT做好

2.9.3. 如果某个云产品连安全都做不好，那很快就会遭到淘汰

2.9.4. 云端产品这一领域就是要靠安全说话，这也正是认为一般云厂商，乃至一般SaaS厂商，都必定会做好安保的原因

2.9.5. IT人员是专心做安保，而云工作者则是拼了命做安保

3.1. 就SaaS应用而言，目前除了厂商自己所执行的DR之外，还没有真正意义上的这种DR产品

3.2. 当前最好的办法也只能是等SaaS厂商恢复正常之后，再去恢复你的数据

3.3. 购买一件产品来管理所有事务，当然要比分别购买两三件产品来专门管理两三种不同的事务要便宜

3.4. 如果RTO或RPO是0，那你肯定需要购买一款基于主数据复制机制的DR工具

3.4.1. 几乎没有那种既能把RTO或RPO压到0，又能把日常的操作恢复给做好的工具

3.5. 如果这种基于复制机制的DR工具能够把日常的操作恢复给做好，那你就可以考虑让该工具身兼二职，而不用专门购买日常的操作恢复工具了

4.1. 目标是让主计算环境在为某种灾难所摧毁之后，能够尽快上线

4.2. 目标不是购买某个能够做备份的数据复制产品，或某个能够做复制的数据备份产品，也不是为了专门去使用或专门不去使用云平台，而是要让你们的组织在遇到灾难时能够尽快上线

4.3. 开始跟厂商沟通之前，一定要先搞清楚操作恢复与灾难恢复这两个方面的需求

4.4. 编写DR运行手册

4.4.1. DR手册通常以电子书的形式制作

5.1. 需要设计一份DR运行手册，让某个懂IT的人能够依照这份手册，从头到尾执行你的灾难恢复计划

5.1.1. 能否做到这一点，正是判断手册质量是否合格的标准

5.2. 所要实现的目标

5.2.1. 权威(Authoritative)

5.2.1.1. DR运行手册只能有一份

5.2.1.2. 必须是最新版

5.2.2. 精准(Accurate)

5.2.2.1. 根据不正确的信息做灾难恢复，是相当困难的

5.2.3. 易于获取(Accessible)

5.2.3.1. 最容易让大家访问到运行手册的办法就是把它放在网上

5.2.3.2. 电子版的运行手册应该保存在许多地方，本组织内部与云端都要有

5.2.3.3. 这些手册之间的版本要同步，以便让访问者总是能获取到最新版本，这应该是比较容易做到的

5.2.3.4. 打印一份纸质的版本

5.2.4. 易于理解(Absorbed)

5.2.4.1. 每个人都要把这份手册给吃透(everyone needs to grock it)

5.2.5. 及时更新(Active)

5.2.5.1. 这份手册应该持续更新，并纳入你们日常的变更控制流程

5.2.5.2. 通过自动编目机制把这些东西添加到运行手册里

5.2.5.3. 无论通过哪种方式更新手册，都必须确保该方式总是能让手册的内容保持最新

5.2.6. 灵活(Adaptable)

5.2.6.1. DR计划一定要灵活，一定要有备用的办法

5.2.7. 可审计(Auditable)

5.2.7.1. 外界应该能根据你的这份运行手册来验证它是否有效

5.2.8. 可确认(Affirmed)

5.2.8.1. 凡是未经测试的DR手册，都不能称为有效的DR手册

5.2.8.2. 没有做过测试的DR手册仅是一份理论上的手册而已

5.2.8.3. 必须执行常规的DR测试，让工作人员按照这份手册上设计的步骤去做灾难恢复

5.2.8.4. 多执行这样的DR测试，会帮助你把运行手册写得更好

5.2.8.5. 备份做测试是很重要的，而对DR计划做测试则尤为重要

5.2.8.5.1. DR测试做得越频繁，将来真正执行DR时就越容易成功

5.2.8.5.2. 测试时要假设所有深知DR计划的人都无法到场，你们只能通过那些平常不做DR的人来执行灾难恢复

5.2.8.5.3. 必须把不得不请教专家的地方给记录下来，因为这意味着你的手册在这些地方没有讲清楚

5.2.8.5.4. 平常测试得比较充分，而且能够根据测试结果及时更新这份手册以及与之相关的系统，那么到了必须紧急启动DR计划时，你们就不会那么慌张了

5.3. DR流程概述

5.3.1. DR手册的开头应该概述本组织的DR流程

5.3.2. 应该以一份执行纲要(executive summary)开头，这个纲要可以理解为对概述所做的概述

5.4. 技术清单

5.4.1. 灾难恢复过程中用到的每个产品都应该列在“技术清单”部分，而且要写上提供该产品的每个公司的联系信息

5.4.2. 最好能让阅读手册的人知晓相关合同

5.4.3. 一定要知道自己能联系到谁，并了解到这些人应该提供什么样的设备或服务

5.5. 联系信息

5.5.1. 需要把组织里能够参与或指导恢复流程的每一个人都考虑到

5.5.2. 灾难发生之后，时间很紧迫，所以多写几种联系方式是很有帮助的

5.5.3. DR流程的指挥者（或者说高管）也相当重要

5.5.4. 多存几份，放在各种地点

5.5.4.1. 即便有好几个地方同时受灾，你们也还是能通过这样的信息联系到合适的人

5.6. 具体步骤

5.6.1. 重点在于，你写的这套流程是给那种熟悉IT并且知道如何登录与管理系统的人看的

5.6.2. 在你们的组织里，所有做IT的人都应该参与培训，以便在需要执行DR计划时，能够从容地执行该计划

5.7. 上报异常状况

5.7.1. 计划赶不上变化

5.7.1.1. 总会有你计划不到的东西

5.7.2. 如果网络无法按照预先设想的方式予以初始化，那么就应该将其上报给首席网络管理员

5.7.3. 如果联系不到，就应该上报给IT部门的主管

5.7.4. 如果还不行，就应该继续上报给CIO（首席信息官），依次类推

5.7.5. 一定要提前定好，不要让执行DR计划的人到了真正遇见异常状况时，再去想到底应该联系谁

5.7.5.1. 按照手册里预先定好的流程上报即可