备份领域已经进入了一个全新的时代，传统的解决方案仍然有用，但规模、变化速度和应用环境需要不同的、根本不同的方法。本文旨在阐述这个新世界的挑战，界定分界线，以及如何考虑构建一个能够实现云原生规模的数据保护框架。

我们不会给出需要用云规模复制解决方案重新考虑传统备份方法的确切数字，但它确实存在，仅仅是因为你无法备份或恢复超过一定大小的数据。不过，我们的目标是根据我们看到客户及其社区正在做的事情，为他们提供一个合理的框架。它将涵盖备份和恢复到对象存储，以及放弃备份而采用复制。

首先， **带宽是最重要的考虑因素。** 你的专用备份网络将决定何时需要从传统备份方法转向大规模方法。

所有对象存储都是面向吞吐量的。有些 比其他更强大。这意味着他们希望获得最快的网络。在我们的基准测试中，我们几乎总是将网络最大化。如果你的对象存储没有谈论网络速度，暗示一下，那是因为它们并不快。以 MinIO 为例，考虑 100 GbE - 即使在备份/恢复架构中（因为让企业恢复运行是首要目标，对吧？）。

其次，市面上有一些很棒的备份软件。我们与它们都合作，并且在我们的博客上发布了关于 Veeam、 Commvault 和 Velero 的文章，仅举几例。这些软件不仅仅是确保数据从 A 点备份到 B 点 - 它们还有去重、索引、编目、压缩、安全恢复等等功能。这些软件旨在通过增量复制、更改块跟踪等方式优化带宽。

应用类型、规模和变异速度的现代挑战在某个点之后会造成真正的问题。请查看下面的表格。

结论是，超过 1PB，你将需要 24 小时或更长时间才能完成备份/恢复。这同样假设有 100GbE **专用** 带宽用于此任务。即使考虑了备份供应商可以应用的去重、压缩、更改块跟踪等巧妙技巧，你可能也无法超过 2PB。

对于绝大多数公司来说，这完全没问题。这就是备份供应商拥有如此多客户的原因。他们没有 2PB 的数据，或者将数据仔细地切分成不同的备份。

**最佳实践 #1** - 如果你的数据量很小或较小（<1PB），你可以使用传统的备份软件将数据备份和恢复到 MinIO（现在所有供应商都将对象存储视为最佳备份位置）。MinIO 的内置工具（mc mirror 或复制）也是有效的，但它们无法提供上面概述的一些核心功能。确保你有足够的带宽来应对问题时进行恢复。

越过红线

但是对于拥有多个 PB 数据的企业呢？正如你所料，这需要采用不同的方法。这需要使用主动-主动的多站点复制。通过这种方法，企业可以以一种可管理且可持续的方式实现 3-2-1 的备份理念。

使用 **主动-主动多站点复制** 方法，你可以建立三个站点（如果你选择遵循 3-2-1）。第一个站点是主站点。第二个站点在地理位置上是远程的，第三个站点也是如此。这些站点可以位于本地、托管数据中心或公有云中。使用 MinIO，你不必担心架构上的区别 - MinIO 可以运行在你希望的任何地方。你只需要担心带宽和配置。

多个站点解决了异地备份要求。

在构建这些系统时，会有初始启动，然后是持续管理。初始启动将取决于数据量和带宽。这可能需要一周或更长时间，具体取决于数据量。从那时起，它将持续不断地运行，并且无缝衔接。

在此架构中，如果主站点出现故障，负载均衡器将指向辅助源。辅助源将继续备份到三级源。没有数据丢失。

这里有一些需要注意的功能/能力。

主动-主动复制是为那些寻求多主拓扑、快速热热故障转移和多地理位置恢复能力的组织设计的。将多站点复制想象成网状网络 - 每个桶都与多个网状节点同步。这进一步提高了 MinIO 复制的灵活性，使其能够满足那些在多数据中心或多区域同步方面有更复杂要求的组织的需求。

多站点复制从配置哪些桶需要复制开始。

多站点复制支持复制删除操作、删除标记、现有对象和副本元数据更改。

MinIO 可以复制

• 对象及其元数据（在 MinIO 中与对象原子写入）。这些对象可以被加密或未加密。这受限于上面关于旧对象的约束。所有者需要具有相应的权限。
• 对象版本。
• 对象标签，如果有的话。
• S3 对象锁定保留信息，如果有的话。需要注意的是，源的保留信息将覆盖复制端上的任何信息。如果没有保留信息，对象将采用目标桶上的保留期限。有关对象锁定的更多信息，请查看这篇博客文章或 文档。

一些巧妙的功能

• 源和目标桶可以具有相同的名称。这对应用程序在没有任何中断的情况下透明地故障转移到远程站点特别重要。负载均衡器或 DNS 只是将应用程序流量指向新站点。如果远程桶使用不同的名称，则无法建立透明故障转移功能。这对 Splunk 或 Veeam 等企业应用程序来说是一个至关重要的可用性要求。
• MinIO 还支持在源和目标桶之间以开箱即用的方式自动复制对象锁定/保留功能。这与其他实现形成鲜明对比，在其他实现中，管理起来非常困难。
• MinIO 不需要为 AccessControlTranslation、Metrics 和 SourceSelectionCriteria 进行配置/权限 - 大大简化了操作，减少了出错的机会。
• MinIO 使用近乎同步复制，在桶上发生任何变异后立即更新对象。其他供应商可能需要长达 15 分钟才能更新远程桶。 MinIO 在数据中心内遵循严格一致性，并在数据中心之间遵循最终一致性，以保护数据。复制性能取决于 WAN 连接的带宽和变异速率。只要有足够的带宽，更改将在提交后立即传播。版本控制功能使 MinIO 能够像一个不可变的数据存储一样，轻松地合并主动-主动配置中的更改。能够无延迟地推送更改对于在数据中心完全发生故障的情况下保护企业数据至关重要。
• MinIO 还扩展了通知功能，以推送复制故障事件。应用程序可以订阅这些事件并提醒运维团队。有关这方面的文档可以在 这里找到。

架构注意事项

多站点复制与双向主动-主动复制共享基本注意事项，但对延迟有一些额外的考虑。

**硬件：** MinIO 建议在参与多站点复制配置的所有部署中使用相同的硬件。每个具有异构硬件配置的 MinIO 部署都会增加复杂性，并减缓潜在问题的识别速度。这是一个最佳实践，而不是硬性规则，我们承认这可能很难保证 - 特别是如果其中一个端点是云存储服务。

**网络：** 参与多站点桶复制的每个 MinIO 部署都会增加复制配置中所有其他部署的带宽和吞吐量要求。确保整个网络 - NIC、跨站点 WAN、交换机和电缆本身 - 提供 **比** 复制站点之间所需数据量更多的吞吐量和带宽。

**延迟：** 多站点复制对延迟更加敏感，因为 MinIO 不会将对象视为已复制，除非它已同步到 **所有** 配置的远程目标。因此，复制延迟由复制网格中最 **慢** 的链路决定。

**规模：** 多站点复制规模的主要限制是参与配置的每个 MinIO 部署的管理开销。每个 MinIO 部署都是一个独立的对象存储服务 - 复制只在配置的桶之间同步 **对象**。管理员仍然负责同步服务器级配置，例如身份和访问管理或网络入站。

**最佳实践 #2** - 超过 1PB，我们建议使用主动-主动的多站点复制。我们还建议获得商业许可，让 MinIO 在系统架构和部署过程中陪伴在您身边。主动-主动比备份更昂贵，但比数据丢失更便宜。

使用持续数据保护实现类似 Time Machine 的行为

持续数据保护 (CDP) 使企业能够从您选择的任何时间点恢复数据。对于文件和块方法而言，大规模的 CDP 极具挑战性。

使用 MinIO，用户可以回到对象在任何时间点的状态；由于每个更改都会自动进行版本控制，因此“恢复”快照的概念变得无关紧要，因为它已经存在。

持续数据保护利用了 MinIO 的 版本控制功能。版本控制在存储桶级别启用，并为对象的每个版本创建唯一的版本 ID。当写入对象的新的版本时，对象的新旧版本都会存在，每个版本都有其自己的唯一标识符。只需删除旧版本的删除标记，就可以快速轻松地按需公开单个对象的旧版本。       

启用版本控制后，MinIO 会跟踪每个操作，并且永远不会覆盖任何对象。您可以使用 MinIO 控制台、MinIO 客户端 (mc) 或 SDK 来应用版本控制并使用不同版本的对象。

只有管理员和具有相应权限的用户才能更改版本控制配置。一旦为存储桶启用版本控制，就不能禁用版本控制，只能暂停版本控制。

版本控制存在权衡 - 虽然它可以保护数据免受意外操作的影响，但会导致存储桶大小增加，因为存储桶会保存对象的多个版本。可以使用生命周期管理来删除不再需要的对象版本，从而缓解这种情况。MinIO 生命周期管理工具是一种基于策略的方法，它决定数据在被删除之前在磁盘上保留多长时间 - 但这将留待以后的博文再讨论。

最佳实践 #3 - 备份是更大数据保护和数据管理方程中的一个变量。将备份与数据生命周期管理结合起来，以控制成本和复杂性。

数据生命周期管理选项

如果架构师打算遵守 3-2-1 计划 - 他们应该使用不同的介质类型。MinIO 支持 NVMe、SSD、HDD，因此这应该不是问题。将多站点、主动-主动复制与数据生命周期管理结合起来，从昂贵的快速驱动器分层到便宜的慢速驱动器，或者通过 ILM 功能分层到公共云上的廉价存储。这很容易配置。

现在都一起

让我们总结一下

始终考虑您的带宽。过度配置。这与您的架构选择无关。

小数据（小于 1PB）。使用您选择的备份供应商并将数据备份到对象存储 (MinIO)。一个不变的真理 - 您的数据会增长。确保您将其放到可扩展的东西上。

中到大数据 (1-2PB+)。将大量数据传统备份到 MinIO 将不起作用（并且在数百 TB 之前的 SAN/NAS 设备中就不再起作用了）。转向复制。根据组织的需求，可以是双站点或多站点。不要忘记您的带宽。