Skip to content

Replicate a bucket to another region

View as Markdown

A replication rule automatically copies every new object written to a source bucket into a destination bucket in the other region. It is also how you move a bucket’s contents to the other region, since a bucket itself stays in the region it was created in.

Both the source and the destination bucket need Object Versioning turned on, and they need to match on encryption: both encrypted, or both unencrypted. A replication rule always crosses regions, so if you need a destination bucket in the other region, create it first.

On the source bucket, open the Actions menu, select Replication Rule, choose the destination region and bucket, and click Save. From then on, every new object written to the source bucket replicates to the destination automatically; objects from before the rule stay in the source only.

Each bucket belongs to one replication rule at most, as its source or its destination: a rule pairs two buckets that are in no other rule.

From the bucket’s Replication Bucket tab, turn the rule off to pause replication without deleting it, or delete it outright.

To confirm everything replicated before relying on the destination bucket, compare the two with an S3-compatible tool; see Connect with the mc client. Once the copy checks out, point your applications at the new bucket; see Point your applications at the new region. Then remove the replication rule, and delete the source bucket if you no longer need it there.

If you turned on Object Versioning for the destination bucket only for replication, you can suspend it there once the rule is removed.

Applications and scripts keep using the old bucket until you change two things in their settings: the endpoint and the bucket name. Each region has its own endpoint:

Region Endpoint
Delhi objectstore.e2enetworks.net
Chennai in-south1-objectstore.e2enetworks.net

How you change them depends on the tool. With the MinIO client, add an alias for the new region, here Chennai:

mc alias set <new-alias-name> https://in-south1-objectstore.e2enetworks.net <access-key> <secret-key>

With s3cmd, change host_base and host_bucket in ~/.s3cfg; with an SDK, change the endpoint URL your code passes to its S3 client. The access key must have a role on the destination bucket; see Generate an access key. List the bucket through the new settings to check they work:

mc ls <new-alias-name>/<destination-bucket-name>

You should see the objects in the destination bucket. Once all your applications use it, the move is done.

If creating the rule failed, see Troubleshooting E2E Object Storage for what each check needs.