ToB企服应用市场:ToB评测及商务社交产业平台

标题: 读数据掩护：工作负载的可恢复性05备份级别 [打印本页]

作者: 西河刘卡车医 时间: 2024-12-6 13:16
标题: 读数据掩护：工作负载的可恢复性05备份级别

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. 备份系统是用来记住数据的，但我们现在可能得让它把某些东西忘掉

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)