读数据保护：工作负载的可恢复性18即时恢复的备份方案

1. 即时恢复的备份方案

1.1. 即时恢复，就是在文件、文件系统、数据库、虚拟机或应用程序遭到损坏之后，无须经历某种恢复流程就可以将其立刻恢复出来

1.2. 适合用在对RTO要求很严的场合

1.3. 最常见的即时恢复方案就是从快照里面恢复，只需要一条命令即可把快照提升为正本

• 1.3.1. 根本不需要把数据从一个地方复制到另一个地方，它只需要调整一下指针，就能把你的文件系统给恢复好

1.4. 不要单用复制或快照来做备份或DR方案，因为单用复制无法从逻辑故障（例如病毒）中恢复，单用快照则无法应对硬件故障

1.5. 如果要做即时恢复，那么应该从CDP、准CDP、CDM以及支持即时恢复的其他当代备份产品里选择

• 1.5.1. 纯粹的CDP产品可以把RTA与RPA压得很低，但这种产品也是相当昂贵的

• 1.5.2. 准CDP、CDM与其他产品在RTA与RPA方面的表现各不相同，它们的成本也不一样

2. 复制

2.1. 复制(replication)是一种使用了好几十年的数据保护方式

• 2.1.1. 必须确定一个你想要保护的卷或文件系统，让它作为源卷(source volume)

• 2.1.2. 源卷可以是某个存储阵列或卷管理器中的某个虚拟磁盘

• 2.1.2.1. 一般通过LUN（Logical Number Unit，逻辑单元号）来指代

• 2.1.2.2. 可以是一个文件系统

• 2.1.3. 目标卷(target volume)，这个卷最好能够处在与源卷不同的某个地点

2.2. 复制系统(replication system)

• 2.2.1. 有的是由存储阵列厂商提供的

• 2.2.2. 有的是由卷管理器厂商提供的

• 2.2.3. 有的是由文件系统厂商提供的

• 2.2.4. 有的来自某种第三方的复制方案

• 2.2.5. 复制系统里把源卷与目标卷配置好，然后在这两个卷之间执行初次同步，让目标卷的内容变得跟源卷看上去完全相同

• 2.2.6. 做过初始同步之后，复制系统就会设法确保源卷里发生的每一个变化都能体现在目标卷上

2.3. 复制技术也可以在文件层面实施，但是那样做的效率要低得多，而且通常也不会有人那么做

• 2.3.1. 在文件层面运用复制技术，只要文件中有任何一个地方发生变化，就必须把整个文件复制过去

2.4. 同步复制系统

• 2.4.1. 好处在于它的保护水平比较高

• 2.4.2. 会把应用程序所要做的改动先同步到目标卷，然后再确认这项改动已经正式生效

• 2.4.2.1. 跟数据库领域的两阶段提交(two-phase commit)很像

• 2.4.2.2. 会把“向源卷写入数据”与“将该数据复制到目标卷”合起来作为一项不可分割的原子操作加以处理

• 2.4.3. 缺点

• 2.4.3.1. 如果目标系统的性能较低，或者有待同步的这些数据所经历的路径较为复杂，那么应用程序可能得等待好长一段时间才能收到ACK信号

• 2.4.3.2. 它会把操作者的失误与受损的数据也百分百地同步过去

2.5. 异步复制系统

• 2.5.1. 非同步的复制系统

• 2.5.2. 好处则是它对受保护的卷所造成的性能影响比较小

• 2.5.2.1. 通常不会从性能上影响受保护的源卷

• 2.5.3. 并不会将发生变化的数据立刻复制过去，而是会先将这些变化纳入一个队列，等到时间与带宽都比较充裕时，再依次将其复制到目标卷

• 2.5.3.1. 应用程序对源卷的每个写入操作都会变成两项操作，其中一项直接在源卷上执行，另一项先发送给复制系统，让该系统把它添加到队列尾部

• 2.5.3.2. 根据带宽与延迟情况，目标卷可能会落后源卷几秒钟乃至几个小时

• 2.5.4. 主要问题

• 2.5.4.1. 复制过程可能拖得比较久，导致目标卷的内容远落后于源卷

• 2.5.4.2. 写入合并（write coalescing，亦称写入聚合）

2.6. 混合复制

2.7. 数据库复制

• 2.7.1. database replication

• 2.7.2. 把某个数据库中的事务自动复制到另一个数据库（也就是自动在另一个数据库上执行一遍）​

• 2.7.3. 与块级别的复制相比，这种复制有一个重要的区别：它是在事务层面执行的，而不是在数据块层面执行的

• 2.7.4. 数据库复制通常采用异步方式执行

2.8. 复制技术的局限

• 2.8.1. 以前，如果要保护某款运行着关键任务的应用程序，那么首选的备份方案可能就是复制

• 2.8.2. 只采用复制做备份方案是有局限的，它不足以保护数据

• 2.8.3. 最大的局限就是常见的复制系统都没有后退按钮

• 2.8.3.1. 如果某人操作失误，例如删掉了一张本来不应该删除的数据表，那么复制系统会把这个失误照搬到目标数据库上

• 2.8.4. 单靠复制，并不能够保护数据库

• 2.8.5. 在复制机制下，源数据与目标数据合起来只能算一个副本，因为如果源数据受损，那么复制机制会把这种损害效果照搬到目标数据上，使得目标数据也随之受损

• 2.8.6. 它会给数据库或支撑数据库的存储设备带来性能上的压力

3. CDP

3.1. 持续数据保护

3.2. 它是一个带有变更日志（后退按钮）的异步复制系统

3.3. CDP是想用一个系统来满足操作恢复（operational recovery，又称运营恢复/运行恢复）与灾难恢复这两方面的要求

• 3.3.1. 能够把数据库恢复到变更日志所涵盖的任何一个时间点，而且几乎立刻就能恢复好，或者至少可以说，它的恢复速度比传统的备份系统快得多

• 3.3.2. CDP系统的用户可以指定变更日志应该保留多久，这项设置决定了他们最远能把受保护的系统恢复到哪一个时刻

3.4. 两类

• 3.4.1. 第一类系统总是会针对有待保护的应用程序、数据库或卷来维护一份随时能够上线的镜像

• 3.4.1.1. 还具备变更日志，因此能够把源数据的状态退回到日志所覆盖的任何一个时间点，而不像普通的异步复制系统那样，只能让源数据回到刚过去的那一刻

• 3.4.1.2. 如果你想把它恢复到从前的某一刻，那可能会稍有延迟

• 3.4.2. 第二类系统并不会针对将来有可能要执行的恢复工作去维护一个随时能够上线的镜像，而是会把目前以及将来恢复时有可能用到的各种数据块全都存储起来，并拿这些数据块构造一个虚拟卷(virtual volume)

• 3.4.2.1. 优点在于，无论你要求它恢复到哪一个时间点，它都能拿自己保存起来的这些数据块，立刻给你呈现一个符合要求的虚拟卷

• 3.4.2.2. 缺点则是：这种虚拟卷的性能，比不上刚才那类CDP系统里的物理卷（physical volume，也就是实体卷）​

3.5. CDP让你能够同时把DR（灾难恢复）与备份做好，而且提供了无数个恢复点供你选择

• 3.5.1. 源系统所执行的每一次写入操作都会记入日志，因此无论你想把源系统恢复到哪一个时间点，日志里都有与之相应的时刻，CDP系统只需要把源系统恢复到那一刻即可满足你的要求

3.6. CDP系统通常当作数据库备份方案出售

3.7. CDP的真正问题在于它所需的资源量

• 3.7.1. 需要执行大量的I/O操作，而且很耗费CPU资源、内存、网络带宽及存储空间

• 3.7.2. CDP软件本身的价格也不便宜

3.8. 如果有一个很关键的数据库需要保护，其RTO与RPO都近于0，那么你有两个办法可选

• 3.8.1. 拿一个传统的备份系统做操作恢复，同时拿一个复制系统做DR

• 3.8.2. 购买一个能够身兼两职的系统

4. 快照

4.1. 专指虚拟快照(virtual snapshot)，对于这种快照来说，大多数的数据都必须依赖你所要保护的那个源卷

• 4.1.1. 快照本身并不是一种良好的备份方案，因为如果快照所依赖的源卷消失了，那么快照也就失效了

4.2. 占用的是比较昂贵的存储空间

4.3. 在制作快照的那一刻，其实根本就没有复制或移动数据

4.4. 写时复制

• 4.4.1. copy-on-write

• 4.4.2. 快照软件会先把旧版的数据块复制并发送到一个特殊区域，然后再用你想要写入的内容把这个数据块更新到新版

• 4.4.3. 在你写入新内容时把旧数据块先复制到别处，所以叫作写时复制

• 4.4.4. 主要优点在于，它不需要我们修改那些针对底层文件系统而设计的代码

• 4.4.5. 缺点在于，它的性能会越来越差

4.5. 写时重定向

• 4.5.1. redirect-on-write

• 4.5.2. 如果你更新某份文件，那就意味着该文件中的一个或多个数据块发生了变化，此时文件系统只需要把新版的数据块写到其他地方，并且让相应的指针指向那些地方

• 4.5.2.1. 将相应指针重定向到那些地方即可

• 4.5.2.2. 实际上相当于拥有了无数个快照，这些快照能够永远保存下去，并且不会影响源卷的性能

• 4.5.3. 缺点则在于，文件系统必须从一开始就针对该方法做出设计

• 4.5.4. NetApp推出了这样一个既能大量制作快照又不会影响性能的方案，因此让这种采用快照来保护数据的做法，变得相当流行

4.6. 暂时拦阻所有的写入操作

• 4.6.1. 根据某个卷制作VMware快照，那么文件系统会把针对该卷的所有写入操作暂时拦截下来，直到快照释放之后，再予以放行

4.7. 快照让你能够访问到某个文件与卷的各个版本，而且只需占用很少的空间，但如果你的源卷频繁发生变化，那么快照可能也会随之迅速膨胀

4.8. 大多数的数据都必须依赖源卷

• 4.8.1. 如果源卷受损，那么快照也就无法正常使用了

• 4.8.2. 单凭快照自身无法满足3-2-1原则

• 4.8.3. 仅制作快照并不足以构建有效的备份系统

5. 准CDP

5.1. 将快照与复制结合起来却可以形成一种相当棒的数据保护系统，这就是准CDP(near-CDP)系统

5.2. 首先对你要保护的主卷制作快照，然后把它复制到另一个地方

5.3. 可以让你拥有源数据的多份副本，并保证其中有一份副本是离站的

5.4. 所谓准CDP系统，是指基于复制机制而构造，并以一种近乎持续但又不完全持续的方式来保护数据的系统

• 5.4.1. 保护数据，意思是让源数据能够退回到从前的某个时间点

5.5. 如果你把源数据所发生的每个变化都复制了下来，那么就算你是以异步方式复制的，就算目标卷的数据状态稍微落后于源卷，你做的也依然是CDP而不是准CDP

5.6. 如果你频繁地制作微型快照（例如每秒钟制作一次）​，并把这些快照之间的差量复制下来，那么你做的是准CDP

5.7. 每个备份系统制作备份的间隔时间差得比较大

5.8. 看看最后能否通过某种技术制作出这样一个备份，让它处在既远离主站，又不跟主站联网的地方

5.9. 许多准CDP方案在应用程序集成方面做得不好

6. CDM

6.1. Copy Data Management，复制数据管理

6.2. CDM的理念是让副本具备包括恢复数据在内的多项功能，并提供一个集中的系统，让副本能够在这里体现出这些功能，同时节省存储与管理方面的成本

6.3. 工作原理通常是做数据切割，把针对某个系统的所有写入操作都以异步方式发给辅助系统，所以这跟针对源卷的异步复制其实是一样的

6.4. CDM与CDP的区别在于：为了让数据副本具备多种用途，并尽量少占据一些存储空间，它必须采用各种专门的技术来确保这一效果

6.5. CDM一般不会把自己标榜成高性能的灾难恢复方案

6.6. 它们主要关注的是如何降低存储成本，并让数据副本满足多种需求，而不是像CDP系统那样专门用来制备数据副本，以便将来能够高效地完成灾难恢复

• 6.6.1. 其优势在于，备份与恢复系统所提供的常见服务它都能提供，除此之外，它所提供的副本还能够用来做测试、开发以及其他一些工作，而且这种副本不一定都得是实体副本

6.7. 并不是专门为了备份而设计的，它是想降低测试、开发与备份所需的副本数量

• 6.7.1. 目标主要集中在测试与开发上，而未必会把备份放在重要地位

6.8. 要求你采用同一个厂商的产品

6.9. 要求你必须全面切换到该系统

7. 让备份发挥更多功效

7.1. 大家都把备份看成一个很耗钱的事情，而且觉得这里面几乎产不出收益

7.2. 让备份在恢复数据之外还能发挥其他功效的理念

7.3. 让同一份数据副本既能当备份使用，又能当档案使用

7.4. 用来检查数据是否符合各项法律法规

• 7.4.1. 一旦发现有人以某种模式来使用数据，系统就会把违规使用数据的情况通知给相关人员

7.5. 还能够扫描发来的备份数据，以阻止勒索攻击

• 7.5.1. 通常是在遭受攻击之后才开始恢复的，而不是在攻击刚开始发生时就发出提醒

• 7.5.2. 让它很适合用来探测有没有人正在对本组织的某个或某些系统发动勒索攻击

7.6. 提供本来应由CDM系统提供的一些功能

• 7.6.1. 可以提供一种能以读/写模式挂载的快照，并据此轻松地制作出相应的虚拟机，让我们能够在这样的虚拟机里面开始做测试/开发工作

7.7. 根据备份与恢复之外的需求来做历史数据分析

8. 如何选取备份方案

8.1. 没有哪个备份与恢复方案是完美无缺的

8.2. 已有备份方案是否能满足需求

• 8.2.1. 真正问题通常都不是软件或硬件问题，而是配置问题

• 8.2.2. 原方案提供方为了挽留你们继续使用该产品，甚至会提供免费咨询

8.3. 权衡各种备份方案的优劣

• 8.3.1. 如果你们需要把以后的主要工作放在云端执行，而不仅是把本地的虚拟机搬移到云平台，那可能就得考虑那些专门为云端设计的备份与恢复系统

• 8.3.2. 块存储在恢复单一的大型镜像时，可能比较快，大部分备份系统都会把备份数据当作一个大型的镜像保存到磁盘中

• 8.3.3. 如果你用的是对象存储，那么一定要看看备份系统是怎么存储备份数据的，不要选择那种有可能影响性能的存储方式

8.4. 直接购买整套解决方案

• 8.4.1. 大多数备份与恢复系统目前都以整套方案的形式售卖

8.5. 应该把你们的组织能够接受，且可以满足其需求的备份方式列出来，然后看看有哪些整套的备份解决方案支持这样的备份方式，接下来从这些方案里选购