Frequently asked questions about same-account and cross-account data replication, including same-region and cross-region scenarios.
Can I specify a custom path or prefix for the destination bucket?
No. Same-region and cross-region replication do not support custom storage paths for the destination bucket. The destination path is determined by the data path of the source bucket configured in the data replication rule.
Can I replicate objects based on their last modified time?
No. You cannot configure a data replication rule to replicate objects based on a specific last-modified time range. However, you can use the File Modified Time feature of the online migration service to do this. If you specify a time range, only the files modified within that period are migrated.
Why am I unable to create a data replication rule?
Check that the required permissions are granted.
Missing permissions for a RAM user
A RAM user cannot click OK when creating a data replication rule in the console.
Cause: The
oss:PutBucketReplicationpermission is not granted.Solution: Grant the
oss:PutBucketReplicationpermission to the RAM user.
Custom RAM roles do not appear in the RAM role list when a RAM user creates a data replication rule.
Cause: The
ram:ListRolespermission is not granted.Solution: Grant the
ram:ListRolespermission to the RAM user.
Missing permissions for a RAM role
Same-account replication
Grant the RAM role permissions to perform replication between the source and destination buckets. Role types.
Cross-account replication
Use Account A to grant a RAM role permissions to replicate data from the source bucket, and Account B to grant a RAM role permissions to receive replicated objects in the destination bucket. Role authorization.
Check whether the source and destination buckets have the same versioning status.
The source and destination buckets must have the same versioning status: both versioned or both unversioned.
Check whether the endpoint or AccessKey information is correct.
If you use an SDK or ossutil to create a data replication rule, check the following:
Verify the region endpoints for the source and destination buckets. Regions and endpoints.
Verify the AccessKey pair. View the AccessKey information of a RAM user.
What do I do if the Resource Access Management (RAM) console displays invalid authorization warnings when I create a replication policy?
When you use the visual editor in the RAM console to create a custom replication policy containing oss:ReplicateList and oss:ReplicateGet, the console may display unrecognized action and unrecognized resource warnings.
These warnings occur because the visual editor's action dictionary does not include these internal OSS actions. The warnings do not affect the validity of the policy.
Create the policy by using either of the following methods:
Switch to Script editor mode and enter the policy JSON. This mode does not display these warnings.
Use the
aliyun ram CreatePolicycommand in the command-line interface (CLI) to create the policy.
After you create the policy, create a cross-account replication rule in the OSS console. If you can create the rule, the policy is effective.
Why are objects not replicated to the destination bucket?
If objects do not appear in the destination bucket after you configure a data replication rule, check the following causes.
The source bucket is incorrectly configured.
Check whether the data replication status is Enabled.
The prefix is incorrect.
To replicate specific objects, set the prefix. For example, if the prefix is
log, only objects such aslog/date1.txtandlog/date2.txtare replicated. Objects likedate3.txtare not replicated.NoteDo not add an asterisk (*) at the end of the prefix, such as
log/*. The prefix cannot contain the bucket name.To replicate all objects from the source bucket to the destination bucket, leave the prefix field empty.
Check whether replication of historical objects is enabled and whether the missing objects are historical objects.
Check whether the source objects are replicas from another bucket.
OSS does not replicate objects that are themselves replicas from another replication rule. For example, if replication is configured from bucket A to bucket B and from bucket B to bucket C, replicas in bucket B are not replicated to bucket C.
Check whether the objects are KMS-encrypted. If so, enable replication for KMS-encrypted objects.
If the source object or destination bucket uses SSE-KMS with a specified CMK ID, select Copy and configure the following parameters:
CMK ID: Specify the KMS key to encrypt the destination object.
First create a KMS key in the same region as the destination bucket. Create a key.
RAM Role Name: Select a RAM role to perform KMS encryption on the destination object.
New RAM Role: Creates a new RAM role for KMS encryption. The role name format is
kms-replication-SourceBucketName-DestinationBucketName.AliyunOSSRole: Uses the AliyunOSSRole role for KMS encryption on the destination object. OSS automatically creates this role if it does not exist.
NoteIf you create or modify a role, grant it the
AliyunOSSFullAccesspermission. Otherwise, data replication may fail.
Call HeadObject and GetBucketEncryption to query the encryption status of the source object and the destination bucket.
Check whether the replication progress is 100%.
Data replication is asynchronous and can take several minutes to several hours depending on the data size. After progress reaches 100%, check whether the object appears in the destination bucket.
Why are object deletions not replicated?
Cause 1: A retention policy (WORM) is configured for the destination bucket.
Before the retention period expires, no user, including the resource owner, can delete objects.
Cause 2: Deletion behavior depends on the versioning status of the source bucket and the replication policy.
Source bucket versioning
Request method
Data replication policy
Result
Unversioned
A Delete request is initiated.
Replicate additions and modifications
Only the object in the source bucket is deleted. The object in the destination bucket is not deleted.
Replicate additions, modifications, and deletions
The objects in both the source and destination buckets are deleted.
Versioning enabled
A Delete request is initiated without an object version ID.
Replicate additions and modifications
No object is deleted from either bucket. OSS creates a delete marker in the source bucket and replicates the delete marker to the destination bucket.
Replicate additions, modifications, and deletions
A Delete request is initiated with an object version ID.
Replicate additions and modifications
Only the object version in the source bucket is deleted. The object version in the destination bucket is not deleted.
Replicate additions, modifications, and deletions
The specified object versions in both the source and destination buckets are deleted.
Verify data consistency
Run the following code to verify data consistency between the source and destination buckets after replication.
import com.aliyun.oss.OSSClient;
import com.aliyun.oss.common.auth.*;
import com.aliyun.oss.model.*;
import com.aliyun.oss.OSSException;
import com.aliyuncs.exceptions.ClientException;
public class Demo {
public static void main(String[] args) throws ClientException {
// Obtain access credentials from environment variables. Before you run this sample code, make sure that the OSS_ACCESS_KEY_ID and OSS_ACCESS_KEY_SECRET environment variables are set.
EnvironmentVariableCredentialsProvider credentialsProvider = CredentialsProviderFactory.newEnvironmentVariableCredentialsProvider();
// Set srcEndpoint to the endpoint of the region where the source bucket is located.
String srcEndpoint = "https://oss-cn-hangzhou.aliyuncs.com";
OSSClient srcClient = new OSSClient(srcEndpoint , credentialsProvider);
// Specify the name of the source bucket.
String srcBucketName = "src-replication-bucket";
// Set destEndpoint to the endpoint of the region where the destination bucket is located.
String destEndpoint = "https://oss-cn-beijing.aliyuncs.com";
OSSClient destClient = new OSSClient(destEndpoint, credentialsProvider);
// Specify the name of the destination bucket.
String destBucketName = "dest-replication-bucket";
// If the source and destination buckets do not have versioning enabled, call listObjectsV2 to list the replicated objects from the source bucket.
// If versioning is enabled or suspended for the source and destination buckets, call listVersions to list the replicated objects from the source bucket.
ListObjectsV2Result result;
ListObjectsV2Request request = new ListObjectsV2Request(srcBucketName);
do {
result = srcClient.listObjectsV2(request);
for (OSSObjectSummary summary : result.getObjectSummaries())
{
String objectName = summary.getKey();
ObjectMetadata srcMeta;
try {
// Get the metadata of the source object.
srcMeta = srcClient.headObject(srcBucketName, objectName);
} catch (OSSException ossException) {
if (ossException.getErrorCode().equals("NoSuchKey")) {
continue;
} else {
System.out.println("head src-object failed: " + objectName);
}
continue;
}
ObjectMetadata destMeta;
try {
// Get the metadata of the object replicated to the destination bucket.
destMeta = destClient.headObject(destBucketName, objectName);
} catch (OSSException ossException) {
if (ossException.getErrorCode().equals("NoSuchKey")) {
System.out.println("dest-object not exist: " + objectName);
} else {
System.out.println("head dest-object failed: " + objectName);
}
continue;
}
// Check whether the CRC values of the source and destination objects are consistent.
Long srcCrc = srcMeta.getServerCRC();
String srcMd5 = srcMeta.getContentMD5();
if (srcCrc != null) {
if (destMeta.getServerCRC() != null) {
if (!destMeta.getServerCRC().equals(srcCrc)) {
System.out.println("crc not equal: " + objectName
+ " | srcCrc: " + srcCrc + " | destCrc: " + destMeta.getServerCRC());
}
continue;
}
}
// Check whether the MD5 values of the source and destination objects are consistent.
if (srcMd5!= null) {
if (destMeta.getContentMD5() != null) {
if (!destMeta.getContentMD5().equals(srcMd5)) {
System.out.println("md5 not equal: " + objectName
+ " | srcMd5: " + srcMd5 + " | destMd5: " + destMeta.getContentMD5());
}
continue;
}
}
// Check whether the ETag values of the source and destination objects are consistent.
if (srcMeta.getETag() == null || !srcMeta.getETag().equals(destMeta.getETag())) {
System.out.println("etag not equal: " + objectName
+ " | srcEtag: " + srcMeta.getETag() + " | destEtag: " + destMeta.getETag());
}
}
request.setContinuationToken(result.getNextContinuationToken());
request.setStartAfter(result.getStartAfter());
} while (result.isTruncated());
}
}
Is chained replication supported?
No. Data replicated from bucket A to bucket B is not further replicated from bucket B to bucket C.
To replicate data from bucket A to bucket C, configure a separate replication rule from bucket A to bucket C.
If historical replication is still in progress for both buckets, new data written to bucket A might be scanned by the historical replication task and replicated to bucket C.
Does two-way replication between buckets create a replication loop?
No. Replicated data is never sent back to its origin. Data replicated from A to B is not replicated back to A.
Are lifecycle rule deletions replicated?
If the replication policy is Replicate additions and modifications, lifecycle-deleted objects in the source bucket are not deleted from the destination bucket.
If the replication policy is Replicate additions, modifications, and deletions, lifecycle-deleted objects in the source bucket are also deleted from the destination bucket.
NoteIf the destination bucket still contains objects with the same names as lifecycle-deleted source objects, these may have been manually written to the destination bucket.
Why is historical replication progress stuck at 0%?
The replication progress is not updated in real time.
Historical replication progress updates only after all files are scanned. For buckets with hundreds of millions of objects, this may take several hours. A progress of 0% does not mean replication has not started.
Confirm whether historical replication has started by checking changes in the destination bucket's storage capacity and traffic. Query bucket-level usage.
The authorization policy of the source bucket is incorrect.
OSS does not validate permissions when creating a replication rule. The rule is created even with incorrect permissions, but data will not be replicated and progress remains at 0%.
What to do if data replication is slow?
Increase bandwidth
Replication is asynchronous and can take several minutes to several hours depending on the data volume. If replication is slow due to bandwidth limits, contact technical support to request a bandwidth increase.
Enable Replication Time Control (RTC)
With RTC enabled, OSS replicates most objects within seconds and 99.99% within 10 minutes. RTC-enabled tasks incur data replication traffic charges. Use Replication Time Control (RTC).
How to track replication operations?
Configure an event notification rule with event types ObjectReplication:ObjectCreated, ObjectReplication:ObjectRemoved, and ObjectReplication:ObjectModified to track object creations, updates, deletions, and overwrites. Use event notifications to monitor OSS object changes in real time.
Is replication supported on suspended-versioning buckets?
No. Both buckets must have the same versioning status: both unversioned or both versioned.
Are KMS API calls for replication billable?
Yes. If the destination bucket uses KMS encryption, you are charged for the corresponding KMS API calls. Billing of KMS 1.0.
Can I disable a replication rule?
Yes. You can click Disable Replication next to the rule to stop data replication.
Existing replicated data remains in the destination bucket, but new data written to the source bucket is no longer replicated.
Does replication change the order of files?
No. Replication preserves the modification order of files.