Welcome to the upcoming version of the MinIO Documentation! The content on this page is under active development and may change at any time. If you can't find what you're looking for, check our legacy documentation. Thank you for your patience.

Enable One-Way Server-Side Bucket Replication

The procedure on this page creates a new bucket replication rule for one-way synchronization of objects between MinIO buckets.

Active-Passive Replication synchronizes data from a source MinIO cluster to a remote MinIO cluster.

MinIO server-side replication supports at most two MinIO clusters. Both clusters must run MinIO.

See also

Requirements

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:

Required Permissions

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

The following policy provides permissions for configuring and enabling replication on a cluster.

{
    "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"
        }
    ]
}
  • The "EnableRemoteBucketConfiguration" statement grants permission for creating a remote target for supporting replication.

  • The "EnableReplicationRuleConfiguration" statement grants permission for creating replication rules on a bucket. The "arn:aws:s3:::* resource applies the replication permissions to any bucket on the source cluster. You can restrict the user policy to specific buckets as-needed.

Use the mc admin policy add to add this policy to the source cluster. Use mc admin user add to create a user on the source cluster and mc admin policy set to associate the policy to that new user.

The following policy provides permissions for enabling synchronization of replicated data into the cluster.

{
    "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"
        }
    ]
}
  • The "EnableReplicationOnBucket" statement grants permission for a remote target to retrieve bucket-level configuration for supporting replication operations on all buckets in the MinIO cluster. To restrict the policy to specific buckets, specify those buckets as an element in the Resource array similar to "arn:aws:s3:::bucketName".

  • The "EnableReplicatingDataIntoBucket" statement grants permission for a remote target to synchronize data into any bucket in the MinIO cluster. To restrict the policy to specific buckets, specify those buckets as an element in the Resource array similar to "arn:aws:s3:::bucketName/*".

Use the mc admin policy add to add this policy to the destination cluster. Use mc admin user add to create a user on the destination cluster and mc admin policy set to associate the policy to that new user.

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.

Considerations

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.

Procedure

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:

    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.