tencent cloud

Lifecycle Configuration Elements
Download PDF
Last updated: 2024-03-25 15:28:24
Lifecycle Configuration Elements
Last updated: 2024-03-25 15:28:24
Download PDF

Basic Structure

A lifecycle configuration is specified as XML and consists of one or more lifecycle rules. The structure is as follows:
<LifecycleConfiguration>
    <Rule>
        <ID>**your lifecycle name**</ID>
        <Status>Enabled</Status>
        <Filter>
            <And>
                <Prefix>projectA/</Prefix>
                <Tag>
                    <Key>key1</Key>
                    <Value>value1</Value>
                </Tag>
            </And>
        </Filter>
        **transition/expiration actions**
    </Rule>
    <Rule>
        ...
    </Rule>
</LifecycleConfiguration>
Each rule contains the following:
ID (optional): Indicates the content of the rule and is customizable.
Status: Indicates whether the rule is enabled or disabled.
Filter: Identifies objects to which the rule applies.
Action: Specifies actions (operations) that need to be performed on objects that match the above description.
Time: Days (after the object's last modified date) or Date based on which actions are performed on objects.

Rule Description

Filter element

For all objects in bucket

Specify an empty filter, in which case the rule applies to all objects in the bucket.
<LifecycleConfiguration>
    <Rule>
        <Filter>
        </Filter>
        <Status>Enabled</Status>
        **transition/expiration actions**
    </Rule>
</LifecycleConfiguration>

Based on object key prefix

Specify a prefix-based filter so that the rule applies only to objects with the specified prefix. For example, you can filter out objects by the prefix logs/:
<LifecycleConfiguration>
    <Rule>
        <Filter>
           <Prefix>logs/</Prefix>
        </Filter>
        <Status>Enabled</Status>
        **transition/expiration actions**
    </Rule>
</LifecycleConfiguration>

Based on object tag

Specify a filter based on key and value so that the rule applies only to objects with the specified tag. For example, you can filter out objects by tags key=type and value=image:
<LifecycleConfiguration>
    <Rule>
        <Filter>
           <Tag>
              <Key>type</Key>
              <Value>image</Value>
           </Tag>
        </Filter>
        <Status>Enabled</Status>
        **transition/expiration actions**
    </Rule>
</LifecycleConfiguration>

Using multiple filters

In COS, you can combine multiple filters by using AND. For example, you can filter out objects by the prefix logs/ as well as tags key=type and value=image:
<LifecycleConfiguration>
    <Rule>
        <Filter>
            <And>
                <Prefix>logs/</Prefix>
                <Tag>
                      <Key>type</Key>
                      <Value>image</Value>
                </Tag>
            </And>
        </Filter>
        <Status>Enabled</Status>
        **transition/expiration actions**
    </Rule>
</LifecycleConfiguration>

Action element

Specify one or more predefined actions in a lifecycle rule so that these actions will be performed when any objects meet the rule.

Transition action

Specify the Transition action to transition objects from one storage class to another. For a versioning-enabled bucket, this action applies to the current object version. You can set the transition date to as short as 0 days. For example, you can transition objects to the ARCHIVE storage class in 30 days:
<Transition>
    <StorageClass>ARCHIVE</StorageClass>
    <Days>30</Days>
</Transition>

Deletion upon expiration

Specify the Expiration action to delete expired objects. For a versioning-disabled bucket, expired objects will be permanently deleted. For a versioning-enabled bucket, expired objects are added with a DeleteMarker and become the current version. For example, you can delete objects that expire in 30 days:
<Expiration>
    <Days>30</Days>
</Expiration>

Incomplete multipart upload

Note:
You cannot specify object tags and clear incomplete multipart uploads at the same time in the same lifecycle rule.
Specify the AbortIncompleteMultipartUpload action to delete multipart upload tasks with the specified UploadId if they are not successfully completed within the predefined time period. Then, these tasks cannot be resumed or indexed. For example, you can abort multipart upload tasks not successfully completed within 7 days:
<AbortIncompleteMultipartUpload>
   <DaysAfterInitiation>7</DaysAfterInitiation>
</AbortIncompleteMultipartUpload>

Non-current object

In a versioning-enabled bucket, the Transition action only applies to objects of the latest version, and the Expiration action only results in adding delete markers to the objects. Therefore, COS provides the following actions for objects of non-current versions:
Specify the NoncurrentVersionTransition action to transition non-current objects to another storage class at the specified time. For example, you can transition non-current objects to the ARCHIVE storage class in 30 days:
<NoncurrentVersionTransition>
    <StorageClass>ARCHIVE</StorageClass>
    <Days>30</Days>
</NoncurrentVersionTransition>
Specify the NoncurrentVersionExpiration action to delete non-current objects at the specified time. For example, you can delete non-current objects in 30 days:
<NoncurrentVersionExpiration>
    <Days>30</Days>
</NoncurrentVersionExpiration>
Specify the ExpiredObjectDeleteMarker action to clear the remaining delete markers. You can set it to true or false. This action is triggered by the NoncurrentVersionExpiration action. If this feature is enabled, when lifecycle execution deletes the last historical version in the lifecycle of an object, COS will automatically delete the remaining delete markers.
The details are as follows. If the NoncurrentVersionExpiration action is in effect:
If there is only one delete marker left, COS will automatically delete the last delete marker regardless of whether ExpiredObjectDeleteMarker is enabled.
If there are multiple delete markers left, COS will check whether ExpiredObjectDeleteMarker is enabled (true), and if so, COS will automatically delete the remaining delete markers; otherwise, COS will not delete them.
<ExpiredObjectDeleteMarker>
    <Days>true|false</Days>
</ExpiredObjectDeleteMarker>

Time element

Based on number of days

Days refers to the number of days since an object was last modified.
For example, if an object is set to be transitioned to the ARCHIVE storage class in 0 days, when the object is uploaded at 2018-01-01 23:55:00 GMT+8, it will be added to the transition queue at 2018-01-02 00:00:00 GMT+8 and transitioned before 2018-01-02 23:59:59 GMT+8.
For example, if an object is set to be deleted upon expiration in 1 day, when the object is uploaded at 2018-01-01 23:55:00 GMT+8, it will be added to the expiration queue at 2018-01-03 00:00:00 GMT+8 and deleted before 2018-01-03 23:59:59 GMT+8.

Based on specific date

Perform the predefined action on all eligible objects based on the filter on the specified Date. The date must be in the ISO 8601 format, and the time is always 00:00 GMT+8. For example, use 2018-01-01T00:00:00+08:00 for January 1, 2018.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No

Feedback