1.4.1. 对象存储系统会定期重新计算每个对象的哈希码，并将其与原本的UID进行对比
1.4.2. 因为位衰减而造成的差别就会立刻浮现出来，对象存储系统可以从早前复制到其他地方的某个副本里寻找相应的数据，并将其复制回来，以修复此问题
1.5. 对象存储也能够当作协议层来用，这种协议层可以覆盖在各种类型的底层存储系统上1.5.1. 对象存储也能够当作协议层来用，这种协议层可以覆盖在各种类型的底层存储系统上
1.5.2. 系统只要能给对象存储写入数据就行，而无须关心这个对象存储系统在底层究竟如何保存对象
1.5.3. 访问时间（access time，又称存取时间）等指标还是有必要注意的，你可以换用不同手段来实现对象存储方案，看看哪种手段能够缩短访问数据所需的时间
1.6. Amazon的S3（Simple Storage Service，简单存储服务）1.6.1. S3在对象存储领域的地位与Kubernetes及Docker在容器与容器编排领域的地位类似
1.6.2. 一提起容器与容器编排系统的实现方式，我们只会想到Kubernetes和Docker
1.7. 弹性较高的对象存储方案显得更加可靠，它能够更好地应对灾难、网络攻击以及管理失误1.7.1. Google Cloud Platform是一个很典型的例子
1.7.1.1. 它提供的所有对象存储方案，在访问时间与可靠程度这两个方面都是相同的
1.7.1.2. 区别在于获取数据的费用
1.7.1.2.1. 价格较低的那些方案，虽然在保存数据时几乎不用花钱，但是获取数据的费用却很高
1.8. 如果打算用对象存储系统来充当备份与档案的目标，那么应该把私有云以及各种公用云厂商所能提供的方案都考虑一遍2. 目标去重设备2.1. 去重（deduplication，也就是重复数据删除）是一个流程，用来认定一系列备份或档案中的重复数据并将其删除，以提升磁盘存储系统的利用效率2.2. 最为流行的备份目标自然还是目标去重设备2.2.1. 当前我们在保存备份数据时，最常使用的一种设备就是目标去重设备
2.2.2. 目标去重设备是一种能够执行去重的设备
2.3. VTL2.3.1. Virtual Tape Library，虚拟磁带柜
2.3.2. 实际上是一个伪装成磁带柜形式的服务器，它其实会把备份的结果保存到磁盘上
2.3.2.1. VTL可以通过Fibre Channel（光纤通道）或iSCSI连接
2.3.2.2. 通过Fibre Channel与块设备相连，性能要远高于通过网线与NAS阵列相连
2.3.3. 在基于磁盘的备份目标里面，VTL可以说是头一种能够成为主流的专用设备
2.3.3.1. VTL起初比较流行
2.3.4. 大多数VTL都能够模仿某种型号的磁带柜，甚至连插槽数量与磁带柜所支持的磁带机数量这样的小细节，也能够模拟出来
2.3.4.1. 对于备份服务器而言，它还是会认为自己把数据备份到了真正的磁带柜里
2.3.4.2. 有的备份程序（例如基于NDMP的程序）只支持将数据备份到磁带，但你可以把VTL当成备份目标，从而让这些数据进入磁盘
2.3.5. 缺点在于：它明明用的是支持随机访问的磁盘，但为了模拟磁带，它必须以一种只能按顺序访问的方式运作
2.3.5.1. 如果你正在某个虚拟磁带上做备份或恢复，那么这个虚拟磁带就无法参与到其他的备份与恢复流程之中
2.4. NAS filer2.4.1. 基于NAS的目标去重设备已经明显超越了VTL
2.4.2. 所有的主流备份产品都开始支持NAS filer所提供的文件系统了
2.4.3. 基于NAS的目标去重系统能够通过NFS或SMB协议来挂载，这种系统共享起来要比虚拟磁带柜(VTL)容易得多
2.4.4. 把数据备份到文件系统上，要比备份到磁带容易得多
2.4.5. 问题在于：备份数据以一个目录的形式出现在了备份服务器上
2.4.5.1. 创建特制的协议，令备份软件能够通过该协议与目标去重系统沟通，而不让备份数据在服务器上以一个目录的形式出现
2.4.5.1.1. 如果你现在用的是这样的备份软件，那就应该立刻考虑开启相关的选项，把这个备份目录隐藏起来
2.4.5.1.2. 如果你的备份产品还没有提供这种选项，那可能就得考虑是否需要换用其他备份产品了
2.5. 带有目标去重机制的磁盘阵列是一种相当有用的手段，让我们能够把备份工作从磁带迁移到磁盘2.5.1. 随着备份技术不断发展，又会出现一些可能比目标去重设备更为流行的备份手段
2.5.2. 备份是云平台的拿手项目
2.6. 所有的目标去重系统都不相同2.6.1. 切割数据的方式不同，去除重复数据的手法不同，而且把去重后的数据写入存储介质的办法也不同
2.6.2. 当场去重(inline)与后置去重(post-process)之间
3. 公用云存储3.1. 对象存储3.1.1. 对象存储的优势在于它能够同时读取并写入多个小文件，然而，把备份数据写入磁盘的备份软件基本上都不是这么运作的，因此未必能够直接发挥出对象存储的优势
3.1.2. 对象存储本身具备许多特性，只不过与一般的块存储设备相比，读取单个的大文件并不是它的强项
3.1.3. 你每执行一次I/O操作，都需要为此付费，这样的操作可能叫作GET与PUT，这种收费方式通常称为request pricing（按读写请求收费）
3.2. 块存储3.2.1. 通常以文件系统的形式呈现
3.2.2. 块存储与对象存储相比有一个好处，即它跟大多数备份软件读写数据的方式是比较契合的，这些软件更习惯读取文件系统与块存储里的数据
3.2.3. 块存储则没有这个问题，因为你付的费用已经涵盖了所有的I/O操作，无论你执行多少I/O，都是这个价钱
3.3. cloud out3.3.1. 只把云平台当成保存离站备份的地方
3.3.2. 如果客户依然在自己的数据中心里运行备份软件，只不过会把其中的某些或全部备份复制一份放在云端，那么它用的就是cloud out方式
3.3.3. 云端当成了一个离站的保管公司
3.3.4. 云端的对象存储比较廉价，客户可以轻易地将备份数据复制到这里做离站保存
3.4. 把运行在数据中心里的备份软件放到云端虚拟机里运行3.4.1. 至少要把最近制作出来的一些备份放在某个文件系统里
3.4.2. 客户可能要在底层选用块设备
3.5. 云原生存储3.5.1. 原生的云端存储方案
3.5.2. 可以使用对象存储作为备份目标，并且能够发挥出这种存储机制的各项优势，这也包括效率方面的优势
4. 选择备份目标并发挥其优势4.1. 并没有适用于所有人的完美备份设备，大家都必须学会根据自己的需求来选择最合适的设备4.2. 必须想办法把现有的这种存储设备所具备的潜力充分发挥出来4.3. 优化现有存储设备的性能4.3.1. 优化磁带的性能
4.3.1.1. 给磁带机做性能优化是相当困难的，但无论如何，你都必须先了解磁带的基本工作原理
4.3.1.2. 大多数备份系统之所以会在使用磁带时出问题，都是由于它们生成备份数据的速度赶不上磁带的转速
4.3.1.2.1. 需要重新设计该系统，让备份数据的生成速度尽量与磁带的速度接近
4.3.1.3. 最低传输速度(minimal transfer speed)
4.3.1.3.1. 每个厂商所生产的每一种磁带机，在该指标上可能都有所区别
4.3.1.4. 要是能把备份数据的生成速度，直接做得跟磁带机所支持的最大速度一样，那当然最好
4.3.1.5. 暂时做不到，那还是先想办法让它达到磁带机的速度下限
4.3.1.6. 如果磁带机的速度最低只能降到每秒500MB，而备份服务器给磁带机传输数据时所用的带宽却仅有每秒100MB，那肯定会出问题
4.3.1.6.1. 每秒100MB的网络，无论如何也做不到每秒传输500MB数据的效果
4.3.1.7. 目前的备份服务器至少应该采用10G的以太网，这样才能让数据的传输速度满足备份设备的要求
4.3.1.8. 最简单的办法就是别把平常制作出来的那种备份直接发送到磁带上，而是可以在磁带系统前放置一套磁盘缓存机制，让这套缓存里至少存有一个晚上的备份量，这样这些数据就能以磁带机所要求的速度立刻进入磁带系统，而不会让磁带机因数据输入得过慢而被迫降速或反复倒带
4.3.1.9. 更好的方案是把带有去重机制的磁盘阵列放在磁带系统的前端
4.3.1.10. 如果你们无力承担给磁带系统前面放置磁盘的费用，那就必须尽力确保备份数据的输入速度至少要跟磁带的最低速度一样快
4.3.1.10.1. 唯一的办法就是把备份系统的multiplexing功能打开
4.3.1.10.2. 只需要让这个速度达到磁带机的最低要求，而不能调得过高，因为速度越高，将来恢复数据时效率就越低
4.3.2. 优化RAID的性能
4.3.2.1. RAID磁盘阵列的性能，优化起来要比磁带机容易得多
4.3.2.2. 凡是带有奇偶校验机制的RAID配置方式，都会让数据的写入效率有所降低
4.3.2.3. 只是把RAID阵列当成位于磁带机之前的磁盘缓存机制，那或许可以考虑采用striping方式（也就是RAID 0方式）来配置，这种方式不做校验
4.3.2.3.1. 能够避开校验带来的影响，从而大幅提升磁盘的写入性能
4.3.3. 优化目标去重设备的性能
4.3.3.1. 不要仅为了追求去重率(deduplication ratio)而无谓地执行完全备份
4.3.3.1.1. 做完全备份的频率比备份系统要求的还高，那实际上就相当于把很大一部分时间都浪费在了给备份数据做去重处理上，这样的处理工作基本上是多余的
4.3.3.2. 要考虑备份数据与目标去重设备之间的连接方式
4.3.3.2.1. NFS可能比SMB快一些，也有可能刚好相反
4.3.3.2.2. iSCSI连接，这样连接，速度或许更快
4.4. 改用更为合适的设备4.4.1. 厘清你的备份软件或备份服务所支持的设备
4.4.1.1. 如果你们已经选好了自己的备份软件或备份服务，那么应该先跟提供该软件或服务的厂商沟通，问问他们，这款产品最适合跟什么样的目标设备搭配
4.4.1.1.1. 先听取他们的意见，然后自己做测试，最后再决定
4.4.1.2. 如果你们还没有选定备份软件，而是正打算购买一套新的备份系统，那么一定要先把备份系统定下来，然后再去考虑购买什么样的目标设备
4.4.1.2.1. 一定要先把备份软件或备份服务定下来，然后再根据该产品来考虑购买什么样的目标设备
4.4.2. 选择最适合自身情况的设备
4.4.2.1. 在资金许可的范围内，挑选最适合自己的系统
4.4.3. 位于本组织内部的磁盘
4.4.3.1. 在组织内部构建一套完全基于磁盘的备份系统
4.4.3.1.1. 通常会与源端或目标端的去重系统相搭配，让你们能够对所有的备份都执行去重处理，并将其轻松地复制到其他地点
4.4.3.2. 并非所有的磁盘系统在性能上都完全一样，你必须先测试自己打算购买的这个系统，看看它的性能究竟如何，然后再决定是否购买
4.4.3.3. 一定要把实际工作环境里经常有可能出现的那些状况全都测试到
4.4.3.4. 在多个目标去重系统之间对比的时候，你应该把同一套数据备份到它们上面，看看其中哪一个产品的去重率高
4.4.3.4.1. 一定要用实际工作中的数据来测试，否则就是浪费时间
4.4.3.5. 能够立刻将其恢复，那么必须把你们打算购买的目标去重系统放在这种情境下测试一遍
4.4.3.6. 别只拿一两个虚拟机测试，而是要尽可能让虚拟机的数量接近你们在恢复受灾的工作系统时所需使用的实际数量
4.4.3.6.1. 某些系统在只开一两个虚拟机的情况下表现得或许还可以，但你只有增加虚拟机的数量，才能看出这些系统的真实水平
4.4.4. 云存储
4.4.4.1. 如果你们要在云端运行备份系统，那只能选择云盘作为目标设备
4.4.4.2. 如果支持对象存储，那么你要注意观察它在使用这种类型的存储设备时，性能究竟如何
4.4.4.2.1. 支持对象存储，并不意味着它在使用这种类型的存储设备时，性能一定很高
4.4.4.3. 支持对象存储的产品有Amazon S3、Azure Blob与Google Cloud Storage
4.4.4.4. 不应该仅因为对象存储比较便宜，就去使用它，你必须考虑到这样做是否会产生严重的后果
4.4.4.5. 对象存储能够自我修复，而且会自动把数据复制到多个地点（一般是三个）
4.4.4.5.1. 如果使用对象存储，那么你所付的费用本身就涵盖了制作三份副本这一功能
4.4.4.5.2. 在公用云平台里使用对象存储时需要关注的费用问题，主要在于云平台会针对读取与写入操作收费
4.4.5. 完全使用磁带
4.4.5.1. 只有在所有的磁盘系统都已经涨得比磁带系统贵，而且你们又确实很缺钱的情况下，才值得仅采用磁带系统来存放备份数据
4.4.5.2. 如果你们是受资金原因影响而决定采用磁带方案的，那么最后买的可能会是LTO
4.4.5.3. LTO有一个好处，即这种磁带机在读取磁带时肯定能兼容前两代产品，在写入磁带时肯定能兼容前一代产品
4.4.5.4. 如果某款磁带柜可以通过添加插槽或磁带机来升级，那么就算价格稍微贵一点，也是很划算的
4.4.6. 混合使用多种目标设备
4.4.6.1. 同时使用磁盘与磁带
4.4.6.1.1. 可以用磁盘来存放组织内部的备份数据，并将离站副本保存到磁带上
