1. 恢复站点
1.1. 恢复站点是一个真实或虚拟的地点，用来在计算环境遭到灾难时取代该环境
1.2. 当年的恢复站点总是由另一个数据中心充当，而且那个数据中心最好离你们目前的这个比较远
1.3. 现在一般都不采用实体的数据中心了，而且这个恢复站点一般也不会由你们的组织所拥有
1.4. 选定恢复站点的类型之后，你需要决定自己如何（或者是否需要）把计算环境预先恢复到这个恢复站点里，以便在遇到灾难时让恢复站点立刻上线，取代主站
2. 自建恢复站点
2.1. 最原始的DR计划就是自己来创建并维护DR中心
2.2. 采购并维护一个（或一套）跟主数据中心完全不同的数据中心，并为其配备充足的存储、计算与网络资源，以取代主数据中心
2.3. 自己维护恢复站点是一个相当昂贵的做法，因为这（至少）会让计算环境的总成本翻倍
2.4. 适用于想把灾难恢复流程的各个方面全掌控在自己手里，并不惜为此花费重金的组织
2.5. 由自己来维护的恢复站点，很容易变得无人打理
3. 恢复站点即服务
3.1. 除了自己来维护这些做灾难恢复所需的硬件之外，你还可以付钱请某个公司来帮你采购并维护
3.2. 向服务提供商购买恢复站点的一种形式，是让对方专门为你提供那种用来应对灾难的设备
3.3. 会比自己采购并维护恢复站点贵一些，因为你们还得给这个为你们采购并维护设备的机构付钱
3.4. 工作就是确保恢复站点成功（也就是在主站遇到灾难时，有效地取代主站）
- 3.4.1. 能够降低由你们自己来维护恢复站点所面临的风险
3.5. 用比较低的价格跟其他客户共用那些应对灾难的设备，你们所需支付的费用与共享程度有关
3.5.1. 如果不出现许多组织都在同一时间需要设备的情况，那么这种方式还是很好的
3.5.2. 共用设备或许是一种应对勒索攻击的好办法，但这仅限于共用者里只有一个组织受影响的情况
4. 天生就适合用来做DR的公用云
4.1. 公用云提供了充足的设备，不太会出现客户需要做灾难恢复时找不到设备的情况，而且平常几乎没有开销，只有到了你宣布自己需要做灾难恢复时，才开始产生开销
4.2. 只想在自己确实使用到这些资源时才去付费，而且最好是只按下某个按钮，就能获取到用不完的资源
4.3. 就算某个地域全都遭到自然灾害侵袭，你也还是能够做DR，因为你只需要恢复到另一个区域
4.4. 你可以在灾害发生之前很久就开始做恢复工作，同时只需要支付存储方面的费用，等到真正遭遇灾害时，再为其他方面的资源付费
- 4.4.1. 只有等到你真正开始用那1PB数据做灾难恢复时，你才需要开设1000台虚拟机并为其付费
4.5. 这些方式的费用都要比你把副本保存在传统的数据中心里便宜
4.6. 对你复制的这些数据做快照，并把这种所谓的快照保存在云端的主存储区里，它的价格是普通数据的一半
4.7. 如果你不想让这个盘的性能受这种原因影响而降低，那可以提前决定专门拿一个盘来为恢复做准备，等真正需要恢复时，立刻用那个盘来做恢复，这样可以缩短恢复所需的时间
- 4.7.1. 缺点是成本会高一些
5. 让DR站与主站同步
5.1. 必须决定要不要在灾难还没发生时就提前准备恢复系统
5.2. 如果你们的RTO比较长（也就是说，你们对恢复时间的要求比较宽松），那就未必需要做预先恢复
5.3. 冷站
5.3.1. 如果你只是提前设立恢复站点，但直到遭遇灾害时才开始启动恢复流程，那么这样的恢复站点就是冷站(cold site)
5.3.2. 冷站的成本要比温站与热站低得多，但它所支持的恢复手法远少于后两者
-
5.3.3. 冷站之所以“冷”，是因为其中的设备基本上处在关机状态，只有到了你真正需要用它做恢复时才开机，在这之前，它是不会针对恢复执行任何工作的
- 5.3.3.1. 遇到灾难时，你需要开启实体机或虚拟机，并开始执行恢复
5.3.4. 在还没有出现勒索软件的年代，许多组织都是采用冷站来做DR的
5.3.5. 如果你们的RTO与RPO比较宽松，或者你们的关键数据比较少，那可以考虑选用冷站
5.4. 热站与温站
5.4.1. 如果你为提前恢复做了一些准备，那么你的恢复站点就是温站(warm site)或热站(hot site)，具体选用哪一种站取决于你的RPA
-
5.4.2. 温站上的数据，与你们的组织目前所使用的这套数据近乎同步，但每次同步之后也总是会关机，直到你下次同步或需要做灾难恢复时再开机
5.4.2.1. 温站里的数据可能落后主站几个小时，乃至几天甚至更久，最远可以落后多久取决于你们的需求
-
5.4.2.2. 遇到灾难之后
5.4.2.2.1. 第一是接受这个某部分数据已经受损的结果
5.4.2.2.2. 第二是采用其他一些备份，把数据恢复到与主站一样的状态
5.4.2.3. 温站对大多数组织而言都是一种成本与速度相平衡的方案
5.4.2.4. 在做完恢复之后通过增量备份把数据恢复到离故障点更近的某个点，那么温站就更加值得考虑了
-
5.4.3. 热站总是处于开机状态，并且能够随时取代主站，它跟主站中的数据集尽可能保持同步
5.4.3.1. 最贵的，但它所提供的RTA与RPA也是最短的，短到几乎接近于0
5.4.3.2. 只需要几秒钟时间就能让热站取代主站，而且几乎不会丢失任何数据
5.4.3.3. 如果RPO与RTO是0，那只能选热站
5.4.3.4. 如果你们的RPO与RTO不是0，那么选用热站就是在浪费资源
-
5.4.4. 如果选温站或热站，那必须确保你能够随时访问到所有的设备
- 5.4.4.1. 早前提到的恢复站点即服务(Recovery-Site-as-a Service, RSaaS)通常并不具备这种能力，因此你只能在自建恢复站点与使用公用云之间选择
6. 恢复机制
6.1. 任何一种灾难恢复计划都不能靠一箱磁带来实现
6.2. 任何一种灾难恢复系统，都需要通过网络把主数据集复制到恢复站上
6.2.1. 一种是把主数据复制到恢复站
6.2.2. 另一种是把备份数据复制到恢复站
6.3. 把主数据复制到恢复站
6.3.1. 会把主数据集所发生的每个变化都复制到恢复站的数据集
6.3.2. 可以在文件层面或数据库层面实现，但通常都是在存储层面实现的
-
6.3.3. 同步复制系统会先确保有待写入的数据已经复制到了恢复站，然后才告诉原应用程序，该数据已经写入磁盘，以保证每份数据都同时保存在两个地方
6.3.3.1. 主站与恢复站之间就总是能完全同步
6.3.3.2. 如果你要设立的恢复站是热站，那么必须做同步复制，而且要有足够的带宽并尽量降低延迟
-
6.3.4. 异步复制系统首先把主站发生的变化记录下来，然后按这些变化的发生顺序将其更新到恢复站
6.3.4.1. 过程是异步的，因此恢复站可能落后于主站
6.3.4.2. 落后的时间取决于带宽、延迟，以及变更的数量，有些情况下可能会落后很久
-
6.3.5. 基于阵列的复制(array-based replication)
6.3.5.1. 将其中一个阵列中的数据复制到另一个阵列
6.3.5.2. 基于阵列的复制是一个相当简单而可靠的方式，能够确保恢复站中的数据与主站完全一样
6.3.5.3. 必须选择同一厂商的产品，因此你的选择范围比较窄
6.3.5.4. 由于存储硬件与复制软件都由同一家厂商提供，因此你无法采用比较实惠的产品组合来实现该方案
6.3.5.5. 基于阵列的复制依然是一种相当稳健的手法，能够确保同一份数据会同时保存在主站与恢复站里
-
6.3.6. 基于主机的复制(host-based replication)
6.3.6.1. 一种跟基于阵列的复制相对的手法，它比较灵活
6.3.6.2. 复制在一台或多台主机中执行，每台主机自行复制其数据
-
6.3.6.3. 最早出现的一种是基于软件的卷管理器
6.3.6.3.1. 能够意识到工作环境里有哪些机器是虚拟机，并且了解每台虚拟机中有哪些数据需要复制
6.3.6.4. 基于主机的复制要比基于阵列的复制灵活得多，因为它并不关心你在这两边用的是什么存储设备，它复制的是数据，而不是数据所在的存储设备
6.3.6.5. 可以根据自己对性能与价格的要求，混用不同厂商的产品
-
6.3.7. 利用存储虚拟化硬件(storage virtualization hardware)来复制
6.3.7.1. 硬件位于服务器与存储设备之间，它会对存储设备做虚拟化，并将其呈现给主机
6.3.7.2. 产品通常并不是由磁盘阵列或主机的厂商所提供的（但有时也会由它们提供），你可以通过此类产品，在不同的存储系统之间复制数据
6.3.7.3. 比较灵活，让你能够选用不同厂商的设备来实现
-
6.3.7.4. 缺点在于，它可能不为主机或存储设备的厂商所支持
6.3.7.4.1. 必须从制作存储虚拟化产品的公司那里获得支援
6.3.7.4.2. 将来要是出了问题，可能导致你们的组织与这种产品的厂商之间互相指责
6.4. 把备份数据复制到恢复站
-
6.4.1. 把备份数据复制到恢复站是一种较新的方式
- 6.4.1.1. 真正开始流行是最近10年间的事，其流行原因在于，每种备份环境几乎都会装配某个用来去除重复数据的硬件或软件
-
6.4.2. 如果不做去重，那么需要复制的数据量就实在太大了
6.4.2.1. 即便增量备份也相当大，这种备份通常是完全备份的10%
-
6.4.2.2. 对于每周做一次完全备份且每天做一次增量备份的典型备份计划来说，需要复制的数据量大约是原数据的200%（100%+(10%×7)=170%）
6.4.2.2.1. 需要占用大量带宽
6.4.2.3. 去重之后的完全备份与增量备份，其数据量与去重之前的完全备份相比，通常小于后者的1%
6.4.2.4. 意味着我们可以把每周需要复制的备份数据，从原数据的200%左右降到7%甚至更低。这真是天差地别
-
6.4.3. 你复制的这些备份数据，将来是需要用来恢复的
6.4.3.1. 备份下来的主数据（例如某台虚拟机或某个数据库）在复制到恢复站时通常需要放在某种类型的容器里
6.4.3.2. 必须把数据从这个容器中提取出来，才能将其用于恢复
-
6.4.3.3. 并非所有的备份软件都会把备份数据放到tar这样的容器里
6.4.3.3.1. 必须把备份数据还原到备份之前的格式
6.4.3.4. 备份软件与备份服务处理这个问题的办法，是在你们还没有开始测试或尚未遭遇灾难之前，先对有待保护的虚拟机与服务器自动做例行的提前恢复
-
6.4.4. 平台格式问题
-
6.4.4.1. 操作系统
6.4.4.1.1. Windows或Linux
6.4.4.1.2. Solaris、AIX、HP-UX等系统
6.4.4.1.3. 大型机上的系统以及其他一些专有的系统
-
6.4.4.2. 如果你们的虚拟机管理器有云端版本，那也是比较简单的
6.4.4.2.1. VMware、Hyper-V与KVM都有基于云端的版本
6.4.4.2.2. 把常用的虚拟机管理器恢复到云端版本的同一种虚拟机管理器里，能够简化工作流程并缩短实际恢复时间(RTA)与实际恢复点(RPA)
6.4.4.2.3. 恢复到常见的hyperscaler里的虚拟数据中心，其成本通常要比恢复到规模相似的传统虚拟机管理器低
6.4.4.2.4. hyperscaler提供虚拟机数据中心的历史，要比云平台给传统的虚拟机管理器提供云端版本的历史长得多
6.4.4.2.5. hyperscaler中的每个虚拟机，其成本都低于云端版本的虚拟机管理器里的相应虚拟机
-
6.4.4.3. 每一种流行的虚拟化平台都有自己的磁盘格式，而你们使用的虚拟机管理器同样有它自己的磁盘格式，这两种格式可能完全不同
6.4.4.3.1. 转换
6.4.4.3.1.1. conversion
6.4.4.3.1.2. 如果做转换，那你要把整个虚拟机的镜像都交给某种转换工具处理一遍
6.4.4.3.1.3. 工具本身就是用来将虚拟机导入AWS的，这意味着它很擅长将本地的V M镜像转换成一种能够运行于AWS的镜像
6.4.4.3.1.4. 它经过了长期验证，而且它使用的是由hyperscaler提供的标准工具
6.4.4.3.1.5. 缺点在于耗时太久
-
6.4.4.3.1.5.1. 速度本来就不是这种工具的设计目标，它注重的是完备与可靠
6.4.4.3.1.5.1.1. 工具是为了让你把虚拟机导入AWS，我们在做这种工作时通常并不着急
6.4.4.3.1.5.2. 必须将整个虚拟机都处理一遍
6.4.4.3.1.5.2.1. 虚拟机越大，转换所花的时间就越长
> 6.4.4.3.2. 变换
> 6.4.4.3.2.1. transformation
> 6.4.4.3.2.2. 变换是由数据保护厂商做的，它会就地变换文件，而不会把整个磁盘镜像都交给刚才说的那种转换流程去处理一遍
> 6.4.4.3.2.3. 所做的可能是给镜像加一层包装，打开镜像并给其中插入驱动程序，然后对文件执行一系列操作，让这个磁盘镜像能够与指定的hyperscaler兼容
> 6.4.4.3.2.4. 好处在于它相对来说比较快，每个磁盘镜像只需要几分钟就能做好
6.4.4.3.2.4.1. 换工具本身就是为了迅速完成工作而设计的
6.4.4.3.2.4.2. 并不需要把整个磁盘镜像都过一遍，因此，对磁盘镜像执行变换所需的时长与该镜像的大小无关
6.4.4.3.2.4.2.1. 不需要复制或移动数据，只是就地对数据执行一些表面上的处理而已
> 6.4.4.3.2.5. 变换的过程是由每个备份厂商自己安排的，它不会由hyperscaler提供，于是你当然就无法为此寻求hyperscaler的支援了
