1.1. 所有的备份都必须经过测试
1.1.1. 没有经过测试的备份不算真正的备份
1.2. 数据制作备份的唯一理由就在于以后想要从备份中恢复这些数据
1.3. 能不能把备份所保护的数据恢复出来，唯一的办法就是对备份做测试
1.3.1. 常规的（或者说，例行的）恢复测试应该是其中很重要的一个部分
1.3.2. 要测试备份系统及其文档是否有效，我们还必须安排常规的恢复测试，以此来培训员工
1.4. 对自己所负责的全部数据都定期执行恢复测试
1.4.1. 每种数据的测试频率应该根据这种数据多长时间恢复一次来决定
1.5. 云平台能够简化各种测试工作
1.5.1. 不用担心这些测试之间会争着把数据恢复到同一套资源上
1.5.2. 在云平台里把每种测试所针对的资源配置好，这样就可以让这些测试都把数据恢复到各自所针对的资源上
1.5.3. 应该把SaaS里常见的一些东西也恢复出来
1.5.3.1. 用户
1.5.3.2. 文件夹
1.5.3.3. 单个的文件
1.5.3.4. 电子邮件
2. 备份级别2.1. 完全备份(full backup)
2.1.1. 将所有东西都备份下来
2.1.2. 传统意义上的完全备份会把有待保护的系统里（除了你明确排除掉的那些东西之外）的所有东西，全都备份到备份服务器中
2.1.3. 文件系统里的所有文件或数据库里的所有记录，都在备份范围之内
2.1.3.1. 前者属于非结构化数据(unstructured data)
2.1.3.2. 后者属于结构化数据(structured data)
2.2. 增量备份(incremental backup)
2.2.1. 只把变化的内容备份下来
2.2.1.1. 传统意义上的增量备份会把文件系统里自上次备份以来发生变化的所有文件，或者数据库里自上次备份以来发生变化的所有记录都备份下来
2.2.1.2. 不同的备份产品在运用这几类增量备份时所采用的术语，可能也有所区别
2.2.2. 全文件式的增量备份（full-file incremental backup，也称整文件式的增量备份）
2.2.2.1. 只要某文件的修改日期跟上次备份时不同，或它在Windows系统里的存档位（archive bit，也叫档案位、封存位）标注为开启，那么该文件就会纳入这次备份的范围
2.2.2.2. 只有两种增量备份不是这么运作的，也就是块级别的增量备份以及原数据端的去重备份
2.2.3. 标准的增量备份
2.2.3.1. 标准的增量备份（typical incremental backup，也叫典型的增量备份）是把从上次备份算起发生变化的所有数据全都备份下来，无论上次做的是哪种类型的备份，都这样处理
2.2.3.2. 如果你做的是标准的增量备份，那必须把当前这个标准增量备份与最近一次完全备份之间的所有标准增量备份全拿出来，才能够恢复数据
2.2.4. 积累式的增量备份
2.2.4.1. 积累式的增量备份（cumulative incremental backup，又叫累进的增量备份）是把从上次做完全备份时算起发生变化的所有数据全都备份下来
2.2.4.2. 只需要拿出最近一次的积累式增量备份以及它所依据的那个完全备份，就可以把所有数据全都恢复出来
2.2.4.3. 若是将备份放到磁盘上，那么积累式的增量备份所具备的优势，就体现不出来了
2.2.5. 带有层次的增量备份
2.2.5.1. 利用层次或级别(level)这一概念来覆盖前面某段时间内所发生的变化，它用0级备份来表示完全备份，用1至9级来表示增量备份
2.2.5.2. 每一级的增量备份都会把从上一个级别低于它的备份算起发生变化的所有数据全都涵盖进来
2.2.5.3. 汉诺塔(Tower Of Hanoi, TOH)式的增量备份方案
2.2.6. 块级别的增量备份
2.2.6.1. 块级别的增量备份(block-level incremental backup)只会把自上次备份以来发生变化的字节或块备份进来
2.2.6.2. 关注的是发生变化的字节或块，它会用一种机制来判定，有哪些字节、字节段或块在上次制作备份之后发生了变化，从而需要纳入增量备份之中
2.2.6.3. 备份方式所要执行的I/O数量以及所需的带宽，要比全文件式的增量备份小得多
2.2.6.4. 最为常见的用途是备份虚拟机管理器
2.2.6.4.1. 位图(bitmap)的结构，里面记录着从某个时间点算起发生变化的全部二进制位
2.2.7. 源数据端的重复数据删除
2.2.7.1. 源数据端的重复数据删除(source-side deduplication)简称源端去重，其中的“源”字是为了强调这种去重应用于源(source)数据，而非目标(target)数据
2.2.8. 合成式的完全备份
2.2.8.1. 制作完全备份的频率越高，恢复起来就越快，因为这会缩短处理增量备份所花的时间
2.2.8.2. 通过复制制作合成式的完全备份
2.2.8.2.1. 不会影响备份客户端，也就是说，你要备份的那个服务器或虚拟机，根本不会在合成备份的过程中受到影响，因此，无论什么时候都可以做这样的备份
2.2.8.2.2. 复制数据的过程很耗时间
2.2.8.2.3. 会对备份的来源系统与目标系统之中的磁盘，做出大量的I/O操作
2.2.8.3. 通过目标去重设备来模拟合成式的完全备份
2.2.8.3.1. 其间不需要移动数据，因此效率相当高，只不过这种办法可能仅适用于备份特定类型的数据
2.2.8.3.2. 虚拟机、文件系统，以及某些受支持的数据库
2.2.8.4. 从刚开始就一直做增量备份
2.2.8.4.1. 你的备份软件应该将每个对象都分开存放，即便是最小的对象
2.3. 月初做一次完全备份，每天做一次标准的增量备份，每周做一次积累式的增量备份
2.3.1. 切换磁带所浪费的时间从45min缩短到12min
2.4. Windows系统的存档位
2.4.1. 存档位（archive bit，也叫档案位、封存位）是Windows系统给文件设计的一个标志
3. 数据保护系统的各项指标3.1. 与恢复有关的指标
3.1.1. RTO
3.1.1.1. 看它恢复数据需要多长时间
3.1.1.2. RTO（Recovery Time Objective，恢复时间目标/目标恢复时间）是各方都同意的一个时长，用来表示系统在遇到事故之后，需要花多长时间才能恢复
3.1.1.3. 不一定非得要求整个组织都采用同一个RTO
3.1.1.4. RTO是一项目标，这与数据保护系统的实际恢复时间(RTA)是有区别的
3.1.2. RPO
3.1.2.1. 看恢复之后损失了多少数据
3.1.2.2. RPO（Recovery Point Objective，恢复点目标/目标恢复点）是指遇到大型事件之后，本组织最多能允许多长时间内的数据遭受损失
3.1.3. RTA与RPA
3.1.3.1. RTA（实际恢复时间）与RPA（实际恢复点）这两项指标只有在执行恢复时才能测量出来，这可以指真正的恢复，也可以指为了测试而做的数据恢复
3.1.3.2. RTA与RPA则用来表示受测系统能够在多大程度上满足这两项目标
3.1.4. 如果不做恢复测试，就无法了解备份系统是否可靠，也无法了解执行大规模的数据恢复到底需要哪些资源，以及这种恢复工作对环境中的其余部分会提出哪些要求
3.1.4.1. 唯一的办法就是做恢复测试
3.2. 与系统的能力或容量有关的指标
3.2.1. 系统对授权与工作负载的使用量
3.2.2. 总的存储容量与已使用的容量
3.2.2.1. 如果不监控存储设备的总容量以及系统当前已使用的容量，那你就有可能遇到必须做出紧急决定的情况，而你在这种情况下所做的选择，可能会违背本组织的备份策略
3.2.3. 数据处理速度
3.2.3.1. 备份系统每天能够接受的备份量通常有一定限度，我们一般用每秒多少MB或每小时多少TB来表示
3.2.3.2. 一定要监控系统的数据处理速度与磁带驱动器的数据处理速度，这是相当重要的
3.2.3.3. 云平台的优点在于，如果你使用的这个云端产品或云端服务能够根据使用情况自动调整其带宽，那么它的数据处理速度就几乎不受限制
3.2.3.3.1. 主站的带宽并不是无限的，而且每天也只有24个小时，因此主站与云平台之间的传输总量有一定限制
3.2.4. 计算能力
3.2.4.1. 云平台中的许多备份系统与备份服务所使用的软件，与运行在数据中心里的备份产品相同
3.3. 备份窗口
3.3.1. 备份窗口（backup window，或称备份时段）
3.3.2. 传统的备份系统在备份期间会大幅影响主系统的性能
3.3.3. 完全备份是要把所有东西都备份下来，因此给主系统带来的负担当然会比较大
3.3.4. 做增量备份，如果用的是全文件式的增量备份，那么依然会让主系统承受压力
3.3.4.1. 即便文件里只有一个字节发生变化，备份系统也还是要把整个文件都备份下来
3.4. 备份与恢复的成功率与失败率
3.4.1. 把执行备份与恢复的次数记录下来，并计算出各自的成功率
3.5. 保留策略
3.5.1. 是备份系统与档案系统里一个特别重要的东西
3.5.2. 确保备份系统确实能够按照预定的保留策略来保留数据
3.5.3. 数据保护系统的保留期也应该由组织来决定
3.5.3.1. 备份或档案保留多久，不应该由IT部门里的某个人决定，而是应该根据法律与监管方面的要求以及本组织的需求来决定
3.5.3.2. 确定保留策略之后，你还应该看看数据保护系统有没有遵守本组织的总策略
3.5.4. 备份数据在每一级存储介质上应该保留多久
3.5.5. 在设定保留期时还应该说明备份数据在每一种介质上保留多久
3.5.6. 被遗忘权
3.5.6.1. Right To Be Forgotten, RTBF
3.5.6.2. 擦除权(right to erasure)
3.5.6.3. 备份系统是用来记住数据的，但我们现在可能得让它把某些东西忘掉
