Creating a Lifecycle Rule

Application Scenarios

This section describes how to create a lifecycle rule.

Constraints

A lifecycle rule can use prefixes and tags but cannot use wildcards, suffixes, or regular expressions.
A bucket can have an unlimited number of lifecycle rules, but the XML file of all its rules cannot exceed 20 KB.
A maximum of 20 lifecycle rules can be configured for a parallel file system.
If you want to modify the lifecycle rules of a bucket, you need to add rules. For example, if a bucket has already had Rule 1, you can add Rule 2 by performing the following operations:
1. Call GetBucketLifecycle to obtain Rule 1.
2. Add Rule 2.
3. Call PutBucketLifecycle to update the lifecycle rule to Rule 1 and Rule 2.
If you use OBS Console to update an existing lifecycle rule, you do not need to obtain the rule first. You just need to add a new rule and the new rule then automatically overwrites the existing one. For details, see Configuring a Lifecycle Rule on OBS Console.

Lifecycle Rule Configuration

You can configure lifecycle rules by using OBS Console, APIs, or SDKs.

Using OBS Console

In the navigation pane of OBS Console, choose Object Storage.
In the bucket list, click the bucket you want to operate. The Objects page is displayed.
In the navigation pane, choose Data Management > Lifecycle Rules.
Click Create. The Create Lifecycle Rule dialog box is displayed.

Configure parameters under Basic Information.

Click to enlarge

**Table 1** Parameters under **Basic Information**
Parameter	Description
Status	Whether to enable the lifecycle rule If Status is enabled, the lifecycle rule will be applied to affected objects as scheduled. The actions that can be triggered include storage class transitions, object deletion, fragment deletion, and removal of expired delete markers. If Status is disabled, the lifecycle rule will not be applied.
Rule Name	The name of the lifecycle rule A rule name: Can be 255 characters long. Can contain only uppercase letters, lowercase letters, digits, periods (.), underscores (_), and hyphens (-).
Scope	The scope of objects the lifecycle rule applies to Objects with specified prefix: The rule applies to the objects with the specified prefix in the bucket. All objects: The rule applies to all objects in the bucket. Multiple lifecycle rules may overlap. In such cases, the overlapping must comply with the predefined constraints. Otherwise, conflicting rules can cause the configuration to fail.
Prefix	If you choose Objects with specified prefix as the scope, you need to specify an object name prefix. The lifecycle rule applies to the objects with the specified prefix. An object name prefix: Cannot contain the following special characters: *\ : ? " < > \|** Cannot start with a slash (/). Cannot have two consecutive slashes (//).
Tag	Optional You can add a tag to make the lifecycle rule apply to the objects with the specified tag. A lifecycle rule can have a maximum of 10 tags configured. Once a tag is used as a filter, Delete Fragments Upon Expiration and Remove Expired Delete Marker cannot be enabled. For details about how to add tags to objects, see Adding Tags to an Object.

Configure Current Version and Historical Version to specify the number of days after which objects are deleted or transitioned to another storage class.

Click to enlarge

The Historical Version appears only when versioning is enabled or suspended for the bucket.

**Table 2** Settings for **Current Version** and **Historical Version**
Item	Description
Status	Whether to enable the current version or historical version. With Status enabled, you can add a maximum of four settings. With Status disabled, you do not need to make any settings.
Infrequent Access	After the specified number of days since the last update, objects that meet the defined conditions will be transitioned to Infrequent Access.
Archive	After the specified number of days since the last update, objects that meet the defined conditions will be transitioned to Archive. If you want to transition objects first to Infrequent Access and then to Archive, make sure that the number of days before transitioning to Archive is greater than the number of days before transitioning to Infrequent Access. If you only want to transition objects to Archive, there is no such restriction.
Deep Archive	After the specified number of days since the last update, objects that meet the defined conditions will be transitioned to Deep Archive. If you want to transition objects first to Infrequent Access and then to Deep Archive, make sure that the number of days before transitioning to Deep Archive is greater than the number of days before transitioning to Infrequent Access. If you want to transition objects first to Archive and then to Deep Archive, make sure that the number of days before transitioning to Deep Archive is greater than the number of days before transitioning to Archive. If you only want to transition objects to Deep Archive, there is no such restriction.
Delete Upon Expiration	After the specified number of days since the last update, OBS will delete the objects that meet the defined conditions. The number of days before performing this action must be an integer greater than that specified for any transition. If versioning is not enabled for the bucket, specified objects will be permanently deleted once they expire. The deleted objects cannot be recovered.

Transitioning the storage class of objects or deleting objects may incur changes in costs. The details are as follows:

Deleting objects frees up storage space. Prices vary depending on storage classes.
Deep Archive, Archive or Infrequent Access objects have a minimum billable storage duration of 180, 90 or 30 days, respectively. If the objects are deleted or transitioned before this minimum duration is reached, you still need to pay for a full storage duration.
Transitioning storage classes through lifecycle rules will incur request costs.
For details about lifecycle rule billing, see Billing in Special Scenarios.

Current Version and Historical Version are two concepts related to Versioning. If versioning is enabled for a bucket, uploading objects with the same name to the bucket creates different object versions. The last uploaded object is called the current version, while those previously uploaded are called historical versions. For more information, see Versioning.
You must configure either Current Version or Historical Version. You can also configure both of them.

Configure Delete Fragments Upon Expiration to specify the number of days after which fragments are deleted.
- Status: whether to enable Delete Fragments Upon Expiration
- You can specify the number of days after which fragments in the bucket will be deleted.
Incomplete data in a bucket is called fragments. Fragments are generated during failed upload attempts.
Configure Remove Expired Delete Marker.

An expired delete marker is the only single delete marker that remains after all historical versions of an object are deleted. This action will remove expired delete markers to improve performance.

Status: whether to remove expired delete markers
Select "I have confirmed these lifecycle rule configurations and understand how they may impact my costs."
Click OK to complete the lifecycle rule configuration.

Using APIs

Configuring Bucket Lifecycle Rules

Using SDKs

Using the GUI Tool - OBS Browser+

Log in to OBS Browser+.
Select the bucket for which you want to configure a lifecycle rule and choose More > Lifecycle Rules.
Click Create.

Configure related parameters.

**Table 3** Lifecycle rule parameters
Parameter	Description
Status	Whether to enable the lifecycle rule If Status is enabled, the lifecycle rule will be applied to affected objects as scheduled. The actions that can be triggered include storage class transitions and object deletion. If Status is disabled, the lifecycle rule will not be applied.
Rule Name	The name of the lifecycle rule A rule name: Can be 255 characters long. Can contain only uppercase letters, lowercase letters, digits, periods (.), underscores (_), and hyphens (-).
Applies To	The scope of objects the lifecycle rule applies to Object name prefix: The rule applies to the objects with the specified prefix in the bucket. Bucket: The rule applies to all objects in the bucket. Note that the configuration may fail in the following situations: If the specified prefix overlaps with the prefix of an existing lifecycle rule, OBS regards these two rules as one and forbids you to configure the one you are configuring. For example, if there is a rule with prefix abc in the system, you cannot create another rule whose prefix contains abc. If there is already a lifecycle rule based on an object prefix, you are not allowed to configure another rule that is applied to the entire bucket. If there is a lifecycle rule that can be applied to the entire bucket, you cannot create any rule based on prefix.
Prefix	If you choose Object name prefix, you need to specify an object name prefix. The lifecycle rule applies to the objects with the specified prefix. An object name prefix: Cannot contain the following special characters: *\ : ? " < > \|** Cannot start with a slash (/). Cannot have two consecutive slashes (//).
Transition to Infrequent Access	After the specified number of days since the last update, objects that meet the defined conditions will be transitioned to Infrequent Access.
Transition to Archive	After the specified number of days since the last update, objects that meet the defined conditions will be transitioned to Archive. If you want to transition objects first to Infrequent Access and then to Archive, make sure that the number of days before transitioning to Archive is greater than the number of days before transitioning to Infrequent Access. If you only want to transition objects to Archive, there is no such restriction.
Expiration Time	After the specified number of days since the last update, OBS will delete the objects that meet the defined conditions. The number of days before performing this action must be an integer greater than that specified for any transition. If versioning is not enabled for the bucket, specified objects will be permanently deleted once they expire. The deleted objects cannot be recovered.

An example is given as follows:

Assume you stored the following files in OBS on January 7, 2022:

log/test1.log
log/test2.log
doc/example.doc
doc/good.txt

On January 10, 2022, you additionally stored the following files in OBS:

log/clientlog.log
log/serverlog.log
doc/work.doc
doc/travel.txt
On January 10, 2022, you configured a lifecycle rule to expire and delete objects with the log/ prefix one day after their upload. Objects log/clientlog.log, log/serverlog.log, log/test1.log, and log/test2.log would be deleted on January 12, 2022.

If you configure a lifecycle rule to transition objects with the log prefix to Infrequent Access and Archive 30 days and 60 days after their upload and to delete the objects 100 days after their upload. OBS performs those actions on log/clientlog.log, log/serverlog.log, log/test1.log, and log/test2.log one day after the defined transition periods are reached.

Click OK to save the lifecycle rule.

Configuring a Lifecycle Rule for a Single Object

You can set the time for deleting an object when uploading it. If versioning is enabled, you can set the deletion time for each version of object when uploading it. An object lifecycle rule only affects object versions and not delete markers or fragments.

Unlike setting a lifecycle rule for a bucket, an object lifecycle rule only applies to that specific object. You can only schedule the deletion of the object, and not any storage class transitions. If a bucket lifecycle rule conflicts with an object lifecycle rule, the object lifecycle rule will apply.

OBS allows you to use only APIs and SDKs to set the lifecycle rule for an object.