Help Center/ Object Storage Service/ User Guide/ Data Management/ Lifecycle Management/ Overview of Lifecycle Management
Updated on 2024-10-24 GMT+08:00
View PDF
Share

Overview of Lifecycle Management

Scenarios

The last modification time of an object determines when the lifecycle rule applied to the object becomes effective to periodically transition or delete the object. The transition action is to automatically change objects that are no longer frequently accessed to a storage class with a lower cost without copying the objects themselves.

Figure 1 OBS object lifecycle management
Table 1 Key actions in OBS object lifecycle management

Action

Scenarios

Objects Managed

Operation Guide

Transitions between storage classes

Periodically transition data that is frequently accessed over a period of time but may not be accessed after that period to the Archive or Deep Archive storage class to reduce storage costs. Such data includes digital media, financial and medical records, long-term database backups, and data retained for regulatory compliance.

Objects in a bucket (including the latest and historical versions of objects when versioning is enabled for the bucket)

Transitioning Objects Using Lifecycle Rules

Periodical deletion of objects

Periodically delete data, such as log files, that needs to be retained for a period of time and can be deleted after that period.
  • Objects in a bucket (including the latest and historical versions of objects when versioning is enabled for the bucket)
  • Fragments
    NOTE:

    In a multipart upload, a file is divided into multiple parts and then uploaded. After all parts are uploaded, you can make an API call to assemble the parts into a complete object. The parts that failed to be uploaded or assembled are called fragments. You can continue to execute the interrupted or failed multipart upload to remove fragments, or directly delete fragments to reduce storage costs. For more information about fragments, see Managing Fragments.

  • Expired delete markers
    NOTE:

    An expired delete marker is the only single delete marker that remains after all historical versions of an object are deleted. Removing expired delete markers helps improve performance.

Deleting Objects Using Lifecycle Rules

Points in Time for Lifecycle Management

Below describes the key points in time involved in lifecycle management.

  • An object uploaded to a bucket cannot be modified, so the object's last modification time is when the object was uploaded. Operations, such as changing the object storage class, ACL, metadata, and encryption method and appending data to an object, only change the metadata of an object.
  • For parallel file systems, modifying and truncating a file will change the last modification time of the file.
  • Uploading or copying an object in a bucket or a file in a parallel file system will change their last modification time if there is such an object or a file with the same name. If versioning is not enabled, the last modification time of the object or file is the time when the object or file was last uploaded. If versioning is enabled, a newly uploaded object or file becomes the current version, and the original one becomes a historical version. The last modification time of both the current version and the historical version is the time when the object or file was last uploaded.

After an object is last updated, OBS starts to calculate its lifecycle at the next 00:00 (UTC time). Assume an object was uploaded at 09:00 on June 1, 2024 (UTC). OBS would calculate its lifecycle from 00:00 on June 2, 2024 (UTC). If the object was configured to be deleted one day later, it would be deleted at 00:00 on June 3, 2024 (UTC).

  • It usually takes 24 hours at most for the actions in a lifecycle rule to complete. Considering the start time of the rule, there may be a delay in transitioning storage classes or deleting expired objects, but the total completion time will not exceed 48 hours.

    Assume an object was uploaded at 09:00 on June 1, 2024 (UTC). OBS would calculate its lifecycle from 00:00 on June 2, 2024 (UTC). If the object was configured to be deleted one day later, it would be deleted at 00:00 on June 3, 2024 (UTC). The execution latency does not exceed 24 hours and the deletion would be completed at 00:00 on June 4, 2024 (UTC).

  • If you make changes to an existing lifecycle rule, the lifecycle task on the current day will be terminated and the lifecycle execution time may be prolonged. Therefore, do not frequently change a lifecycle rule. For example, if an object was uploaded at 20:20 on June 1, 2024 (UTC) and has a rule configured to delete it one day later, the rule would be deleted at 00:00 on June 4, 2024 (UTC). However, if the lifecycle rule was modified, for example, the rule name was changed, the lifecycle rule needs to be reloaded and executed again, the deletion may be complete later than 00:00 on June 4, 2024 (UTC).
Parent Topic: Lifecycle Management