1. 康复测验

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. 备份体系是用来记住数据的，但咱们现在或许得让它把某些东西遗忘