1. 备份简史
1.1. 20世纪80年代中期大家都还没有意识到，运行着商用UNIX操作系统的大型工作环境里，应该配备一款商用的备份软件或某种自动的磁带系统
1.2. 1993年备份工作全都是通过shell脚本与cron job形式的计划任务来实现的
- 1.2.1. 脚本总是假定服务器中需要备份的数据肯定能够装到一盘备份磁带里
1.3. FRU
- 1.3.1. Field-Replaceable Unit，可当场更换的部件
1.4. 磁带柜又一次改变了备份工作的面貌
-
1.4.1. 备份系统能够通过磁带柜的机械手臂，自动给磁带制作副本
-
1.4.2. 某些磁带柜还可以把晚上制作好的磁带收集到一个特制的抽屉里，第二天早上抽出来给我们看
2. 确定备份系统的规模
2.1. 采用的方式可能是增强现有的产品，也可能是彻底换用新的产品
2.2. 必须把该系统的规模确定下来，然后才能去考虑购买与此规模相适应的备份方案
2.3. 了解需要购买多少硬件、软件、磁带或磁盘
2.4. 考虑的因素
-
2.4.1. 做一次完全备份需要占用多少存储空间
-
2.4.1.1. 相当重要
-
2.4.1.2. 首次制作完全备份之后，还需不需要继续制作这样的完全备份了？
-
2.4.1.3. 如果需要，那么每隔多久做一次？
-
2.4.2. 有待备份的数据在日常工作中的变化频率
-
2.4.2.1. 最好的办法是参考目前这个备份系统日常制作增量备份时所需占据的空间
-
2.4.3. RTO（目标恢复时间）
-
2.4.4. RPO（目标恢复点）
-
2.4.5. 如果我们不知道该系统必须在多长时间内完成恢复(RTO)，也不知道最多允许丢失多少数据(RPO)，那就无法设计出合适的备份系统
-
2.4.6. 备份在站内与站外需要保留多久
-
2.4.6.1. 一个不能由设计备份系统的团队自己去猜测的指标
-
2.4.6.2. 你们的组织一般会从多久之前制作的备份里恢复数据
＞ 2.4.6.2.1. 备份系统的管理员可以直接帮上忙的
-
2.4.6.3. 法律法规是否要求某些数据必须多保留一段时间
-
2.4.6.4. 是否需要确保某些数据一定会在某段时间之后予以删除
-
2.4.6.5. 如果需要保存的时间特别长，那就应该考虑将其作为档案，而不是备份来予以保存了
-
2.4.7. 制作备份的时间段
-
2.4.7.1. 备份窗口或备份时段
-
2.4.7.2. 一定要就“何时可以制作备份”达成共识
-
2.4.7.3. 如果你们设计的备份系统是从文件级别来制作增量备份与完全备份的，那么必须把这个窗口定下来
＞ 2.4.7.3.1. 这种系统在制作备份的过程中会给执行正式工作的生产系统带来很大负担，对于完全备份来说，这种负担尤其严重
-
2.4.7.4. 如果你们设计的备份系统是从数据块的级别来制作增量备份的，或是运用了源端去重机制，那么该系统在制作备份时给生产系统带来的负担就小得多了
-
2.4.8. 有待备份的数据量在接下来的3~5年里会以什么样的速度增长
-
2.4.8.1. 与你们组织对未来几年的规划有关
-
2.4.8.2. 看看这些发展计划里有没有出现提到存储空间的地方
2.5. 在考虑设计方案时，恢复速度对设计思路的影响要比备份速度大
-
2.5.1. 很容易就能以每小时7TB的速度来备份整个数据中心里的数据
-
2.5.2. 想让备份系统能够以每小时2.5TB的速度把数据恢复到某个客户机上，就未必这么容易了
2.6. 需要与一位懂备份产品的主题专家(SME)合作，以确定这个系统所应达到的吞吐量（或者说，处理能力）
-
2.6.1. 每个磁盘或磁带系统的吞吐量同样有其上限，你必须把这两方面结合起来，才能明白如何达成自己的设计目标
-
2.6.2. 需要把系统中的每一部分所具备的处理能力都充分发挥出来，不要浪费资源
-
2.6.3. 需要确定它应该拥有多大的存储空间，这可以从你们约定的保留期算起
-
2.6.4. 要求你估算未来的增长速度，必须把这个因素也考虑进来
3. 维护备份服务器上的操作系统
3.1. 为了实现该系统，必须采用一系列实体服务器或虚拟服务器作为其核心部件
3.2. 备份服务器是守护备份数据的一道门，这些备份数据是相当宝贵的资产
3.3. 如果他们能够获取到访问操作系统的特权，那么就有可能提升自己对备份软件与硬件的访问权，从而借此给你们的组织造成破坏
3.4. 为了防止他人破坏备份数据，你必须让这些备份服务器成为整个数据中心里更新最及时且安保最严格的服务器
4. 维护备份软件
4.1. 备份厂商经常会给它们的备份软件添加新功能
4.2. 作为备份系统的管理员，你必须尽力更新这些备份软件
-
4.2.1. 有些更新是安全更新，需要立刻安装
-
4.2.2. 还有一些则可以灵活处理，例如可以等到系统有机会暂时下线的时候，再去安装
-
4.2.3. 除了要更新备份服务器上的软件，你还必须考虑自己是否安装过与该软件相配合的agent，如果有，那么这些agent也需要更新
4.3. 最恐怖的事情莫过于升级备份系统上的软件，因为新版软件有可能把原来制定的许多流程都搞乱
- 4.3.1. 一定要给新版的备份软件做测试
5. 应对各厂商的产品之间的差异
5.1. 至少会涉及4个不同的厂商
-
5.1.1. 备份服务器的制作商
-
5.1.2. 备份软件的开发商
-
5.1.3. 磁带或磁盘的制作商
-
5.1.4. 备份数据的保管方
5.2. 全部采用磁盘保存备份副本实在太贵，所以还是会使用老式的磁带柜，在需要长期保留数据的组织里尤其容易出现这种情况
5.3. 混用各厂商产品的环境里，最大的问题就是这些产品之间会出现不兼容的现象
6. 专门用一个系统做DR
6.1. 大多数备份系统都很难满足针对恢复整个数据中心的内容而设定的RTO
6.2. 许多组织都会再买一套系统，专门用来给那些执行重要任务的系统做灾难恢复(DR)
6.3. 单独购买一个系统，并采用该系统来执行DR计划
7. 专门用一个系统做电子取证
7.1. 备份是用来在系统受到损坏或破坏之后恢复该系统的，而档案则用于应对电子取证与合规方面的需求
7.2. 如果你想把暂时用不到的数据保存到成本较低的地方，那么也可以考虑将其归档（也就是将其制作成档案）
7.3. 大多数备份系统都不适合作为档案系统使用
7.4. 单独构建一个系统做电子取证，开销不会很小，但总要低于你们手工应对电子取证请求所引发的开销
7.5. 如果你们的备份系统无法执行电子取证（其实大多数备份系统都不行），那么很可能会因为想要降低后续成本而决定单独购置一个电子取证系统
8. 与磁带有关的问题
8.1. 磁带机很难做性能优化
-
8.1.1. 在许多数据保护系统里，磁带机是必备的组件，然而要想对基于磁带的备份系统做出性能优化，几乎不太可能
-
8.1.2. 无法针对增量备份做性能优化的
-
8.1.3. multiplexing固然能提升备份的效率，但却会降低恢复时的效率
-
8.1.3.1. 在恢复时，你必须将这些备份数据全都读取出来，而且要把里面的大多数内容丢掉
-
8.1.4. 把一套完整备份从磁盘复制到磁带差不多，而且能够将这两种存储设备的优势都充分发挥出来，磁盘适合充当初始的备份目标，磁带则适合用来转录已经备份好的一大批数据
-
8.1.5. 事先把这些数据备份到磁盘，然后再将其转录到磁带上，那么至少不会出现性能问题
-
8.1.6. 我们无法根据发送给磁带机的各种备份数据来把这些磁带机的性能给彻底调整好
8.2. 磁带可能会弄丢
-
8.2.1. 如果你们已经采用磁盘来保存组织内部的日常备份数据了，然而有些做灾难恢复时需要使用的信息依然存放在磁带上，那么这些磁带可能还是得交给“开着货车的人”(man in a van)，让他把磁带运到某个地点去保管
-
8.2.2. 磁带可能会丢失或遭窃
-
8.2.2.1. 在制作备份时给数据加了密，那后果就没有这么严重了
-
8.2.2.2. 把数据备份到磁带的时候，一定要加密，否则实在是太冒险了
-
8.2.2.3. 未加密的备份磁带落到坏人手里真的很糟糕
8.3. 离站磁带的保管方也是一个风险因素
-
8.3.1. 流程用来确保本组织总是能够知晓每一盘磁带目前应该位于何处
-
8.3.2. 保管者是人，人都会出错，无论是故意还是不小心，总之，人是会出错的
9. 与磁盘有关的问题
9.1. 我们从来都没有打算去解决IT问题，我们只是要把这些问题转移到别处
9.2. 磁盘无法与备份系统断绝联系
-
9.2.1. 磁带除了成本低廉，还有一个好处就是你很容易把它运送到离站地点，从而切断其与备份系统之间的联系
-
9.2.1.1. 在使用磁带的那个年代，入侵者必须亲自进入保管磁带的地点，才能破坏这些离站的备份数据
-
9.2.2. 设置这样的屏障能够防止坏人删掉你们的备份数据，或者防止他们故意给这些数据加密，然后向你索要赎金
-
9.2.3. 有人会入侵备份系统，并由此访问你们的磁盘，他会故意给这些数据加密，或者故意把它们删掉，让你将来无法执行数据恢复
-
9.2.4. 如果你是使用SaaS服务存放备份数据的，而该服务所使用的基础设施与你们自己的基础设施是完全隔开的，那么通常也可以起到防护效果
-
9.2.4.1. 计算机病毒与打算发起勒索攻击的人，无法通过攻击你们的基础设施来顺带攻击这些备份数据
9.3. 位衰减
-
9.3.1. 保存在磁性介质上的数据所出现的退化现象
-
9.3.2. 磁盘里的数据块不应该存放超过5年，否则就有可能出现位衰减
-
9.3.3. 唯一有效的方案就是多施加一套机制，让该机制把数据偶尔检查一遍，看看这些数据是否与从前相同
-
9.3.4. 常见的方案是采用对象存储机制来应对这种长期存放数据的需求
-
9.3.4.1. 如果磁性介质中的数据由于退化而变更，那么对象存储机制可以将这一状况探测出来，并予以修复
10. 其他情况
10.1. 前期需要投入大量资金购买设备
- 10.1.1. 必须把接下来两年可能会用到的硬件也提前购买进来
10.2. 必须为有可能出现的各种状况提前配置资源
- 10.2.1. 许多资源在备份量比较少的那些时段里会处于闲置状态
10.3. 难以扩展
-
10.3.1. 备份系统里的组件通常都是那种只能更换而不能扩充的组件
-
10.3.2. 备份系统必须把纳入备份范围的每一份文件，以及接受去重处理的每一个数据块，都记录在索引里面
