在备份和恢复领域,一个有趣的动态正在兴起。随着数据量的增长,即使是最复杂的备份供应商也难以提供可接受的恢复时间目标 (RTO) 和恢复点目标 (RPO)。
这个问题开始出现的具体数据量取决于许多不同的因素,但在约 10PB 左右开始变得棘手。在这个数据量下,遍历数据进行备份变得不可行,恢复时间也超出了系统恢复到运行状态的合理范围。您被迫以更小的增量来处理数据。
尽管如此,您仍然需要保护您的数据,毕竟它是现代企业的心脏。那么,策略是什么呢?
策略是将对象存储上的版本控制和复制相结合。正确实现后,可以将您的 RPO 和 RTO 时间缩短至零。
没错,RTO 为零,RPO 也为零。
更重要的是,无论是 1PB、10PB 还是 100PB,RTO 和 RPO 始终为零。
以下是其工作原理。我们将从通过版本控制实现持续数据保护开始,然后跨区域/数据中心/可用区复制这些数据,以便在任何一个位置出现故障时,系统能够故障转移到第二个站点(或者在多站点情况下是第三个、第四个站点)。
不变性和版本控制
不变性是对象存储的核心原则——一旦写入,对象就无法更改。使用 MinIO,对对象的所有操作都是原子的,并且在启用版本控制时,任何对象都不会丢失。
典型的工作流程包括用户或应用程序从 MinIO 服务器获取对象,在本地修改它,然后将新版本上传回服务器。原始对象成为系统记录的一部分,因为它无法修改,并且随着每个新版本的保存,可以回滚更改以使用以前的版本。这也会使较新的版本保持完整,因为即使添加了更新的版本也是如此。
MinIO 将此称为持续数据保护。
为了保持 API 一致性,MinIO 遵循亚马逊 S3 的结构/实现。当写入对象的每个新版本时,都会为其分配一个唯一的版本 ID。应用程序可以指定版本 ID 以访问特定时间该对象的特定版本。MinIO 在同一个存储桶中保留对象的多个变体,并提供了一种机制来保留、检索和同时恢复存储在存储桶中的每个对象的每个版本。
MinIO 版本控制不依赖于卷级快照。快照根本无法扩展。当您创建整个卷的完整时间点副本时,回滚到对象的先前版本需要读取整个卷的快照才能获取特定对象。一些存储供应商将快照链接在一起,因此必须按顺序恢复它们。此过程类似于搜索整个图书馆的多个版本以仅找到一篇特定文章——它既缓慢又痛苦。
MinIO 使用删除标记来防止意外删除。当删除版本化对象时,它不会从系统中删除。而是,会创建一个删除标记,并成为该对象的当前版本。当请求该对象时,MinIO 会返回 404 未找到消息。删除删除标记将取消删除对象。类似地,如果写入对象的新的版本,则对象的新旧版本都存在,每个版本都有其自己的唯一标识符。只需删除其删除标记,就可以根据需要快速轻松地公开各个对象的旧版本。
启用版本控制后,MinIO 会跟踪每个操作,并且永远不会覆盖任何对象。您可以使用 MinIO 控制台、MinIO 客户端 (mc)、SDK 或命令行来应用版本控制并使用对象的不同版本。
保护活动数据免受数据损坏
活动数据中出现数据损坏是一个问题,更糟糕的是,您可能会备份损坏的数据,然后您的备份也毫无用处。MinIO 确保活动数据中不会出现数据损坏。这意味着,如果在主存储上发生数据损坏,则损坏的数据将不会“备份”,从而避免了可能导致恢复无法进行的情况。
MinIO 可以使用其复杂的擦除编码动态检测和纠正数据损坏。因此,您永远不会收到损坏的数据,所有副本始终保持干净。
MC 回溯 - 确保每个对象都不丢失
MinIO 包含一个回溯功能,使您能够列出、检查、检索或回滚对象之前的状态。它可以在任何时间点恢复整个命名空间中的所有更改,而无需恢复整个数据。
MC 回溯是一个更高级别的功能,可以应用于大多数 MC 命令集以使用对象的不同版本。--rewind 选项可用于 list、tree、du、cat、head、cp、rm、tag 和 stat,因此您可以使用不同时间点的存储桶和对象,而无需覆盖任何内容。
--rewind 标记可以通过多种方式调用,以便您可以找到要查找的对象的先前版本。--rewind 标记后面可以跟着时间间隔(例如 3d)或特定时间(例如 2020.03.24T10:00),以便使用当时处于活动状态的对象的版本。
如果您确实希望确保没有版本被删除或篡改,则可以使用启用了对象锁定的功能创建存储桶(使用 ./mc mb -l),或稍后使用 ./mc retention 添加它。
保留和锁定是在遭受攻击后进行审计时非常重要的概念。假设有一天您注意到有人未经授权访问您的存储桶。启用对象锁定后,任何版本的任何对象都不会被删除。它们是不变且只读的,因此在攻击中不会被损坏或删除。一旦您了解审计员的法律要求,就可以使用 retention 命令对存储桶设置治理,使其在审计完成之前无法修改。
或者,如果您想节省存储空间,可以根据日期和时间清除对象版本。例如,命令 ./mc rm play/iceberg/ --recursive --versions --rewind 365d 将删除所有对象在 365 天前的所有版本。
主动-主动复制
任何对象存储都应该能够在多个数据中心之间同步数据。它们应该能够支持
- 同一数据中心复制
- 跨数据中心复制
- 同一区域复制
- 跨区域复制
主动-主动复制使组织能够保护其数据,尤其是在大规模数据环境下。它是多主存储拓扑、快速热热故障转移和多地理位置弹性的基石。
MinIO 不仅支持上述场景,还支持多站点主动-主动复制,用于在任意数量的 MinIO 部署之间同步对象。可以将多站点复制视为网状网络——每个存储桶都在多个网状节点之间同步。这进一步提高了 MinIO 复制的灵活性,使其能够满足组织在多数据中心或多区域同步方面更复杂的需求。此处有一篇完整的文章,因此我们不会深入探讨技术细节,但我们想说的是,我们不知道还有其他人拥有此功能。

MinIO 可以复制
- 存储桶和存储桶元数据,例如策略(访问、生命周期等)。
- 对象及其元数据(在 MinIO 中与对象一起原子写入)。这些对象可以是加密的或未加密的。这受上面关于旧对象的约束的限制。所有者需要相应的权限。
- 对象版本。
- 对象标签(如果有)。
- S3 对象锁定保留信息(如果有)。需要注意的是,源的保留信息将覆盖复制端上的任何信息。如果没有保留信息,则对象将采用目标存储桶上的保留期限。有关对象锁定的更多信息,请参阅此博文或文档。
- 身份和访问管理策略和令牌
MinIO 提供三种复制数据的方式。
第一种是站点到站点,第二种是存储桶到存储桶,第三种是存储桶到其他存储(其他与 S3 兼容的对象存储和/或 POSIX 文件系统)。
多站点复制是在站点级别进行的设置,只需配置一次即可。它支持现有和将来的存储桶。所有链接的站点始终保持自动同步,应用程序可以自由地在 MinIO 部署之间进行负载平衡。
存储桶复制是在存储桶级别明确配置的,从而可以灵活地创建高级复制拓扑。每个存储桶可以复制到一个或多个远程存储桶。远程存储桶可以具有相同名称或不同名称,可以是单向或双向的。每个存储桶可以选择不同站点中的不同目标集。存储桶复制可以简单地用作单个存储桶的复制,而不是整个站点的复制。
站点和存储桶复制功能都是服务器端复制。这意味着启用后,服务器会跟踪更改并使用服务器端资源有效地将其推送到远程目标。即使重新引导和重新启动也无关紧要。
存储桶到其他存储的复制是通过使用名为“mc mirror”的类似 rsync 的实用程序进行客户端复制来实现的。客户端复制必须将对象下载到正在运行该工具的单个客户端节点,然后将其重新上传到目标站点。如果重新引导,您必须重新启动实用程序才能继续同步过程。我们仅建议使用此过程将对象复制到第三方对象存储或旧版 (POSIX) 文件系统。
源存储桶和目标存储桶可以具有相同的名称。这对于应用程序在没有任何中断的情况下透明地故障转移到远程站点尤其重要。负载均衡器或 DNS 只需将应用程序流量引导到新站点即可。如果远程存储桶的名称不同,则无法建立透明故障转移功能。
在所有三种情况下,都有一些注意事项。虽然支持异构硬件,但双方都需要具有类似的容量和性能特征(灾难恢复将是一个明显的例外)。
下一个考虑因素是带宽,并且是迄今为止最重要的因素。首先,根据更改率和突发性计算所需的适当带宽。为了保持多个站点同步,您需要使复制带宽与数据到达速率相匹配。如果没有这样做,更改将被排队并最终同步。MinIO 还支持同步复制,但只能以复制链路的速率运行。
您对更高带宽的投资比对更低延迟的投资更重要,因为它将带来更高的投资回报。MinIO 由于其架构,可以容忍长距离(100 毫秒以上延迟)。这对地理复制来说是一个巨大的优势。
如版本控制部分所述,MinIO 还原生支持跨源和目标存储桶的自动对象锁定/保留复制。
MinIO 不需要配置/权限来进行 AccessControlTranslation、Metrics 和 SourceSelectionCriteria,从而大大简化了操作并减少了出错的可能性。
MinIO 使用近同步复制,在存储桶上发生任何更改后立即更新对象。MinIO 在数据中心内遵循严格一致性,并在数据中心之间遵循最终一致性,以保护数据。
但是快照呢?
快照是传统备份策略的核心组成部分。事实证明,这非常有效,当然,前提是您的快照本质上很小。在 SAN 或 NAS 层级创建的快照是只读的,因此备份系统可以慢慢来,因为没有任何变化。即使有很多卷,由于每个卷都很小,因此也是可以管理的。当数据库开始横向扩展时,情况开始发生变化。横向扩展数据库写入多个驱动器。如何以原子方式对所有驱动器进行原子快照?你做不到。
这导致数据库供应商为自己开发了直接在线备份。我们正在与一家这样的企业及其数据库 MariaDB 合作。MariaDB 有自己的备份功能。与客户和 MariaDB 合作,我们能够将性能提高 10 倍。它现在直接备份到 MinIO,并依次进行复制以实现业务连续性。
但是错误怎么办?
唯一比错误更糟糕的事情是传播错误。它发生了。这是不可避免的。有人会删除数据。有人会覆盖数据。MinIO 会有 bug。这些都是合理的计划事项——并且您可以做到。
一些客户独立升级,在对更改感到满意之前,另一侧保持不变。其他人只是有两个站点,其中一个站点是灾难恢复站点,并且只有一路传播。
弹性是一个选择,也是预算和 SLA 之间的权衡。客户有一系列选择可以防止意外发生。
不为人知的秘密……
每个企业都在大肆宣传灾难恢复和业务连续性。这是高管层的优先事项,但很少有人真正了解“现实世界”的 RTO 和 RPO 指标。他们没有能力进行大规模测试。因此,他们保护他们可以测试的东西。不用说,在实际灾难、恶意软件或勒索软件攻击中,这不会进展顺利。
通过站点复制,灾难恢复测试不仅简单明了,而且可以在不产生重大影响的情况下在实时环境中进行。灾难恢复测试可以通过 DNS 重定向和使主服务器脱机来完成。这将允许企业准确地测试切换是否可以无缝进行。
我们与我们在备份领域的合作伙伴一起亲眼目睹了缺乏实际测试的情况。这些企业已准备好保护大规模数据,因为现有解决方案无法保护大规模数据。尽管如此,仍然很容易让自己沉浸在一个知名品牌的舒适毯中。我们想明确一点——领先的备份供应商绝对擅长保护规模低于 10PB 的数据。它们具有出色的功能和特性,并且定价合理。话虽如此,我们与一些企业合作,在受到攻击后,他们花了几个月的时间才恢复正常——而且他们只处理低个位 PB 的数据。
在规模上,保护数据是对象存储的端到端工作。没有其他解决方案。
要了解 MinIO 如何帮助您保护数据,请通过 hello@min.io 联系我们,我们可以讨论合适的解决方案——从 1PB 到 1000PB。