如何从 AWS S3 迁移到 MinIO

云回迁是我们经常被问到的一个问题。人们认为公有云是一个非常有用的地方，充满了弹性可用的服务，因此它极大地加速了企业采用云原生技术的步伐。然而，公有云在提高生产力的同时也会增加成本，特别是对于数据密集型应用程序来说，出站费用可能会大幅增加。如果你的公有云中存储着超过一个PB的数据，那么经济效益可能更倾向于回迁到本地私有云。我们在之前的一篇博客文章中讨论了云数据回迁的趋势，云的生命周期。

企业已经将许多EB的数据回迁到了本地 MinIO，无论是裸机还是 Kubernetes。大多数企业都在 Kubernetes 上运行，充分利用 MinIO 的容器化架构。他们在本地、边缘，以及他们需要云原生对象存储的任何地方运行多个 Kubernetes 集群，覆盖多云环境。

这篇文章将讨论将数据从 AWS S3 迁移到本地 MinIO 所需的步骤。

成本估算

使用与公有云相同的技术，私有云是扩展的理想选择，包括 S3 API 兼容的对象存储、高速网络、Kubernetes、容器和微服务，但没有高昂的每月费用。

我们在之前的一篇博客文章中进行了 TCO 分析，云的生命周期，它表明 MinIO 比公有云便宜 61%（每月 23.10 美元/TB 对比每月 58.92 美元/TB），用于 100PB 的对象存储。该模型将 AWS 成本（标准 S3 包括每月数据传输成本、区域间复制、S3 API 操作、KMS、生命周期成本）与私有云上的 MinIO 成本（硬件、MinIO 许可证、存储效率、机架空间、电力、冷却）进行了比较。

整个过程中最昂贵的环节可能是从 AWS 中提取数据的费用。从 AWS 出站到互联网的传输成本在每 GB 5 美分到 9 美分之间。一些快速计算可以帮助你进行预算，例如，将 500TB 的数据从 us-west-01 的 S3 迁移到位于 Redwood City，CA 的本地 MinIO 的粗略估计成本约为 30000 美元。

你可以选择只将 S3 数据的热数据层下载到 MinIO，并将冷数据层发送到 S3 Glacier，而不是下载它们。这将大大降低出站费用的成本，并且根据留在 AWS 中的数据量，你可以节省相当多的成本。例如，如果我们总共有 500TB 的数据，将 250TB 传输到 S3 Glacier，并将 250TB 传输到 MinIO，则数据传输费用将大致减少一半，降至 16000 美元，而 S3 Glacier 的月费约为 300 美元。将数据分层到低成本的云存储中，使得在自己的数据中心运行 MinIO 成为对象存储更具吸引力的选择。

当然，你对组织的云成本更加熟悉，应该进行自己的分析。希望我们能提供一个框架来帮助你分析成本。

部署 MinIO

MinIO 是全球性能最高的对象存储（32 个 NVMe 节点上的 GET 速度为 349 GB/s，PUT 速度为 177 GB/s），能够支持最苛刻的数据湖、分析和AI/ML 工作负载。数据以强一致性写入 MinIO，并使用不可变对象。所有对象都受行内擦除编码、比特腐烂哈希和加密保护。

若要确定支持本地 MinIO 部署所需的硬件，请参阅我们的参考硬件页面。

若要将 MinIO 部署到裸机 Linux 上，请参阅部署 MinIO：多节点多驱动 — MinIO 对象存储 for Linux。

若要将 MinIO 部署到 Kubernetes 上，请参阅MinIO 对象存储 for Kubernetes。

回迁所需的规划和配置

提前进行一些规划可以帮助你在数据迁移过程中避免服务中断。为了将配置从 S3 迁移到 MinIO，你首先需要了解组织是如何配置 S3 的。

首先，记录你想要迁移到 MinIO 的当前 S3 中的存储桶。接下来，使用 MinIO 控制台或 mc（MinIO 客户端）在 MinIO 中创建这些存储桶。

接下来，在 AWS 控制台或客户端中，你必须了解并列出所有与 IAM 相关的和与存储桶元数据相关的 信息，以便在 MinIO 中重新创建它们。记录所有你将从 AWS 迁移到数据中心的 IAM 策略，包括用户、组、服务帐户、用户映射、组映射、服务帐户映射和服务组映射。然后，使用 MinIO 控制台或 mc 在 MinIO 中创建它们。

如果你为 S3 生命周期规则配置了通知和分层，那么你也必须确保在 MinIO 中重新创建它们。

开始回迁

首先，确保你在 S3 中设置了 IAM 策略，该策略仅允许访问你正在迁移的存储桶。保存凭证，我们稍后将使用它们来创建别名。

你可以使用批处理复制或 mc mirror 将对象的最新版本从 S3 复制到 MinIO。

通过创建别名可以简化这两个选项。首先，下载 mc

接下来，为你在本地部署的 MinIO 集群创建一个别名，将变量替换为你在部署期间设置的值。

接下来，为存储数据的 S3 存储桶创建一个别名，将变量替换为你在部署期间设置的值。

使用S3 到 MinIO 批量复制，在 RELEASE.2023-05-04T21-44-30Z 版本中引入，它是一种高效且快速的方案，因为它只是简单地将对象的最新版本及其元数据进行单向复制。唯一的缺点是，目标对象无法保留其版本 ID 和修改时间。这是一种将数据从 S3 兼容的源（包括 AWS S3）迁移到 MinIO 的好方法。您还可以配置 S3-MinIO 批量复制，以对存储在 S3 中的对象进行重复的特定时间点复制。

批量复制与 mc mirror（下面描述）相比具有以下几个优势：

• 消除了客户端到集群网络作为潜在的吞吐量瓶颈
• 用户只需要启动批量作业的权限，而不需要访问数据本身的权限
• 如果作业失败，系统会自动重试
• 批量作业提供对复制的精细控制

配置和运行批量复制的用户帐户必须包含以下策略

{
            "Effect": "Allow",
            "Action": [
                "admin:CancelBatchJob",
                "admin:DescribeBatchJob",
                "admin:ListBatchJobs",
                "admin:StartBatchJob"
            ]
        }

第一步是创建和自定义 YAML 描述文件

然后编辑 replication.yaml 以配置复制作业，包括凭据、端点、源存储桶、过滤器/标志和目标存储桶。源存储桶都在 S3 上，目标存储桶都在 MinIO 上。

replicate:
apiVersion: v1
# source of the objects to be replicated
source:
type: TYPE # valid values are "s3"
bucket: BUCKET
prefix: PREFIX
# NOTE: if source is remote then target must be "local"
# endpoint: ENDPOINT
# credentials:
#   accessKey: ACCESS-KEY
#   secretKey: SECRET-KEY
#   sessionToken: SESSION-TOKEN # Available when rotating credentials are used
# target where the objects must be replicated
target:
type: TYPE # valid values are "s3"
bucket: BUCKET
prefix: PREFIX
# NOTE: if target is remote then source must be "local"
# endpoint: ENDPOINT
# credentials:
#   accessKey: ACCESS-KEY
#   secretKey: SECRET-KEY
#   sessionToken: SESSION-TOKEN # Available when rotating credentials are used
# optional flags based filtering criteria
# for all source objects
flags:
filter:
newerThan: "7d" # match objects newer than this value (e.g. 7d10h31s)
olderThan: "7d" # match objects older than this value (e.g. 7d10h31s)
createdAfter: "date" # match objects created after "date"
createdBefore: "date" # match objects created before "date"
## NOTE: tags are not supported when "source" is remote.
# tags:
#   - key: "name"
#     value: "pick*" # match objects with tag 'name', with all values starting with 'pick'
## NOTE: metadata filter not supported when "source" is non MinIO.
# metadata:
#   - key: "content-type"
#     value: "image/*" # match objects with 'content-type', with all values starting with 'image/'
notify:
endpoint: "https://notify.endpoint" # notification endpoint to receive job status events
token: "Bearer xxxxx" # optional authentication token for the notification endpoint
retry:
attempts: 10 # number of retries for the job before giving up
delay: "500ms" # least amount of delay between each retry

您需要为想要镜像的每个 S3 存储桶创建配置文件。好消息是，您可以同时运行多个批量复制作业，并在每个作业完成后收到通知。

使用以下命令启动批量复制

mc batch start minio1/ ./replication.yaml
Successfully start 'replicate' job `E24HH4nNMcgY5taynaPfxu` on '2023-06-26 17:19:06.296974771 -0700 PDT'

您可以查看批量作业的状态

mc batch status minio1/ E24HH4nNMcgY5taynaPfxu
●∙∙
Objects:        28766
Versions:       28766
Throughput:     3.0 MiB/s
Transferred:    406 MiB
Elapsed:        2m14.227222868s
CurrObjName:    share/doc/xml-core/examples/foo.xmlcatalogs

或者，您也可以使用 MinIO 客户端并运行 mc mirror，这是一个功能强大且灵活的数据同步工具。您可以使用它将 S3 或 S3 API 兼容存储中的对象复制到 MinIO，并将其镜像到 MinIO。您即将执行的操作，即从 S3 镜像到 MinIO，是该命令最常见的用例之一。

使用mc mirror 将数据从 S3 复制到 MinIO，并为每个存储桶重复此操作。您可以以编程方式一起执行所有镜像命令。

所需时间取决于数据量、网络速度以及站点之间的物理距离。如果您要迁移 500TB 数据，可能需要 24 小时，而 petabyte 级别的数据则需要几天。mc 完成所有对象的复制后，您将看到一条消息。

无论您使用的是批量复制还是 mc mirror，您都可以比较存储桶内容以验证源和目标是否包含相同对象。如果存储桶包含相同对象，以下命令将不会返回任何内容。

mc diff aws-s3/mybucket minio1/mybucket

唯一剩下的任务是将应用程序配置中指向 S3 端点的引用替换为指向 MinIO 端点的引用。由于 MinIO 拥有业界领先的S3 兼容性，您的应用程序永远不会意识到它们不是在 S3 上运行。

如果您想离开 AWS，但不想购买自己的硬件，请咨询将 S3 迁移到 Equinix Metal 上的 MinIO。

将数据迁移回本地 MinIO

本博文向您展示了如何计划和将数据从 AWS S3 迁移回本地 MinIO。企业进行这种迁移有很多原因，例如控制云支出、增强基础设施控制、改善本地性能等等。无论出于何种原因，重要的是您将要控制自己的对象存储部署。
如果您有任何关于从 AWS S3 迁移到本地 MinIO 的问题，或者只是想对您的迁移计划进行合理性验证，请随时通过Slack 与我们联系。