容量层（或者我们在 Vim 中称之为 - captir）早在 Veeam Backup and Replication 9.5 Update 4 时代就出现了，名称为 Archive Tier。 其背后的想法是能够将超出所谓的操作恢复窗口的备份移动到对象存储。 这有助于为那些磁盘空间很少的用户清理磁盘空间。 这个选项被称为移动模式。
要执行这个简单（看起来）的操作，满足两个条件就足够了：移动备份中的所有点都必须位于上述操作恢复窗口的边界之外，该窗口是在 UI 中明确设置的。 第二：链必须是所谓的“密封形式”（密封备份链或非活动备份链）。 也就是说，随着时间的推移，这条链不会发生任何变化。
但在 VBR v10 中，这个概念又补充了新的功能——复制模式、密封模式以及一个名字很难发音的东西——不变性。
这些是我们今天要讨论的有趣的事情。 首先介绍一下它在VBR9.5u4中是如何工作的，然后介绍一下第十个版本中的变化。
愿纯语言的拥护者原谅我，但有太多术语无法翻译。
所以这里会有大量的英国语。
还有很多动图。
还有图片。
- 没有丝毫的遗憾。 文章作者。
怎么样
好吧，让我们首先分析操作恢复窗口和密封备份（或如非活动备份链文档中所称的那样）。 如果没有他们的理解，进一步的解释是不可能的。
如图所示，我们有一种带有数据块的备份链，它位于容量层所连接的存储库的性能层 SOBR 上。 我们的运营备份窗口为三天。
因此，周一创建的 .vbk 密封了前一个链，其窗口设置为三天。 这意味着您可以安全地开始将三天前的所有物品运送到射击场。
但密封链到底意味着什么？更新 4 中可以将什么发送到容量射击场？
对于前向增量，密封链的标志是创建新的完整备份。 如何获得此完整备份并不重要：合成完整备份和活动完整备份都会被考虑。
在反向的情况下，这些都是不属于操作窗口的文件。
在前向增量和回滚的情况下，这些都是回滚和.vbk，如果性能范围上还有另一个.vbk
现在让我们考虑使用备份副本链的选项。 只有属于政府飞行服务队扣留的物品才会被运送到这里。 因为存储在更新的备份副本链中的所有内容都可以以一种或另一种方式更改。
现在让我们看看幕后。 在那里，会发生一个称为脱水的过程 - 在范围内留下空备份文件，并将这些文件中的块拖动到容量拍摄范围。 为了优化这个过程，使用了所谓的脱水指数，它可以让您避免复制已经复制到容量拍摄范围的块。
让我们通过一个例子来看看这是什么样的：假设我们有一个来自交易窗口的 .vbk，并且属于一条密封链。 这意味着我们完全有权将其移至容量射击场。 移动时，会在传输文件的容量破折号和块中创建元数据文件。 链接级元数据文件描述了我们的文件由哪些块组成。 在图中的情况下，我们的第一个文件由块 a、b、c 组成，元数据包含这些块的链接。 当我们有第二个 .vbk 文件，准备移动并由块 a、b 和 d 组成时，我们通过分析脱水指数，了解到只有块 d 需要传输。 其元数据文件将包含指向两个先前区块和一个新区块的链接。
因此，用数据填充这些空白空间的过程称为补水。 它已经使用自己的补水索引，该索引基于本地性能范围上最旧的 .vbk 文件。 也就是说，如果用户想要从容量射击场返回文件，我们首先创建最旧的完整备份的块的索引，并仅从容量射击场传输丢失的块。 在图中所示的情况下，为了根据补水指数对FullBackup1.vbk进行补水，我们只需要从容量拍摄范围中获取的块C。 如果存储云对象充当容量射击场，这可以让您节省大量资金。
在这里，这项技术可能看起来与 WAN 加速器中使用的技术相同，但实际上只是看起来如此。 在加速器中，重复数据删除是全局性的；这里，本地重复数据删除在每个文件内的特定偏移处使用。 发生这种情况是由于要解决的任务不同：这里我们需要复制大型完整备份文件，根据我们的研究，即使它们之间经过很长一段时间，这种重复数据删除算法也会给出最佳结果。
但索引之神还有更多索引！ 还有数据恢复的索引！ 当我们开始恢复位于容量仪表板中的计算机时，我们将仅读取不在性能仪表板中的唯一数据块。
它变成了
这就是介绍部分的全部内容。 它非常详细，但如上所述，如果没有这些细节，就无法解释新功能是如何工作的。 因此，事不宜迟，让我们继续第一个。
复制方式
它很大程度上基于现有技术，但具有完全不同的使用逻辑。
此模式的目的是确保位于本地盘区的所有数据在容量破折号中都有一个副本。
如果正面比较“移动”和“复制”模式，结果将如下所示：
- 只有密封的链条才能移动。 在复制模式的情况下，无论备份作业中发生什么，绝对都会传输所有内容。
- 当文件超出操作备份窗口的边界时会触发移动，并且一旦备份文件出现就会触发复制。
- 不断监控新数据的复制情况，并每 4 小时触发一次移动数据。
在考虑新模式时，我建议从简单的示例转向复杂的示例。
在最常见的情况下，我们只需拥有带有增量的新文件，然后将它们复制到容量拍摄范围即可。 无论备份作业采用什么模式，无论是否属于链上的密封部分，无论我们的操作窗口是否已经过期。 他们只是拿走了它并复制了它。
这背后的过程仍然是如上所述的脱水。 在复制模式下，它还确保我们不会复制存储中已有的块。 唯一的区别是，如果在电影模式下我们用虚拟文件替换真实文件，这里我们不会以任何方式接触它们并保持一切不变。 否则，它是完全相同的脱水指数，它仔细地试图节省您的金钱和时间。
问题出现了 - 如果您查看用户界面，您有机会同时选择这两个选项。 这种组合模式将如何运作？
让我们理解。
开始是标准的：立即创建并复制备份文件。 为其创建并复制增量。 这种情况会一直发生，直到我们意识到文件已经离开我们的操作窗口并且出现一条密封链的那一刻。 此时我们执行脱水操作并将这些文件替换为虚拟文件。 当然，我们不会再向容量射击场复制任何东西。
所有这些令人着迷的逻辑只负责界面中的一个复选框：创建备份后立即将其复制到对象存储。
为什么我们需要这种复制模式？
最好这样重新表述这个问题：在它的帮助下我们可以免受哪些风险？ 它能帮助我们解决什么问题？
答案很明显：当然，这就是数据恢复。 如果我们在对象存储上拥有本地数据的完整副本，那么无论我们的产品发生什么情况，我们始终可以从位于条件亚马逊的文件中恢复数据。
因此，让我们从最简单到最复杂的顺序来看看可能的情况。
落在我们头上的最简单的不幸就是备份链中的文件之一无法访问。
一个更悲伤的故事是我们的 SOBR 存储库的一个范围损坏了。
当整个 SOBR 存储库无法访问但容量射击场仍在运行时，情况会变得更糟。
一切都非常糟糕 - 当备份服务器死掉时，你的第一个愿望就是尝试在十分钟内跑到加拿大边境。
现在让我们分别看看每种情况。
当我们丢失一个（甚至多个）备份文件时，我们所需要做的就是启动存储库重新扫描过程，丢失的文件将被替换为虚拟文件。 并且使用再水化过程（在文章开头讨论过），用户将能够将数据从容量射击场下载到本地存储。
现在情况更加复杂了。 假设我们的 SOBR 由在性能模式下运行的两个扩展组成，这意味着我们的 .vbk 和 .vib 分布在它们上相当不均匀的层中。 而在某个时间点，其中一个盘区不可用，用户迫切需要恢复机器，而该机器的部分数据正是位于该盘区上。
用户启动恢复向导，选择他想要恢复的点，向导在工作时发现他本地没有恢复所需的所有数据，因此需要从容量拍摄中下载画廊。 同时，保留在本地存储上的块将不会从云端下载。 荣耀恢复索引（是的，文章开头也提到过）。
这种情况的一个子类型是整个 SOBR 存储库变得无法访问。 在这种情况下，我们没有任何东西可以从本地存储复制，所有块都是从云端下载的。
而最有趣的情况是备份服务器挂掉了。 这里有两个选择：管理员是伟大的并且进行了配置备份，管理员是邪恶的匹诺曹本人并且没有进行配置备份。
在第一种情况下，他只需在某处部署全新安装的 VBR 并使用标准方法从备份恢复其数据库就足够了。 在这个过程结束时，一切都会恢复正常。 或者按照上述情况之一恢复。
但是，如果管理员要么是他自己的敌人，要么配置备份也遭受了史诗般的失败，那么即使在这里我们也不会让他听天由命。 对于这种情况，我们引入了一个称为导入对象存储的新过程。 它允许您跳过手动重新创建 SOBR 存储库并在后续重新扫描时为其附加容量射击范围的过程，只需将存储对象添加到 Vim 界面并运行“导入存储存储库”程序即可。 如果您的备份已加密，那么唯一可能妨碍您和您的备份的是输入密码的请求。
这可能是关于复制模式的全部内容，我们继续讨论
密封模式
主要思想是新备份不能出现在存储库的选定 SOBR 范围上。 在 v10 之前，我们只有维护模式，完全禁止对存储库进行任何操作。 一种用于关闭存储的硬核模式，其中只有“Evacuate”按钮可用，该按钮一次性将备份传输到另一个范围。
而密封模式是一种“软”选项：我们禁止创建新的备份，并根据选择的保留逐步删除旧的备份，但在此过程中我们不会失去从存储点恢复的能力。 当我们有一个硬件接近其使用寿命并需要更换它，或者我们只是需要将其释放以用于更重要的事情，但没有地方可以立即移动所有东西时，这是非常有用的。 不然无法删除。
因此，操作原理非常简单：需要禁止所有写入操作（新数据的出现），保留读取（恢复）和删除（保留）。
两种模式可以同时使用，但请记住维护具有更高的优先级。
作为示例，请考虑由两个范围组成的 SOBR。 假设前四天我们以Forward Forever Incremental 模式创建了备份，然后我们密封了范围，这导致我们在第二个可用范围上启动新的活动完整创建。 如果我们的保留是四，那么当位于密封范围内的整条链超出其限度时，就心安理得地删除它。
在某些情况下，删除会提前发生。 例如，这是具有周期性满的正向增量。 如果我们在前两天创建了完整备份，并且在星期四我们决定密封存储库，那么在星期五创建新备份时，星期一的文件将被删除，因为到目前为止没有任何依赖关系。 而且这一点本身并不取决于任何人。 然后，我们等到可用范围上创建了四个点，然后删除剩余的三个点，这三个点不能单独删除。
使用反向增量，事情变得更简单。 其中，最旧的点不依赖于任何东西，可以安全地删除。 因此，一旦在新盘区上创建了新的.vbk，旧的.vrbs就会被一一删除。
顺便说一句，为什么我们每次都要创建一个新的 .vbk：如果我们不创建它，而是继续旧的增量链，那么旧的 .vbk 在任何模式下都会冻结无限长的时间，从而阻止其删除。 因此，决定一旦该范围被密封，我们就在空闲范围上创建完整备份。
由于射击场的容量，事情变得更加复杂。
首先，我们来看看复制模式。 假设我们积极创建了四天的备份，然后容量射击场被封闭。 我们不会删除任何东西，而是谦虚地忍受保留，然后我们将数据从容量射击范围中删除。
在移动模式下，大约会发生同样的事情 - 我们等待修饰，删除本地存储中的旧内容，并删除存储在对象存储中的内容。
一个有趣的例子，永远向前增量。 我们在三个点安装保留，并在周一开始进行备份，并定期将其复制到云端。 密封存储后，继续创建备份，维持三个点，但容量破折号中存储的数据仍然存在依赖性，无法删除。 因此，我们等到周四，当我们的 .vbk 超出保留范围时，我们才会平静地删除整个保存的链。
还有一个小小的免责声明：这里的所有示例都是在一台机器上显示的。 如果您的备份中有多个，那么它们的修饰将根据是否制作了 Active Full 而有所不同。
这基本上就是全部内容了。 那么让我们继续讨论最核心的功能 -
不变性
和前面几点一样，首先是这个函数解决什么问题。 一旦我们将备份上传到某个地方进行存储，就有强烈的愿望来保证它们的安全，即在给定的保留期间物理上禁止它们的删除和任何修改。 包括管理员，包括他们的根帐户。 这可以让您保护它们免受意外或故意损坏。 任何使用 AWS 的人都可能遇到过类似的功能，称为对象锁定。
现在让我们大致了解一下该模式，然后再深入研究细节。 在我们的示例中，将为我们的容量射击场启用不变性，保留四天。 并且在备份中启用复制模式。
不变性不会以任何方式与一般保留相互作用。 例如，它不会添加额外的积分或类似的东西。 只是一个人不能在四天内删除备份文件。 如果您在星期一进行备份，则只能在星期五删除其文件。
所有先前解释的脱水、索引和元数据的概念仍然完全相同。 但有一个条件 - 该块不仅是为数据设置的，也是为元数据设置的。 这样做是为了防止狡猾的攻击者决定擦除我们的元数据数据库并防止数据块变成无用的二进制糊状。
现在是解释我们的区块生成技术的好时机。 或者区块生成。 为此，请考虑导致其出现的情况。
让我们以六天为时间尺度，下面我们将标记不变性的预期到期时间。 第一天，我们获取并创建一个由数据块 a 及其元数据组成的文件。 如果不变性设置为三天，则可以合理地假设数据将在第四天解锁并删除。 第二天，我们将添加一个新文件 2，其中包含具有相同设置的块 b。 第四天，A块仍然需要移除。 但在第三天，可怕的事情发生了——创建了一个 File3 文件，其中包含一个新块 d 和一个到旧块 a 的链接。 这意味着对于一个块及其不变性标志必须重置为新日期，即转移到第六天。 这里出现了一个问题 - 在实际备份中存在大量此类块。 并且为了延长它们的不变性期限，您需要每次发出大量请求。 事实上，这将是一个几乎无休止的日常过程，因为我们很可能会在每个副本中找到大量的重复数据删除块。 来自对象存储提供商的大量请求意味着什么？ 正确的！ 月底账单巨额。
为了不让你最喜欢的客户突然暴露并获取大量金钱，区块生成机制被发明了。 这是我们添加到设置的不变性期限中的额外期限。 在下面的示例中，该时间段为两天。 但这只是一个例子。 事实上，他们使用自己的公式，在每月锁定期间额外提供大约十天的时间。
让我们继续考虑相同的情况，但涉及块生成。 第一天，我们从块 a 和元数据创建 file1。 我们将生成周期和不变性加起来 - 这意味着删除文件的机会将在第六天。 如果第二天我们创建 File2，其中包含块 b 和块 a 的链接，那么预期删除日期不会发生任何情况。 她像第六天那样站着。 因此，我们试图在请求数量上节省资金。 唯一可以改变截止日期的情况是生成期限已过。 也就是说，如果在第三天新的 File3 包含阻止 a 的链接，则将添加第 2 代，因为第 1 代已经过期。 并且预计删除a块的日期将移至第八天。 这使我们能够大幅减少请求数量，以延长重复数据删除块的生命周期，从而为客户节省大量资金。
该技术本身可供 S3 和 S3 兼容硬件的用户使用，其制造商保证其实施与亚马逊的实施没有不同。 因此，为什么不支持 Azure 的合理问题的答案是——它们具有类似的功能，但它在容器级别而不是单个对象级别工作。 顺便说一句，亚马逊本身有两种模式的对象锁定：合规性和治理。 在第二种情况下，尽管有对象锁定，仍然存在以下可能性：管理员之上的最高管理员和根之上的root，仍然删除数据。 在合规的情况下，一切都钉牢了，任何人都不能删除备份。 甚至亚马逊管理员（根据他们的官方声明）。 这是我们支持的模式。
和往常一样，还有一些有用的链接：
- Про 在每一个细节上。
- 有关的所有信息 处于最佳状态
- О 详细
来源： habr.com