Enable One-Way Server-Side Bucket Replication

MinIO Server-Side Replication Requires a MinIO Cluster as the Destination

MinIO server-side replication only works between MinIO clusters. Both the source and destination clusters must run MinIO.

To configure replication between arbitrary S3-compatible services, use mc mirror.

Enable Versioning on Source and Destination Buckets

MinIO relies on the immutability protections provided by versioning to synchronize objects between the source and replication target.

Use the mc version enable command to enable versioning on both the source and destination bucket before starting this procedure:

mc version enable ALIAS/PATH

• Replace ALIAS with the alias of the MinIO cluster.

• Replace PATH with the bucket on which to enable versioning.

Install and Configure mc with Access to Both Clusters.

This procedure uses mc for performing operations on both the source and destination MinIO cluster. Install mc on a machine with network access to both source and destination clusters. See the mc Installation Quickstart for instructions on downloading and installing mc.

Use the mc alias command to create an alias for both MinIO clusters. Alias creation requires specifying an access key for a user on the cluster. This user must have permission to create and manage users and policies on the cluster. Specifically, ensure the user has at minimum:

• admin:CreateUser

• admin:ListUsers

• admin:GetUser

• admin:CreatePolicy

• admin:GetPolicy

• admin:AttachUserOrGroupPolicy

Required Permissions

Bucket Replication requires at minimum the following permissions on the source and destination clusters:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "admin:SetBucketTarget",
                "admin:GetBucketTarget"
            ],
            "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"
        }
    ]
}

{
    "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"
        }
    ]
}

MinIO strongly recommends creating users specifically for supporting bucket replication operations. See mc admin user and mc admin policy for more complete documentation on adding users and policies to a MinIO cluster.

Replication of Existing Objects

Starting with mc RELEASE.2021-06-13T17-48-22Z and minio RELEASE.2021-06-07T21-40-51Z, MinIO supports automatically replicating existing objects in a bucket.

MinIO requires explicitly enabling replication of existing objects using the mc replicate add --replicate or mc replicate edit --replicate and including the existing-objects replication feature flag. This procedure includes the required flags for enabling replication of existing objects.

Replication of Delete Operations

MinIO supports replicating delete operations onto the target bucket. Specifically, MinIO can replicate versioning Delete Markers and the deletion of specific versioned objects:

• For delete operations on an object, MinIO replication also creates the delete marker on the target bucket.

• For delete operations on versions of an object, MinIO replication also deletes those versions on the target bucket.

MinIO requires explicitly enabling replication of delete operations using the mc replicate add --replicate or mc replicate edit --replicate. This procedure includes the required flags for enabling replication of delete operations and delete markers.

Replication of Encrypted Objects

MinIO supports replicating objects encrypted with automatic Server-Side Encryption (SSE-S3). Both the source and destination buckets must have automatic SSE-S3 enabled for MinIO to replicate an encrypted object.

As part of the replication process, MinIO decrypts the object on the source bucket and transmits the unencrypted object. The destination MinIO cluster then re-encrypts the object using the destination bucket SSE-S3 configuration. MinIO strongly recommends enabling TLS on both source and destination clusters to ensure the safety of objects during transmission.

MinIO does not support replicating client-side encrypted objects (SSE-C).

Replication of Locked Objects

MinIO supports replicating objects held under WORM Locking. Both the source and destination buckets must have object locking enabled for MinIO to replicate the locked object.

You must enable object locking during bucket creation as per S3 behavior. You can then configure object retention rules at any time. Object locking requires versioning and enables the feature implicitly.

1) Configure User Accounts and Policies for Replication

This step creates users and policies on both MinIO clusters for supporting replication operations. You can skip this step if both clusters already have users with the necessary permissions.

The following examples use Alpha and Baker as placeholder aliases for each MinIO cluster. You should replace these values with the appropriate aliases for the MinIO clusters on which you are configuring bucket replication. These examples assume that the specified aliases have the necessary permissions for creating policies and users on both clusters. See User Management and MinIO Policy Based Access Control for more complete documentation on MinIO users and policies respectively.

A) Create Replication Administrator

The following code creates a user and policy for supporting configuring replication on the Alpha cluster. Replace the password LongRandomSecretKey with a long, random, and secure secret key as per your organizations best practices for password generation.

wget -O - https://docs.min.io/minio/baremetal/examples/ReplicationAdminPolicy.json | \
mc admin policy add Alpha ReplicationAdminPolicy /dev/stdin
mc admin user add Alpha alphaReplicationAdmin LongRandomSecretKey
mc admin policy set Alpha ReplicationAdminPolicy user=alphaReplicationAdmin

B) Create Remote Replication User

The following code creates a user and policy for supporting synchronizing data into the Baker cluster. Replace the password LongRandomSecretKey with a long, random, and secure secret key as per your organizations best practices for password generation.

wget -O - https://docs.min.io/minio/baremetal/examples/ReplicationRemoteUserPolicy.json | \
mc admin policy add Baker ReplicationRemoteUserPolicy /dev/stdin
mc admin user add Baker bakerReplicationRemoteUser LongRandomSecretKey
mc admin policy set Baker ReplicationRemoteUserPolicy user=bakerReplicationRemoteUser

2) Configure mc Access to the Source and Destination Cluster

Use the mc alias set command to add an alias for both source and destination MinIO clusters.

Use the mc alias set command to add a replication-specific alias for both remote clusters:

mc alias set AlphaReplication HOSTNAME AlphaReplicationAdmin LongRandomSecretKey
mc alias set BakerReplication HOSTNAME BakerReplicationUser LongRandomSecretKey

3) Create a Replication Target for the Destination Cluster

Use the mc admin bucket remote command to create a replication target for the destination cluster. MinIO supports one remote target per destination bucket. You cannot create multiple remote targets for the same destination bucket.

mc admin bucket remote add AlphaReplication/SOURCEBUCKET \
   https://bakerReplicationRemoteUser:LongRandomSecretKey@HOSTNAME/DESTINATIONBUCKET
   --service "replication"
   [--sync]

• Replace SOURCEBUCKET with the name of the source bucket on the Alpha cluster.

• Replace HOSTNAME with the URL of the Baker cluster.

• Replace DESTINATIONBUCKET with the name of the target bucket on the Baker cluster.

• Specify the --sync option to enable synchronous replication. Omit the option to use the default of asynchronous replication. See the reference documentation for --sync for more information on synchronous vs asynchronous replication.

The command returns an ARN similar to the following:

Role ARN = 'arn:minio:replication::<UUID>:DESTINATIONBUCKET'

Copy the ARN string for use in the next step.

4) Create a New Bucket Replication Rule

Use the mc replicate add command to add the new server-side replication rule to the source MinIO cluster.

mc replicate add AlphaReplication/SOURCEBUCKET \
   --remote-bucket DESTINATIONBUCKET \
   --arn 'arn:minio:replication::<UUID>:DESTINATIONBUCKET' \
   --replicate "delete,delete-marker,existing-objects"

• Replace SOURCEBUCKET with the name of the bucket from which Alpha replicates data. The name must match the bucket specified when creating the remote target in the previous step.

• Replace the DESTINATIONBUCKET with the name of the Baker bucket to which Alpha replicates data. The name must match the bucket specified when creating the remote target in the previous step.

• Replace the --arn value with the ARN returned in the previous step. Ensure you specify the ARN created on the Alpha cluster. You can use mc admin bucket remote ls to list all remote ARNs configured on the cluster.

• The --replicate "delete,delete-marker,existing-objects" flag enables the following replication features:

  • Replication of Deletes

  • Replication of existing Objects

  See mc replicate add --replicate for more complete documentation. Omit these fields to disable replication of delete operations or replication of existing objects respectively.

Specify any other supported optional arguments for mc replicate add.

5) Validate the Replication Configuration

Use mc cp to copy a new object to the source bucket.

mc cp ~/foo.txt Alpha/SOURCEBUCKET

Use mc ls to verify the object exists on the destination bucket:

mc ls Baker/DESTINATIONBUCKET

If the remote target was configured without the --sync option, the destination bucket may have some delay before it receives the new object.