上期介绍了 Veeam 云对象存储使用的基本方法，但是文中有些内容略微有些小错误，在此不再放入该推送的链接，如有需要，请大家后台回复：Cloud 或者云调取阅读更新后的版本。本期内容给那些想更深入了解该技术的朋友们。
或许已经有人注意到，在使用 Veeam 云对象存储以后，不管备份存档是位于本地数据中心还是位于云上对象存储中，Veeam 均提供各种丰富的还原手段，其中包括最重要的 Veeam 于 2010 年首创的经典技术 – Instant VM Recovery，关于这个技术的详细使用，可以参考之前的推送：
云对象存储特殊属性，各家云厂商在定价上几乎无一例外的采用 4 个维度来制定收费策略，分别是：容量、读写请求次数、读取数据量、订阅服务时间，这和传统存储设备一次性买断投资的特性完全不同，因此对于长期不使用的数据，存放在云端时，读写请求和读取的费用会变得非常的低，这也是对象存储作为归档异地存放的最佳属性。
但是，这并不意味着备份厂商可以无责任的随意使用对象存储，如果把对象存储当做和传统本地存储一致的属性来对待时，对于传统设备的随意读写的这些操作，特别是做数据校验、数据整理、恢复校验、定时重删任务等读写操作，会给用户带来额外巨大的 I/O 和读取费用。因此 Veeam 为存放到对象存储上的数据做了重新打散处理，并且定义了一系列的存取规则，以确保数据可用性的前提下，尽可能少的使用读写 I/O 和读取数据量，降低云端对象存储的使用成本。
元数据（Metadata）和数据块（Block）
每个 Veeam 的备份存档（.vbk、.vib、.vrb）都会由** Metadata 和 Block **组成，在每个本地存储的存档中，Metadata 和 Block 是密不可分的，通常就存在于同一个文件中。而数据被传送到云端对象存储时，Veeam 会将两者拆分开来，在各自的目录中，单独存放相关数据。而本地磁盘上，Veeam 会保留 Metadata，以便能够在恢复时快速找到对应的 Block。
索引（Index）
索引通常在 SOBR Offload Job 启动时生成，其内容包含了。vbk、.vib、.vrb 这些文件中，各切片数据块的哈希值（Hash），Veeam 从备份存档的 Metadata 中提取这些 Block 的哈希值。生成这些哈希值后，Veeam 会首先把这些内容存放在 Scale Out Backup Repository 下该 backup job 对应的 Extents 目录下的 ArchiveIndex 目录中。在以后的任何一次数据传输中，如果有数据块的哈希值和已有的哈希值相同，那么 Veeam 将会重复利用这些已经传输的数据块，而不会再进行传输，避免浪费带宽。
需要注意的是，这个索引是基于完整备份链（Backup Chain）生成的，也就是说，对于两个不同的 Backup Job，即使对于同一台 VM 做了 Backup，实际上在上传到对象存储的时候，就算数据块拥有相同哈希，也会被重复上传。由于这是整个备份链中的数据块信息，因此，每次的备份链发生变化，那么在下一次执行 SOBR Offload Job 时都会重新生成这个索引。
这个索引中的内容，同时包含了某一数据块在云端对象存储中和在本地磁盘存储中的位置信息，如果某一数据块同时存在于 3 份不同的全备份存档中，其中两份位于本地磁盘中，一份位于云端对象存储上，那么索引会将这些信息都记录下来。当需要执行 SOBR Offload Job 进行新数据上传时，VBR 如果发现新的上传数据中需要上传这份云端已有数据，那么 VBR 会跳过该数据块的上传，同时在本地和云端更新相应记录，以此来节省上传带宽和节省上传时间。
当需要还原时，同样的，VBR 会判断被还原的数据块中的哈希值，如果发现索引中有提到本地磁盘中还存放着这些数据块，那么 VBR 会优先选用本地磁盘上的数据作为还原读取的源，从而大大节省从云端对象存储中读取的数据量。
而正是这个原因，也使得选用云端对象存储上的数据执行 Instant VM Recovery 变得可行。
备份链的活跃部分和非活跃部分
只有备份链的非活跃部分，才能被上传至云对象存储中。无论是手工操作还是自动任务，处于备份链活跃部分的还原点，无论如何都将不会被上传至云对象存储上。
这也是本次更新后 Veeam 对于备份链新引入的两个概念，这是在了解云端对象存储数据上传任务中非常重要的两个概念。介绍这两个概念之前，我们来复习下备份链（Backup Chain）的定义：在 Veeam 的备份存档中，存放在存储介质中的数据以备份链的形式存放，以普通增量备份为例，一般存放结构如下图所示，那么对于一个 Backup Job 而言，这一组文件的集合，被称之为备份链（Backup Chain）。
而备份链的活跃部分和非活跃部分则是以最后一次全备份为分界线，在最后一次全备份之前的部分，我们称之为备份链的非活跃部分，而在最后一次全备份之后的所有增量备份和该全备份，被称之为备份链的活跃部分。如下图所示：
当然这依然是以普通增量备份为例，对于反向增量备份、永久增量备份、Backup Copy，情况会略有不同，但是基本规则也和上面提到的一致。
随着时间的推移，作业的进行，早期的还原点（Restore Point）将会因为新的全备份的产生而被转换为非活跃，从而实现 Offload 操作。
总结一下，哪些数据将会被上传至云对象存储中：
属于备份链的非活跃部分的数据；
早于 Capacity Tier 中设定的日期的数据；
这个 Block 是否之前没有在这个 Backup Job 中被上传过。
这个 3 个条件验证完后，数据将会被决定是否会上传。
以上就是本期对 Veeam Cloud Tier 的深入分析。
