Docs

Torch Object Storage

Cross-region replication

Overview

You can use cross-region replication (CRR) to automatically copy objects from one bucket to another in different regions. This feature lets you filter which objects are replicated and monitor their progress.

Use cases

Meeting compliance requirements

With TOS, you can store your data in multiple availability zones within the same region. However, certain industries may have compliance requirements that mandate storing data in different regions. CRR allows you to replicate data across distant regions to meet these requirements.

Data backup and disaster recovery

You can use CRR to back up data in different regions to prevent data loss in the event of a disaster.

Reducing latency

The shorter the distance that data must travel, the lower the latency. With CRR, you can minimize latency by storing copies of your objects in the bucket closest to your customers' locations.

Data migration

CRR is particularly useful in scenarios that require data migration from one TOS region to another.

Meeting operational requirements

If you have compute clusters in two different TOS regions that need to analyze the same set of objects, you can use CRR to keep copies of those objects in both regions.

What does CRR replicate?

CRR replicates the following information about objects: content, size, last modified time, creator, version number, user-defined metadata, and storage type. The details are as follows:

What is replicated with CRR?

What is not replicated with CRR?

Objects that exist before the CRR rule takes effect, which will not be synchronized by default.

Objects uploaded after the CRR rule takes effect.

Object overwrite operations.

If an object in the source bucket is overwritten after replication, the overwrite operation will be synchronized again with the destination bucket.

Only object overwrite operations will be synchronized again to the destination bucket for objects that have already been successfully replicated. Changes to object metadata, object access control lists (ACLs), and storage type will not be synchronized to the destination bucket.

Object ACLs. By default, an object is set to private after it is replicated to the destination bucket.

Appendable objects.

Objects stored in Archive, Cold Archive, or Deep Cold Archive.

Objects with deletion marks.

Object delete operations.

RenameObject operations.

Lifecycle rules.

Expiration times of objects.

Null objects.

Replication state

The replication state helps you understand the current status of objects being replicated. You can view the replication state on the object details page:

If the object is the source for CRR, the replication state section will display one of the following statuses: Pending, Failed, or Complete.

tip

The feature that allows you to view the replication status of source objects is currently in closed beta. Contact your account manager for access.

If the object is a target for CRR, this section will display Copied file.

If the object is neither a source nor a target for CRR, this section will display -.

tip

You can also use the GetObject and HeadObject APIs to query the replication state of objects. For instructions, see GetObject and HeadObject.

Notes

Category	Notes
Billing	TOS calculates the number of requests for each object synchronized via CRR. You will be charged for these requests. Additionally, when using CRR, you will incur outbound traffic costs for data transferred from the source bucket. For billing details, see Requests and Data transfer. Starting February 20, 2025, you will be charged for data retrieval when synchronizing objects in Infrequent Access Storage or Flashback Archive via CRR. For billing details, see Data retrievals.
Rule quantity	A bucket cannot have more than 100 total cross-region and same-region replication rules.
Permissions	Do not remove the permissions that allow TOS to read from and write to the source and destination buckets during replication. Doing so will cause the replication to fail.
Object size	For CRR, the object size must not exceed the following limits: Non-multipart objects: The maximum size is 5 GiB. Multipart objects: The maximum size is 48.8 TiB, with a maximum of 10,000 parts, each up to 5 GiB.
Impacts	Intelligent Tiering During cross-region replication, TOS may access objects in Intelligent Tiering. After being replicated to the destination bucket, these objects will be moved to the frequent access tier. Lifecycle rule When an object is replicated to the destination bucket using CRR, its last modified time is set to that of the source bucket instead of the time it was replicated. If the destination bucket has lifecycle rules configured, they will be executed based on this time. Redundancy After an object is replicated to a single-AZ or multi-AZ bucket via CRR, it inherits the bucket's redundancy type and becomes a single-AZ or multi-AZ object.
Restrictions	Versioning You can only create a CRR rule when the versioning status of the source and destination buckets is the same—either both are enabled or both are disabled. CRR rules cannot be created if either is suspended. When versioning is enabled on both the source and destination buckets, multiple object versions can be replicated to the destination bucket. After enabling CRR, do not change the versioning status of the source and destination buckets, as this may cause synchronization failures and other issues. If you need to modify the versioning status of the source bucket, delete the corresponding CRR rule first. Server-side encryption Only objects encrypted with SSE-TOS can be replicated. Objects encrypted with SSE-C or SSE-KMS are not supported. The destination bucket's region must support SSE-TOS. Otherwise, replication will fail. If a source object is encrypted with SSE-TOS and the destination bucket uses SSE-KMS, the replica will retain SSE-TOS for server-side encryption. RenameObject RenameObject does not work with CRR. Do not use CRR when RenameObject is enabled on your bucket. Retention policy The object lock status of the source and destination buckets must be consistent—either both are enabled or both are disabled. Otherwise, creation of CRR rules will fail. Replication operations Replication between buckets does not support chain transfers. For example, if one rule replicates from bucket A to bucket B and another rule replicates from bucket B to bucket C, the objects replicated from bucket A to bucket B will not be replicated again to bucket C. Mutual replication between buckets is not supported. For example, if one rule replicates from bucket A to bucket B and another rule replicates from bucket B to bucket A, the objects replicated from bucket A to bucket B will not be replicated back to bucket A.
Object overwrite risk	Writing objects with the same name to both the source and destination buckets may result in objects in the destination bucket being overwritten by objects from the source bucket.
Object replication order	The order in which objects are replicated cannot be controlled. Therefore, we recommend verifying data integrity by comparing the number of objects in directories.
Bandwidth and QPS limits	The default bandwidth for cross-region replication within the Chinese mainland is 10 Gbps, with a QPS of 10,000. For replication between the Chinese mainland and other locations using transfer acceleration, the default bandwidth is 2 Gbps with a QPS of 5,000. Submit a ticket if you need more bandwidth.
Replication between the Chinese mainland and other locations	Before replicating objects between the Chinese mainland and other locations, you must first enable transfer acceleration on the source bucket. For instructions, see Enabling transfer acceleration.

Same-account and cross-account CRR

Within the same account, you can copy objects across regions. You can also copy objects across different accounts. For instructions, see Same-account cross-region replication and Cross-account cross-region replication.

Related operations

After adding a CRR rule, you can use event notifications and logs to track new and updated objects in both the source and destination buckets. The instructions are as follows:

Event notification: For an event notification rule, select tos:ObjectReplication:ObjectCreated and tos:ObjectReplication:ObjectModified as the event types. TOS will then deliver event notifications to the specified destination when a CRR rule adds or overwrites an object. For instructions, see Configuring event notifications.

Logging: Use Torch Log Service to retrieve and analyze operation logs of objects. For instructions, see Log analysis.

Last updated: 2026.08.04 18:26:15