存储桶复制

• 1: 设置存储桶复制的要求
• 2: 启用服务端单向存储桶复制
• 3: 启用双向服务端存储桶复制
• 4: 启用多站点服务端存储桶复制
• 5: 从远程副本重新同步存储桶

1 - 设置存储桶复制的要求

存储桶复制使用规则将一个 MinIO 部署中的存储桶内容同步到远端 MinIO 部署中的存储桶。

复制可以通过以下任一方式完成：

• Active-Passive 符合条件的对象会从源存储桶复制到远端存储桶。 远端存储桶上的任何更改都不会反向复制回来。
• Active-Active 任一存储桶中符合条件对象的更改都会以双向方式复制到另一个存储桶。
• Multi-Site Active-Active 任何已设置存储桶复制的存储桶中符合条件对象的更改，都会复制到所有其他存储桶。

在设置这些复制配置之前，请确保满足以下前提条件。

设置存储桶复制所需的权限

要配置和启用复制规则，存储桶复制要求源端和目标端部署具备特定权限。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "admin:SetBucketTarget",
                "admin:GetBucketTarget",
                "admin:ListBatchJobs",
                "admin:DescribeBatchJob",
                "admin:StartBatchJob",
                "admin:CancelBatchJob"
            ],
            "Effect": "Allow",
            "Sid": "EnableRemoteBucketConfiguration"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetReplicationConfiguration",
                "s3:ListBucket",
                "s3:ListBucketMultipartUploads",
                "s3:GetBucketLocation",
                "s3:GetBucketVersioning",
                "s3:GetObjectRetention",
                "s3:GetObjectLegalHold",
                "s3:PutReplicationConfiguration"
            ],
            "Resource": [
                "arn:aws:s3:::*"
            ],
            "Sid": "EnableReplicationRuleConfiguration"
        }
    ]
}

wget -O - https://silo.pgsty.com/extra/examples/ReplicationAdminPolicy.json | \
mc admin policy create TARGET ReplicationAdminPolicy /dev/stdin
mc admin user add TARGET ReplicationAdmin LongRandomSecretKey
mc admin policy attach TARGET ReplicationAdminPolicy --user=ReplicationAdmin

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetReplicationConfiguration",
                "s3:ListBucket",
                "s3:ListBucketMultipartUploads",
                "s3:GetBucketLocation",
                "s3:GetBucketVersioning",
                "s3:GetBucketObjectLockConfiguration",
                "s3:GetEncryptionConfiguration"
            ],
            "Resource": [
                "arn:aws:s3:::*"
            ],
            "Sid": "EnableReplicationOnBucket"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetReplicationConfiguration",
                "s3:ReplicateTags",
                "s3:AbortMultipartUpload",
                "s3:GetObject",
                "s3:GetObjectVersion",
                "s3:GetObjectVersionTagging",
                "s3:PutObject",
                "s3:PutObjectRetention",
                "s3:PutBucketObjectLockConfiguration",
                "s3:PutObjectLegalHold",
                "s3:DeleteObject",
                "s3:ReplicateObject",
                "s3:ReplicateDelete"
            ],
            "Resource": [
                "arn:aws:s3:::*"
            ],
            "Sid": "EnableReplicatingDataIntoBucket"
        }
    ]
}

wget -O - https://silo.pgsty.com/extra/examples/ReplicationRemoteUserPolicy.json | \
mc admin policy create TARGET ReplicationRemoteUserPolicy /dev/stdin
mc admin user add TARGET ReplicationRemoteUser LongRandomSecretKey
mc admin policy attach TARGET ReplicationRemoteUserPolicy --user=ReplicationRemoteUser

关于在 MinIO 部署中添加用户、访问密钥和策略的更完整文档，请参见 mc admin user、mc admin user svcacct 和 mc admin policy。

存储桶复制的对象加密设置需保持一致

MinIO 支持复制使用 SSE-KMS 和 SSE-S3 加密的对象：

• 对于使用 SSE-KMS 加密的对象，MinIO 要求 目标存储桶支持使用与源存储桶对象 加密时 相同的密钥名称 对对象执行 SSE-KMS 加密。
• 对于使用 SSE-S3 加密的对象，MinIO 要求 目标存储桶同样支持 SSE-S3 对象加密，而不考虑密钥名称。

在复制过程中，MinIO 会先在源存储桶上对对象进行 解密，再通过网络传输未加密的 对象。目标 MinIO 部署随后会使用目标端的加密设置重新对该对象进行加密。 因此，MinIO 强烈建议 在源端和目标端部署上都 启用 TLS，以确保对象在传输过程中的安全。

MinIO 不 支持复制客户端加密对象（SSE-C）。

存储桶复制要求使用 MinIO 部署

MinIO 服务端复制仅适用于 MinIO 部署之间。 源端和目标端部署 都必须 运行版本匹配的 MinIO Server。

如需在任意 S3 兼容服务之间配置复制，请使用 mc mirror。

复制要求启用版本控制

MinIO 依赖 版本控制 提供的不可变性保护来支持 复制和重新同步。

使用 mc version info 验证源存储桶和远端存储桶的版本控制状态。 必要时使用 mc version enable 命令启用版本控制。

如果你在源存储桶中将某个前缀或文件夹排除在版本控制之外，MinIO 就无法复制该文件夹 或前缀中的对象。

对象锁定状态需与存储桶复制保持一致

MinIO 支持复制受 WORM 锁定 保护的对象。 两个复制存储桶 都必须 启用对象锁定，MinIO 才能复制被锁定的对象。 对于主动-主动配置，MinIO 建议在两个存储桶上使用 相同的 保留规则，以确保跨站点 行为一致。

根据 S3 的行为要求，你必须在创建存储桶时启用对象锁定。 随后，你可以在任何时候配置对象保留规则。 在开始此过程 之前，请先在状态异常的目标存储桶上配置所需规则。

2 - 启用服务端单向存储桶复制

本页面中的过程会创建一条新的存储桶复制规则，用于将对象从一个 MinIO 存储桶单向复制到另一个 MinIO 存储桶。 这些存储桶既可以位于同一个 MinIO 部署中，也可以位于不同的 MinIO 部署中。

• 如需在 MinIO 存储桶之间配置双向“active-active”复制，请参见 启用双向服务端存储桶复制。
• 如需在 MinIO 部署之间配置多站点“active-active”复制，请参见 启用多站点服务端存储桶复制

要求

复制要求所有参与的集群满足 以下要求。 本过程假定你已经审阅并验证了这些要求。

如需更多详细信息，请参见 存储桶复制要求 页面。

注意事项

点击展开以下任一项：

过程

• 使用命令行配置单向存储桶复制

  • 创建复制远程目标
  • 创建新的存储桶复制规则
  • 验证复制配置

使用命令行 mc 配置单向存储桶复制

本过程使用 别名 SOURCE 和 REMOTE 来引用每个配置了复制的 MinIO 部署。 请将这些值替换为你的目标 MinIO 部署对应的别名。

本过程假定每个别名都对应一个具有 必要复制权限 的用户。

1) 创建新的存储桶复制规则

使用 mc replicate add 命令，为每个 MinIO 部署添加新的复制规则。

mc replicate add ALIAS/BUCKET \
   --remote-bucket 'https://USER:PASSWORD@HOSTNAME:PORT/BUCKET' \
   --replicate "delete,delete-marker,existing-objects"

• 将 ALIAS 替换为源 MinIO 部署的 别名。 该名称 必须 与上一步创建远端目标时指定的存储桶名称一致。

• 将 BUCKET 替换为源部署上要作为复制源的存储桶名称。

• 使用 --remote-bucket 指定 ALIAS/BUCKET 要复制到的远端 MinIO 部署和存储桶。

  USER:PASSWORD 必须对应远端部署上具有 所需复制权限 的用户。

  HOSTNAME:PORT 必须能解析到远端部署上可访问的 MinIO 实例。 BUCKET 必须已存在，并满足其他所有 复制要求。

• --replicate "delete,delete-marker,existing-objects" 标志会启用以下复制功能：

  • 删除复制
  • 现有对象复制

  有关更完整的文档，请参阅 mc replicate add --replicate。 省略任意字段即可禁用对应组件的复制。

可按需为 mc replicate add 指定其他受支持的可选参数。

2) 验证复制配置

在其中一个部署上，使用 mc cp 将新对象复制到已启用复制的存储桶中。

mc cp ~/foo.txt ALIAS/BUCKET

使用 mc ls 验证目标存储桶中存在该对象：

mc ls ALIAS/BUCKET

3 - 启用双向服务端存储桶复制

本页中的过程会创建新的存储桶复制规则，用于在 MinIO 存储桶之间对对象执行双向“主动-主动”同步。

• 如需在任意兼容 S3 的服务之间配置复制，请使用 mc mirror。
• 如需在 MinIO 集群之间配置单向“主动-被动”复制，请参见 启用服务端单向存储桶复制。
• 如需在 MinIO 集群之间配置多站点“主动-主动”复制，请参见 启用多站点服务端存储桶复制。

本教程介绍如何在两个 MinIO 集群之间配置主动-主动复制。有关在三个或更多 MinIO 集群之间进行多站点复制的教程，请参见 启用多站点服务端存储桶复制。

要求

您必须满足 存储桶复制要求 中描述的所有存储桶复制基础要求。

此外，要设置主动-主动存储桶复制，您还必须满足以下附加要求：

访问两个集群

要设置主动-主动存储桶复制，您必须能够通过网络访问两个部署，并拥有具有所需权限的登录凭证。

您可以安装 mc 并通过命令行访问这些部署。 使用 mc alias set 命令为两个 MinIO 部署创建别名。

创建别名时，需要为部署中的某个用户指定 access key。 该用户 必须 具有在该部署上创建和管理用户及策略的权限。

具体而言，请确保该用户 至少 具有以下权限：

• admin:CreateUser
• admin:ListUsers
• admin:GetUser
• admin:CreatePolicy
• admin:GetPolicy
• admin:AttachUserOrGroupPolicy

注意事项

操作步骤

• 使用命令行配置双向存储桶复制

  • 创建复制远程目标
  • 在每个部署上创建新的存储桶复制规则
  • 验证复制配置

使用命令行 mc 配置双向存储桶复制

此过程会在两个 MinIO 部署之间创建双向、主动-主动复制。

此过程假定您已使用具有 所需复制权限 的用户为每个部署定义了别名。

1) 在每个部署上创建新的存储桶复制规则

使用 mc replicate add 命令，为每个 MinIO 部署添加新的复制规则。

mc replicate add ALIAS/BUCKET \
   --remote-bucket 'https://USER:PASSWORD@HOSTNAME:PORT/BUCKET' \
   --replicate "delete,delete-marker,existing-objects"

• 将 ALIAS 替换为源 MinIO 部署的 别名。 该名称 必须 与上一步创建远端目标时指定的存储桶名称一致。

• 将 BUCKET 替换为源部署上要作为复制源的存储桶名称。

• 使用 --remote-bucket 指定 ALIAS/BUCKET 要复制到的远端 MinIO 部署和存储桶。

  USER:PASSWORD 必须对应远端部署上具有 所需复制权限 的用户。

  HOSTNAME:PORT 必须能解析到远端部署上可访问的 MinIO 实例。 BUCKET 必须已存在，并满足其他所有 复制要求。

• --replicate "delete,delete-marker,existing-objects" 标志会启用以下复制功能：

  • 删除复制
  • 现有对象复制

  有关更完整的文档，请参阅 mc replicate add --replicate。 省略任意字段即可禁用对应组件的复制。

可按需为 mc replicate add 指定其他受支持的可选参数。

在另一个 MinIO 部署上重复此步骤。 将 ALIAS 和 --remote-bucket 的值修改为与第一个部署对应。

完成此步骤后，您应已配置两条复制规则：每个部署上一条，并指向另一个部署上的存储桶。 使用 mc replicate ls 命令验证已创建的复制规则。

2) 验证复制配置

在其中一个部署上，使用 mc cp 将新对象复制到已启用复制的存储桶中。

mc cp ~/foo.txt ALIAS/BUCKET

使用 mc ls 验证目标存储桶中存在该对象：

mc ls ALIAS/BUCKET

通过将另一个对象复制到第二个部署，并验证该对象会复制到第一个部署，来重复执行此测试。

当两个对象都存在于两个部署上时，您就已成功在 MinIO 存储桶之间设置了双向、主动-主动复制。

4 - 启用多站点服务端存储桶复制

本页中的过程用于在多个 MinIO 部署之间配置自动化的服务端存储桶复制。多站点 Active-Active 复制基于 启用双向服务端存储桶复制 过程，并增加了额外注意事项，以确保所有站点上的复制行为可预测。

• 如需在任意 S3 兼容服务之间配置复制，请使用 mc mirror。
• 如需在两个 MinIO 部署之间配置单向 “active-active” 复制，请参阅 启用双向服务端存储桶复制。
• 如需在 MinIO 部署之间配置单向 “active-passive” 复制，请参阅 启用服务端单向存储桶复制。

多站点 Active-Active 复制配置可以跨越多个机架、数据中心或地理位置。多站点配置的部署与维护复杂度通常会随着站点数量和每个站点规模的增加而提高。计划实施多站点复制的企业应考虑借助 MinIO SUBNET 支持，以获取应对此类用例所需的专业知识、规划能力和工程资源。

要求

你必须满足 Bucket Replication Requirements 中描述的所有存储桶复制基础要求。

此外，要创建多站点存储桶复制配置，你还必须满足以下额外要求：

访问所有集群

要设置多站点 Active-Active 存储桶复制，你必须具备访问所有部署的网络连通性，以及具有正确权限的登录凭证。

你可以通过安装 mc 并使用命令行访问这些部署。 使用 mc alias set 命令为每个 MinIO 部署创建别名。

创建别名时，需要指定该部署上某个用户的 access key。 该用户 必须 具有在该部署上创建和管理用户及策略的权限。

具体来说，请确保该用户 至少 具有以下权限：

• admin:CreateUser
• admin:ListUsers
• admin:GetUser
• admin:CreatePolicy
• admin:GetPolicy
• admin:AttachUserOrGroupPolicy

注意事项

点击展开以下任意条目：

过程

对于参与多站点复制配置的每个 MinIO 部署，都需要重复执行本过程中的步骤。根据部署数量的不同，该过程在实施时可能需要投入大量时间并格外谨慎。MinIO 建议在尝试执行文档中的步骤之前，先完整阅读本过程。

• 使用命令行配置多站点存储桶复制

  • 创建新的存储桶复制规则
  • 验证复制配置

使用命令行 mc 配置多站点存储桶复制

本过程使用占位符 ALIAS 来引用每个被配置为复制端点的 MinIO 部署的 alias。 请将这些值替换为各个 MinIO 部署对应的实际别名。

本过程假设每个别名都对应一个具备 necessary replication permissions 的用户。

1) 创建新的存储桶复制规则

使用 mc replicate add 命令，为每个 MinIO 部署添加新的复制规则。

mc replicate add ALIAS/BUCKET \
   --remote-bucket 'https://USER:PASSWORD@HOSTNAME:PORT/BUCKET' \
   --replicate "delete,delete-marker,existing-objects"

• 将 ALIAS 替换为源 MinIO 部署的 别名。 该名称 必须 与上一步创建远端目标时指定的存储桶名称一致。

• 将 BUCKET 替换为源部署上要作为复制源的存储桶名称。

• 使用 --remote-bucket 指定 ALIAS/BUCKET 要复制到的远端 MinIO 部署和存储桶。

  USER:PASSWORD 必须对应远端部署上具有 所需复制权限 的用户。

  HOSTNAME:PORT 必须能解析到远端部署上可访问的 MinIO 实例。 BUCKET 必须已存在，并满足其他所有 复制要求。

• --replicate "delete,delete-marker,existing-objects" 标志会启用以下复制功能：

  • 删除复制
  • 现有对象复制

  有关更完整的文档，请参阅 mc replicate add --replicate。 省略任意字段即可禁用对应组件的复制。

可按需为 mc replicate add 指定其他受支持的可选参数。

对于参与多站点复制配置的每个远程 MinIO 部署，都要重复执行这些命令。 例如，一个由 MinIO 部署 minio1、minio2 和 minio3 组成的多站点复制配置，需要在每个部署上针对每个远程端重复执行此步骤。

具体来说，在这种场景下，需要在每个部署上执行两次此步骤：

• 在 minio1 部署上，为 minio2 创建一条规则，再为 minio3 单独创建另一条规则。
• 在 minio2 部署上，为 minio1 创建一条规则，再为 minio3 单独创建另一条规则。
• 在 minio3 部署上，为 minio1 创建一条规则，再为 minio2 单独创建另一条规则。

2) 验证复制配置

在其中一个部署上，使用 mc cp 将新对象复制到已启用复制的存储桶中。

mc cp ~/foo.txt ALIAS/BUCKET

使用 mc ls 验证目标存储桶中存在该对象：

mc ls ALIAS/BUCKET

在每个部署上重复执行此测试：复制一个新的唯一文件，并检查该文件是否已复制到其他每个部署。

你也可以使用 mc stat 检查该文件，以查看对象当前的 replication stage。

5 - 从远程副本重新同步存储桶

本页中的步骤使用健康的复制远端来重新同步 MinIO 存储桶中的内容。重新同步可用于在副本配置下的 MinIO 部署发生部分或全部数据丢失后进行恢复。

例如，考虑如下所示的 MinIO 主动-主动复制配置：

重新同步允许使用其中一个参与复制的 MinIO 部署上的健康数据，作为重建另一个部署的源。

重新同步是按存储桶执行的过程。对于远端中每个遭受部分或全部数据丢失的存储桶，都必须重复执行重新同步。

要求

MinIO 部署必须在线

重新同步要求源部署和目标部署都在线，并且能够接受读写操作。源端 必须 具备到远端的完整网络连通性。

远端部署可以处于“不健康”状态，即发生了部分或全部数据丢失。只要源端和目标端保持连通，重新同步就可以修复这些数据丢失问题。

重新同步要求现有复制配置

重新同步要求健康的源部署已经为不健康的目标存储桶配置好了复制配置。此外，重新同步仅适用于使用 existing object replication 选项创建的那些复制规则。

使用 mc replicate ls 查看健康源存储桶已配置的复制规则和目标。

复制要求对象加密设置匹配

MinIO 支持复制使用 SSE-KMS 和 SSE-S3 加密的对象：

• 对于使用 SSE-KMS 加密的对象，MinIO 要求 目标存储桶支持使用与源存储桶对象 加密时 相同的密钥名称 对对象执行 SSE-KMS 加密。
• 对于使用 SSE-S3 加密的对象，MinIO 要求 目标存储桶同样支持 SSE-S3 对象加密，而不考虑密钥名称。

在复制过程中，MinIO 会先在源存储桶上对对象进行 解密，再通过网络传输未加密的 对象。目标 MinIO 部署随后会使用目标端的加密设置重新对该对象进行加密。 因此，MinIO 强烈建议 在源端和目标端部署上都 启用 TLS，以确保对象在传输过程中的安全。

MinIO 不 支持复制客户端加密对象（SSE-C）。

复制要求使用 MinIO 部署

MinIO 服务端复制仅适用于 MinIO 部署之间。 源端和目标端部署 都必须 运行版本匹配的 MinIO Server。

如需在任意 S3 兼容服务之间配置复制，请使用 mc mirror。

复制要求启用版本控制

MinIO 依赖 版本控制 提供的不可变性保护来支持 复制和重新同步。

使用 mc version info 验证源存储桶和远端存储桶的版本控制状态。 必要时使用 mc version enable 命令启用版本控制。

如果你在源存储桶中将某个前缀或文件夹排除在版本控制之外，MinIO 就无法复制该文件夹 或前缀中的对象。

复制要求对象锁定状态匹配

MinIO 支持复制受 WORM 锁定 保护的对象。 两个复制存储桶 都必须 启用对象锁定，MinIO 才能复制被锁定的对象。 对于主动-主动配置，MinIO 建议在两个存储桶上使用 相同的 保留规则，以确保跨站点 行为一致。

根据 S3 的行为要求，你必须在创建存储桶时启用对象锁定。 随后，你可以在任何时候配置对象保留规则。 在开始此过程 之前，请先在状态异常的目标存储桶上配置所需规则。

注意事项

重新同步需要时间

重新同步是一个后台过程，会持续检查源 MinIO 存储桶中的对象，并在需要时将其复制到远端。完成复制所需的时间会因对象数量和大小、到远端 MinIO 部署的吞吐量以及源 MinIO 部署上的负载而异。由于这些变量的存在，总完成时间通常无法预测。

MinIO 建议在同步完成之前，通过配置负载均衡器或代理，仅将流量导向健康集群。以下命令可帮助了解重新同步状态：

• 在源端执行 mc replicate resync status 以跟踪重新同步进度。
• 在源端和远端执行 mc replicate status 以跟踪正常复制数据。
• 在源端和远端都运行 mc ls -r --versions ALIAS/BUCKET | wc -l，以验证两端的对象总数和对象版本总数。

在数据丢失后重新同步对象

此过程使用现有的 MinIO replication configuration，将缺失数据恢复到参与该配置的某个 MinIO 部署。具体来说，一个健康的 MinIO 部署（即 SOURCE）会将其现有数据同步到不健康的 MinIO 部署（即 TARGET）。

此过程假定 SOURCE 已存在一个 alias，并且该别名具有配置复制所需的 necessary permissions。

你可以对每个需要重新同步的存储桶重复执行此过程。每个存储桶同时最多只能运行一个复制作业。

1) 列出健康源端上已配置的复制目标

运行 mc replicate ls 命令，列出健康 SOURCE 部署上针对需要重新同步的 BUCKET 已配置的远程目标。

mc replicate ls SOURCE/BUCKET --json

• 将 SOURCE 替换为源 MinIO 部署的 alias。
• 将 BUCKET 替换为要作为重新同步源的存储桶名称。

输出类似如下：

{
   "op": "",
   "status": "success",
   "url": "",
   "rule": {
      "ID": "cer1tuk9a3p5j68crk60",
      "Status": "Enabled",
      "Priority": 0,
      "DeleteMarkerReplication": {
         "Status": "Enabled"
      },
      "DeleteReplication": {
         "Status": "Enabled"
      },
      "Destination": {
         "Bucket": "arn:minio:replication::UUID:BUCKET"
      },
      "Filter": {
         "And": {},
         "Tag": {}
      },
      "SourceSelectionCriteria": {
         "ReplicaModifications": {
            "Status": "Enabled"
         }
      },
      "ExistingObjectReplication": {
         "Status": "Enabled"
      }
   }
}

输出中的每个文档都表示一条已配置的复制规则。 Destination.Bucket 字段指定该存储桶上某条规则对应的 ARN。 找出你希望从中重新同步对象的存储桶对应的正确 ARN。

2) 启动重新同步过程

运行 mc replicate resync start 命令以开始重新同步过程：

mc replicate resync start --remote-bucket "arn:minio:replication::UUID:BUCKET" SOURCE/BUCKET

• 将 --remote-bucket 的值替换为 TARGET MinIO 部署上不健康 BUCKET 的 ARN。
• 将 SOURCE 替换为源 MinIO 部署的 alias。
• 将 BUCKET 替换为健康 SOURCE MinIO 部署上的存储桶名称。

该命令会返回一个重新同步作业 ID，表示该过程已经开始。

3) 监控重新同步

在源部署上使用 mc replicate resync status 命令跟踪已接收的复制数据：

mc replicate resync status ALIAS/BUCKET

输出类似如下：

mc replicate resync status /data
Resync status summary:
● arn:minio:replication::6593d572-4dc3-4bb9-8d90-7f79cc612f01:data
   Status: Ongoing
   Replication Status | Size (Bytes)    | Count
   Replicated         | 2.3 GiB         | 18
   Failed             | 0 B             | 0

重新同步过程完成后，Status 会更新为 Completed。

4) 后续步骤

• 如果 TARGET 存储桶的损坏已波及复制规则，则必须重新创建这些规则，使其与之前的复制配置一致。更多指导请参见 启用双向服务端存储桶复制。
• 执行基础验证，确认复制配置中的所有存储桶在 mc ls 和 mc stat 等命令下显示出相近的结果。
• 在恢复所有复制规则并验证站点间复制之后，你可以配置负责管理连接的反向代理、负载均衡器或其他网络控制平面，使其恢复向已重新同步的部署发送流量。