On this page

Show all

Help Center/ Object Storage Service/ User Guide/ Data Management/ Lifecycle Management/ Creating a Lifecycle Rule

Creating a Lifecycle Rule

Updated on 2024-10-24 GMT+08:00

Application Scenarios

This section describes how to create a lifecycle rule.

Constraints

A lifecycle rule can use prefixes 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.
NOTE:

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.
Click the bucket you want to configure a lifecycle rule.
In the navigation pane, choose Overview.
In the Basic Configurations area, click Lifecycle Rules.

Alternatively, you can choose Basic Configurations > Lifecycle Rules in the navigation pane.
Click Create.

Figure 1 Creating a lifecycle rule
Configure a lifecycle rule.
Basic Information:
- Status: Select Enable to enable this lifecycle rule.
- Rule Name: Enter a rule name that is no longer than 255 characters.
- Prefix (optional):
  - If this field is specified, objects with this prefix will be managed by the lifecycle rule. The prefix cannot start with a slash (/) or contain two consecutive slashes (//), and cannot contain special characters (\:*?"<>|).
  - If this field is not specified, all objects in the bucket will be managed by the lifecycle rule.
NOTE:
Current Version or Historical Version:
NOTE:
- 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 can configure either Current Version or Historical Version or both of them.
- Transition to Infrequent Access After (Days): After this number of days since the last update, objects meeting specified conditions will be transitioned to Infrequent Access.
- Transition to Archive After (Days): After this number of days since the last update, objects meeting specified conditions will be transitioned to Archive. If you want to transition objects first to Infrequent Access and then to Archive, ensure that Transition to Archive After (Days) is larger than Transition to Infrequent Access After (Days). If you want to only transition objects to Archive, there is no such a restriction.
- Transition to Deep Archive After (Days): After this number of days since the last update, objects meeting specified conditions will be transitioned to Deep Archive. If you want to transition objects first to Infrequent Access and then to Deep Archive, ensure that Transition to Deep Archive After (Days) is larger than Transition to Infrequent Access After (Days). If you want to transition objects first to Archive and then to Deep Archive, ensure that Transition to Deep Archive After (Days) is larger than Transition to Archive After (Days). If you want to only transition objects to Deep Archive, there is no such a restriction.
- Delete Objects After (Days): After this number of days since the last update, objects meeting specified conditions will be automatically deleted. This number must be an integer larger than that specified for any transition.
- Delete Fragments After (Days): After this number of days since fragment generation, OBS will automatically delete fragments in the bucket.
Assume that you stored the following files in OBS on January 7, 2015:
- log/test1.log
- log/test2.log
- doc/example.doc
- doc/good.txt
Then, you stored the following files in OBS on January 10, 2015:
- log/clientlog.log
- log/serverlog.log
- doc/work.doc
- doc/travel.txt
On January 10, 2015, you set the objects prefixed with log to expire one day later. You might encounter the following situations:
- Objects log/test1.log and log/test2.log uploaded on January 7, 2015 would be deleted after the latest system scan on January 10, 2015 or January 11, 2015.
- Objects log/clientlog.log and log/serverlog.log uploaded on January 10, 2015 would be deleted on January 11, 2015 or January 12, 2015, depending on whether the objects have been stored for a whole day after the previous system scan. If the object has been stored for a whole day after the previous scan, it would be deleted during this scan. If the object has not been stored for a whole day after the previous scan, it would be deleted during the next scan.
Suppose you configured OBS to transition objects with the log prefix to Infrequent Access and Archive 30 days and 60 days after they are uploaded and delete the objects 100 days after they are uploaded. OBS would perform those actions on log/clientlog.log, log/serverlog.log, log/test1.log, and log/test2.log as you defined.

NOTE:

The object storage time starts from the next UTC 00:00. A lifecycle rule becomes effective at most 24 hours after it is configured. There may be a delay in transitioning objects or deleting expired objects, but it does not exceed 48 hours. If you make changes to a lifecycle rule, the action time will be re-calculated.
Click OK to complete the lifecycle rule configuration.

Using APIs

Configuring Bucket Lifecycle Rules

Using SDKs

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.

Using APIs

Specify the x-obs-expires header if you upload an object using PUT (streaming upload) or POST (browser-based upload).

Using SDKs

The following OBS SDKs provides APIs for you to upload objects and configure the expires parameter for object deletion upon expiration:

Parent Topic: Lifecycle Management

Previous topic: Rules for Auto-deleting and Transitioning Objects Through Lifecycle Rules

Next topic: Lifecycle Configuration Examples

Feedback

Was this page helpful?

Helpful Not helpful

Provide feedback

Thank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.

The system is busy. Please try again later.

Which of the following issues have you encountered?

Content is inconsistent with the product UI

Unclear descriptions

Lack of examples or code

Incorrect steps

Can't find what I need

Lack of best practices

Feedback (optional)

0/500

Select at least one type of issue, and enter your comments or suggestions.

Enter a maximum of 500 characters.

Submit Cancel

For any further questions, feel free to contact us through the chatbot.

Chatbot