You need to enable JavaScript to run this app.
Torch Object Storage

Torch Object Storage

Copy page
Download PDF
Same-region replication
Overview
Copy page
Download PDF
Overview
You can use same-region replication (SRR) to automatically copy objects across buckets in the same region. This feature lets you filter which objects are replicated and monitor their progress.​
Use cases​
You can use SRR to back up your data locally to another bucket within the same region. As TOS does not currently charge for local data transfer, your costs will be lower.​
What does SRR replicate?​
What is replicated with SRR?​
SRR replicates the following information about objects: content, size, last modified time, tag, creator, version number, user-defined metadata, and storage type. The following types of objects can be automatically replicated via an SRR rule:​
  • Objects that exist before the SRR rule takes effect.​
tip​
By default, the SRR rule does not synchronize existing objects. To do so, turn on the "Sync historical object" option in the rule.​
  • Objects uploaded after the SRR 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.​
warning​
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.​
What is not replicated with SRR?​
  • 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.​
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 SRR, 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 close beta. Contact your account manager for access.​
  • If the object is a target for SRR, this section will display Copied file.​
  • If the object is neither a source nor a target for SRR, 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​
Considerations​
Billing​
  • TOS calculates the number of requests for each object synchronized via SRR. You will be charged for these requests. Currently, however, you will not be charged for local data transfer. For billing details, see Requests.​
  • Starting February 20, 2025, you will be charged for data retrieval when synchronizing objects in Infrequent Access Storage or Flashback Archive via SRR. For billing details, see Data retrievals.​
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.​
Rule quantity​
A bucket cannot have more than 100 total same-region and cross-region replication rules.​
Object size​
For SRR, 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 same-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 rules​
  • When an object is replicated to the destination bucket using SRR, 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 SRR, it inherits the bucket's redundancy type and becomes a single-AZ or multi-AZ object.​
Restrictions​
  • Versioning​
  • You can only create a SRR rule when the versioning status of the source and destination buckets is the same—either both are enabled or both are disabled. SRR 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 SRR, 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 SRR rule first.​
  • Server-Side encryption​
  • Only objects encrypted with SSE-TOS can be replicated. 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. For more information, see Server-side encryption overview.​
  • 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 SRR 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.​
​
Same-account and cross-account SRR​
You can copy objects from one bucket to another within the same account, or from one account to another. For instructions, see Same-account same-region replication and Cross-account same-region replication.​
Related operations​
After adding an SRR 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 an SRR 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: 2025.09.29 18:22:22