如何以零 RPO 和 RTO 备份和恢复 100PB 数据

备份和恢复领域出现了一种有趣的动态。随着数据的增长 - 它实际上超过了即使是最先进的备份供应商提供可接受的恢复时间目标 (RTO) 和恢复点目标 (RPO) 的能力。

这个问题从哪里开始出现取决于许多不同的因素——但它在 10PB 左右开始变得奇怪。到那时，遍历数据进行备份变得不可行，并且恢复时间超出了将系统恢复到运行状态的合理时间。您被迫以较小的增量进行交易。

仍然 - 您必须保护您的数据，毕竟这是现代企业的心跳。那么策略是什么？

该策略是对象存储上的版本控制和复制的组合。如果实施得当，您的 RPO 和 RTO 时间将变为零。

这对于 RTO 来说是正确的零。RPO 为零。

更重要的是——无论是 1PB、10PB 还是 100PB 都没有关系。它仍然是零。

下面是它的工作原理。我们将从通过版本控制进行持续数据保护开始，然后跨区域/数据中心/区域复制该数据，这样如果出现任何故障，它会故障转移到第二个站点（或者在多站点的情况下是第三个、第四个）。

不变性和版本控制

不变性是对象存储的核心原则——一旦写入，对象就无法更改。使用 MinIO，对象上的所有操作都是原子的，并且在启用版本控制时，不会丢失任何对象。

典型的工作流程涉及用户或应用程序从 MinIO 服务器获取对象，在本地修改它，然后将新版本上传回服务器。原始对象成为记录系统的一部分，因为它无法修改，并且随着每个新版本的保存，可以回滚更改以使用以前的版本。这也使较新的版本保持不变，因为甚至添加了较新的版本。

MinIO 将此称为持续数据保护。

MinIO 遵循 Amazon 的 S3 结构/实现 API 一致性。写入对象的每个新版本时，都会为其分配一个唯一的版本 ID。应用程序可以指定版本 ID 以在特定时间访问该对象的特定版本。MinIO 在同一桶中保留一个对象的多个变体，并提供一种机制来保存、检索和同时恢复存储在桶中的每个对象的每个版本。

MinIO 版本控制不依赖于卷级快照。快照根本无法缩放。当您制作整个卷的完整时间点副本时，回滚到对象的先前版本需要读取整个卷的快照才能到达特定对象。一些存储供应商将快照“链接”在一起，因此必须按顺序恢复它们。这个过程类似于搜索整个图书馆的多个版本只是为了找到一篇文章——既缓慢又痛苦。

MinIO 通过使用删除标记来防止意外删除。删除版本化对象时，它不会从系统中删除。取而代之的是，一个删除标记被创建并成为该对象的当前版本。当请求该对象时，MinIO 返回 404 Not Found 消息。移除删除标记会取消删除对象。类似地，如果写入了对象的新版本，则对象的旧版本和新版本都存在，每个版本都有自己的唯一标识符。只需删除其删除标志，即可根据需要快速轻松地公开单个对象的旧版本。

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

保护实时数据免受 Bitrot

实时数据中有位腐烂是个问题——更糟糕的是你可以备份位腐烂的数据——然后你的备份也毫无用处。MinIO 确保 bitrot 不会在实时数据中发生。这意味着如果主存储发生比特腐烂，损坏的数据将不会被“备份”，从而防止出现无法恢复的情况。

MinIO 可以使用其复杂的擦除编码即时检测和纠正比特腐烂。因此，不存在收到位腐烂数据的风险，并且所有副本将始终是干净的。

MC Rewind - 无遗物

MinIO 包括一个倒带功能，使您能够像以前一样列出、检查、检索或回滚对象。它可以在任何时间点恢复整个命名空间中的每一个更改，而无需恢复它。

MC Rewind 是一个更高级别的功能，可以应用于大多数 MC 命令集以处理对象的不同版本。--rewind 选项可用于 list、tree、du、cat、head、cp、rm、tag 和 stat，因此您可以在不同的时间点处理桶和对象，而不会覆盖任何内容。

--rewind 标志可以通过多种不同的方式调用，因此您可以找到您要查找的对象的先前版本。--rewind 标志后面可以跟一个时间间隔（例如 3d）或特定时间（例如 2020.03.24T10:00），以处理当时处于活动状态的对象的版本。

如果您真的想确保没有版本被删除或篡改，那么您可以使用 ./mc mb -l 创建启用对象锁定的存储桶，或者稍后使用 ./mc retention 添加它。

如果您在攻击后面临审计，保留和锁定是重要的概念。假设有一天您发现有人未经授权访问您的存储桶。启用对象锁定后，对象的任何版本都不会被删除。它们是不可变的和只读的，因此它们不会在攻击中被损坏或删除。了解审计员的法律要求后，您可以使用保留命令对存储桶设置治理，以便在审计完成之前无法修改它。

或者，如果您想节省存储空间，您可以根据日期和时间清除对象版本。例如，命令 ./mc rm play/iceberg/ --recursive --versions --rewind 365d 将删除超过 365 天的所有对象的所有版本。

主动主动复制

在多个数据中心之间同步数据应该是任何对象存储的核心竞争力。他们应该能够支持：

• 同数据中心复制

• 跨数据中心复制

• 同区复制

• 跨区域复制

主动-主动复制使组织能够保护他们的数据——尤其是大规模的。它是多主存储拓扑、快速热-热故障转移和多地域弹性的基石。

MinIO 不仅支持上述场景，它还支持多站点、主动-主动复制，用于在任意数量的 MinIO 部署之间同步对象。将多站点复制想象成一个网状网络——每个桶在多个网状节点之间同步。这进一步提高了 MinIO 复制的灵活性，适用于对多 DC 或多区域同步有更复杂要求的组织。这里有一篇完整的帖子，所以我们不会深入研究技术细节——但我们会说我们不知道其他任何人拥有这种能力。

MinIO 可以复制：

• 存储桶和存储桶元数据，例如策略（访问、生命周期……）

• 对象及其元数据（在 MinIO 中与对象一起自动写入）。这些对象可以是加密的或未加密的。这受制于上述关于旧对象的限制。所有者将需要适当的权限。

• 对象版本。

• 对象标签，如果有的话。

• S3 对象锁定保留信息（如果有）。应该注意的是，源的保留信息将覆盖复制端的任何内容。如果没有保留信息，对象将在目标存储桶上保留一段时间。有关对象锁定的更多信息，请查看此博客文章或文档。

• 身份和访问管理策略和令牌

MinIO 提供了三种复制数据的方式。

第一个是站点到站点，第二个是桶到桶，第三个是桶到其他（其他 S3 兼容对象存储和/或 POSIX 文件系统）。

多站点复制是站点级别的设置，只需配置一次。它支持现有和未来的桶。所有链接的站点始终自动保持同步，并且应用程序可以自由地在 MinIO 部署之间进行负载平衡。

桶复制是在桶级别明确配置的，从而可以灵活地创建高级复制拓扑。每个桶可以复制到一个或多个远程桶。远程桶可以同名或不同名，单向或双向。每个桶可以在不同的站点选择一组不同的目标。桶复制可以像复制单个桶一样简单地使用，而不是整个站点。

站点和存储桶复制功能都是服务器端复制。这意味着一旦启用，服务器就会跟踪更改并使用服务器端资源将它们有效地推送到远程目标。甚至重新启动和重新启动都是无关紧要的。

Bucket-to-other 复制是通过客户端复制实现的，使用名为“mc mirror”的类似 rsync 的实用程序。客户端复制必须将对象下载到运行该工具的单个客户端节点，然后将它们重新上传到目标站点。如果重新启动，您必须重新启动该实用程序才能继续同步过程。我们仅建议此过程将对象复制到第三方对象存储或遗留 (POSIX) 文件系统。

源和目标存储桶可以具有相同的名称。这对于应用程序在没有任何中断的情况下透明地故障转移到远程站点尤为重要。负载平衡器或 DNS 只是将应用程序流量定向到新站点。如果远程存储桶的名称不同，则无法建立透明故障转移功能。

在所有这三种情况下，都有一些注意事项。虽然支持异构硬件，但双方都需要类似的容量和性能特征（灾难恢复将是一个明显的例外）。

下一个考虑因素是带宽，这是迄今为止最重要的因素。首先，花时间根据变化率和突发性计算所需的适当带宽。要保持多个站点同步，您需要使复制带宽与数据到达的速率相匹配。如果不这样做，更改将排队并最终同步。MinIO 也支持同步复制，但只能以复制链接的速度运行。

您对更高带宽的投资比对更低延迟的投资更重要，因为它会给您带来更高的投资回报。由于其架构，MinIO 可以容忍长距离（100 毫秒以上的延迟）。这对于异地复制来说是一个巨大的优势。

如版本控制部分所述，MinIO 还原生支持跨源和目标存储桶的自动对象锁定/保留复制。

MinIO 不需要 AccessControlTranslation、Metrics 和 SourceSelectionCriteria 的配置/许可——显着简化了操作并减少了出错的机会。

MinIO 使用近同步复制在存储桶发生任何变化后立即更新对象。MinIO遵循数据中心内的严格一致性和跨数据中心的最终一致性来保护数据。

但是快照呢？

快照是传统备份策略的核心组成部分。这被证明是非常有效的，当然前提是您的快照本质上很小。在 SAN 或 NAS 级别制作的快照是只读的，因此备份系统可以慢慢来，因为没有任何变化。即使有很多卷，因为每个卷都很小，这是可以管理的。当数据库横向扩展时——事情开始发生变化。横向扩展数据库写入多个驱动器。您如何以原子方式自动快照所有驱动器？你不能。

这导致数据库供应商为自己开发直接在线备份。我们正在与这样的一家企业及其数据库 MariaDB 合作。MariaDB 有自己的备份能力。通过与客户和 MariaDB 合作，我们能够将性能提高 10 倍。它现在直接备份到 MinIO，然后被复制以实现业务连续性。

但是错误呢？

唯一比错误更糟糕的是传播错误。它发生了。这是不可避免的。有人会删除数据。有人会覆盖数据。MinIO 会有一个错误。这些都是合理的计划 - 你可以。

一些客户独立升级，在他们对更改感到满意之前，保留一侧不变。其他人只有两个站点，其中一个是单向传播的 DR 站点。

弹性是预算和 SLA 之间的一种选择和权衡。客户有多种选择来防止事故发生。

肮脏的秘密……

每个企业都在谈论一场围绕灾难恢复和业务连续性的大游戏。这是最高管理层的优先事项，但很少有人真正理解“现实世界”的 RTO 和 RPO 指标。他们没有能力进行大规模测试。所以他们保护他们可以测试的东西。不用说 - 这在实际灾难、恶意软件或勒索软件攻击中并不顺利。

通过站点复制，灾难恢复测试不仅简单明了，而且可以在实时环境中完成而不会产生重大影响。灾难恢复测试可以通过 DNS 重定向和使主服务器脱机来完成。这将使企业能够准确地测试切换是否可以无缝进行。

我们看到缺乏与我们的合作伙伴在备份空间中进行的第一手真实测试。这些企业已准备好大规模保护数据，因为现有解决方案无法大规模保护数据。尽管如此，将自己包裹在知名品牌的舒适毯子中还是很容易的。我们想明确一点——领先的备份供应商在保护 10PB 以下规模的数据方面绝对出色。它们具有出色的特性和功能，而且价格合理。话虽如此，我们与那些在受到损害后需要几个月才能恢复正常的企业合作——而且他们只处理低个位数的 PB。

大规模 - 保护数据是对象存储的端到端工作。没有其他解决办法。

要了解有关 MinIO 如何帮助您保护数据的更多信息，请通过 hello@min.io 与我们联系，我们可以讨论正确的答案可能是什么——从 1PB 到 1,000。