The Write Once Read Many (WORM) feature of retention policies in Object Storage Service (OSS) allows you to prevent users from modifying or deleting data. If you do not want anyone, including resource owners, to modify or delete objects in a bucket within a specific period of time, you can configure a retention policy for the bucket. Before the specified retention period ends, you can only upload objects to or read objects from the bucket. You can modify or delete objects only after the retention period ends.
Prerequisites
The bucket for which you want to configure retention policies is located in one of the following regions: China (Hangzhou), China (Shanghai), China (Fuzhou-Local Region), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), China (Shenzhen), China (Heyuan), China (Guangzhou), China (Chengdu), China (Hong Kong), US (Silicon Valley), Japan (Tokyo), South Korea (Seoul), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), Philippines (Manila), Thailand (Bangkok), Germany (Frankfurt), UK (London), and UAE (Dubai).
Versioning is not enabled for the bucket for which you want to configure a retention policy. For more information about versioning, see Overview.
Scenarios
The WORM feature provided by the retention policies in OSS helps enterprises meet regulatory and compliance requirements of the U.S. Securities and Exchange Commission (SEC) and Financial Industry Regulatory Authority (FINRA). The feature is suitable for sectors such as finance, insurance, healthcare, and securities, and scenarios such as Multi-Layer Protection Scheme (MLPS) audit of log data.
OSS is accredited and audited by Cohasset Associates and meets the stringent requirements for the retention of electronic records. OSS buckets for which retention policies are configured comply with regulatory regulations, such as SEC Rule 17a-4(f), CFTC Rule 1.31(c)-(d), and FINRA Rule 4511(c). For more information, see OSS Cohasset Assessment Report.
Usage notes
You can configure retention policies only for buckets in OSS.
We recommend that you do not enable OSS-HDFS and configure retention policies for a bucket at the same time.
For example, OSS-HDFS is enabled for a bucket for which a retention policy is configured. When you use methods supported by OSS-HDFS to delete an object from the
.dlsdata/
directory, you receive a message that indicates the object is deleted. However, OSS actually retains the object if the deletion occurs within the retention period and cannot recognize and delete the object after the retention period ends.During the retention period, you can configure lifecycle rules to change the storage classes of objects in the bucket. This way, you can reduce costs and ensure compliance. For more information, see Lifecycle rules based on the last modified time.
Retention policy description
Implementation
By default, a time-based retention policy is in the IN_PROGRESS state after the policy is created for a bucket. The retention policy remains in the IN_PROGRESS state for 24 hours. The retention policy protects the specified resources in the bucket within 24 hours after the policy is created.
In the 24-hour window after the retention policy is created
If the retention policy is not locked, the bucket owner and authorized users can delete the policy.
If the retention policy is locked, the retention period of the policy cannot be shortened and the policy cannot be deleted. However, the retention period can be extended.
If the retention policy is locked, data in the bucket is protected by the retention policy. If you attempt to delete or modify data in the bucket, the
409 FileImmutable
error is returned.
24 hours after the retention policy is created
If the retention policy is not locked 24 hours after the retention policy is created, the policy becomes invalid. You can delete the policy.
Deletion
A time-based retention policy is a metadata attribute of a bucket. If a bucket is deleted, the retention policy of the bucket is also deleted.
If the retention policy is not locked within 24 hours after the policy is created, the bucket owner and authorized users can delete the policy.
If a bucket contains objects that are protected within the retention period, you cannot delete the bucket or the retention policy.
Example
For example, you created a retention policy that has a retention period of 30 days for a bucket on June 1, 2022, and immediately locked the policy. You uploaded the file1.txt, file2.txt, and file3.txt objects to the bucket at different points in time. The following table describes the upload dates and expiration dates of the objects.
Object
Upload date
Expiration date
file1.txt
April 1, 2022
April 30, 2022
file2.txt
June 1, 2022
June 30, 2022
file3.txt
September 1, 2022
September 30, 2022