This topic describes the behavior of data replication, including cross-region replication and Same-region replication (SRR), when used with features such as versioning, lifecycle rules, server-side encryption, and retention policies.
Data replication with versioning
The following limitations apply when you use data replication with versioning:
Enable data replication only between two buckets that have the same versioning state, which is either enabled or disabled. Do not change the versioning state of the source or destination bucket while data is being synchronized.
Do not pause versioning for the source or destination bucket during data synchronization. To pause versioning, you must first delete the data replication rule.
When you delete an object from a versioning-enabled source bucket, the following scenarios occur:
Request type | Data synchronization policy | Result |
A Delete request is sent without specifying an object version ID | Sync additions and modifications | The object is not deleted from the source or destination bucket. Instead, OSS creates a delete marker in the source bucket. This delete marker is then replicated to the destination bucket. |
Sync additions, deletions, and modifications | ||
A Delete request is sent that specifies an object version ID | Sync additions and modifications | The object is deleted only from the source bucket. It is not deleted from the destination bucket. |
Sync additions, deletions, and modifications | The object is deleted from both the source and destination buckets. |
Data replication with lifecycle rules
Data replication with versioning creates multiple previous versions in the destination bucket, which increases storage consumption. To reduce storage costs, use lifecycle rules to control storage costs and implement custom data retention policies.
When you use data replication with lifecycle rules, note the following:
Data replication replicates the outcomes of a lifecycle rule from the source bucket to the destination bucket, but not the rule itself. If you want the destination bucket to follow the same lifecycle rule, you must configure the same rule for the destination bucket.
An object replica in the destination bucket retains the creation time of the original object in the source bucket, not the time when the object is replicated to the destination bucket.
If a lifecycle rule deletes an object in the source bucket while the object is being replicated, the replication of that object may still be completed. In this case, the object replica is retained in the destination bucket.
When you use cross-region replication for a versioning-enabled bucket, delete markers from the source bucket are replicated to the destination bucket. This operation makes the delete marker the current version of the object in the destination bucket, and the previous current version becomes a noncurrent version. If the destination bucket has a lifecycle rule to delete noncurrent versions, such as deleting them after one day, the object's noncurrent version is permanently deleted when the condition is met. Therefore, exercise caution when you configure lifecycle rules that delete noncurrent versions to prevent unintended data loss in the destination bucket.
Data replication with server-side encryption
Data replication within the same account supports unencrypted objects and objects encrypted using server-side encryption with KMS-managed keys (SSE-KMS) or OSS-managed keys (SSE-OSS). For more information, see Server-side encryption.
When you use SSE-KMS, the key used for encryption and decryption depends on whether a Customer Master Key (CMK) ID is specified.
If you do not specify a CMK ID, the default CMK managed by KMS is used for encryption and decryption.
If you specify a CMK ID, the specified CMK is used for encryption and decryption.
When you use data replication with server-side encryption, the following scenarios occur:
Encryption status of the source object | Encryption method of the destination bucket | Data replication rule configuration | Encryption method of the destination object | Description |
Unencrypted | Unencrypted | - | Unencrypted | Uses the destination bucket's encryption method. |
SSE-OSS | SSE-OSS | |||
SSE-KMS, without a specified CMK ID | SSE-KMS, without a specified CMK ID | |||
SSE-KMS, with CMK ID1 specified | No CMK ID configured | SSE-KMS, with CMK ID1 specified | The CMK ID configured in the data replication rule takes precedence. | |
CMK Configuration for ID2 | SSE-KMS, with CMK ID2 specified | |||
SSE-OSS | - | - | SSE-OSS | Uses the source object's encryption method. |
SSE-KMS | - | Do not replicate KMS-encrypted objects | Not replicated | Depends on the data replication rule configuration. |
Configure a CMK ID | SSE-KMS, with a specified CMK ID |
Data replication with retention policies
After a retention policy (WORM) for a bucket is locked, you can upload and read objects in the bucket. However, you cannot modify (overwrite) or delete objects until their retention period expires.
For more information about retention policies, see Retention policies.
When you use data replication with retention policies, the following scenarios occur:
Is the source object under WORM protection? | Allowed operation in the source bucket | Is the target Object under WORM protection? | Is the operation replicated to the destination bucket? |
No | Add an object | Yes | No |
Overwrite an object | Yes | No | |
Delete an object | Yes | No | |
No | Add an object | No | Yes |
Overwrite an object | No | Yes | |
Delete an object | No | Yes | |
Yes | Add an object | No impact. | Yes |