Lifecycle Rule Based on Last Modified Time
There are two effective strategies for basic lifecycle management files: based on last modified time (based on upload time records ) and the last access time (based on access time records). Configure a lifecycle rule based on the file's last modified time to periodically convert objects from hot storage class to cold storage class, or delete objects to reduce storage costs,
Based on the last modified time is suitable for scenarios with clear cold-hot data periods, such as medical data from a healthcare institution. After being uploaded to BOS, the data is rarely accessed within six months and almost never accessed thereafter. Medical archives uploaded 180 days ago can be converted to cold storage. If you want BOS to automatically monitor data access modes, identify cold data, and then convert the identified cold data to a different storage class to achieve tiered storage of hot and cold data and ultimately reduce storage costs, you need to configure [lifecycle rules based on the last access time](BOS/Console Operation Guide/Managing Bucket/Managing Lifecycle/Basic Lifecycle Management Usage Instructions/Lifecycle Rule Based on Last Accessed Time.md).
Usage restrictions
Lifecycle rules currently only support prefix and tag matching. The prefix and tag do not support wildcard matching.
Note
- When configuring through SDK or API, note that PutBucketLifecycle follows overwrite semantics. For instance, if a bucket already has a lifecycle rule (Rule01) configured and you want to add a new rule (Rule02) in addition to Rule01, follow these steps:
- Use the GetBucketLifecycle API to fetch the current lifecycle rule configuration, Rule01.
- Add Rule02 on top of Rule01.
- Use the PutBucketLifecycle API to update the lifecycle rules to include both Rule01 and Rule02.
For more notes, refer to Notes on Basic Lifecycle Management.
Cost description
Converting object storage classes or deleting objects through lifecycle rules will incur corresponding request fees for conversion and deletion. If the rule is configured to delete or convert storage class but the specified minimum storage duration is not met, minimum storage period fees will also be incurred.When configuring rules, pay special attention to ensuring that the minimum storage period for the corresponding storage class shall be met during file deletion or conversion; otherwise, fees for not meeting the minimum storage period will be incurred.
Components
Specified effective scope:
- Prefix matching: Match objects and file parts based on specified prefixes. You can create multiple rules to match different prefixes, ensuring no duplication. The naming rules for prefixes are identical to those for objects.
- Tag matching: Match objects based on specified tag keys and values. A single rule can have multiple tag configurations. The lifecycle rule will execute only if the object includes all specified tags.
Tags set for basic lifecycle rules and execution instructions: For example, the tags set for basic lifecycle rules are a:1, b:2
| Tags carried by objects | Whether the lifecycle rule applies to this object |
|---|---|
| a:1 | No |
| a:1,b:3 | No |
| a:1,b:2 | Yes |
| a;1,b:2,c:3 | Yes |
Description Tag matching rules do not apply to parts.
- Prefix + tag matching: Match objects based on both specified prefixes and tag filter criteria.
- Configure for the entire bucket: Match all objects and file parts within the bucket.
- NOT element: To handle only those objects that meet specified prefix and tag criteria while skipping unneeded objects, use the NOT element to designate prefixes and tags for objects to be excluded from processing.
Expiration time and operations for objects
- Expiration days: Define an expiration period of N days. Objects will expire N days after their last modified time, triggering the specified operation, such as converting the storage class or deletion.
- Expiration date: Define an absolute expiration date. All objects with a last modified time earlier than this date will expire, and the associated operation, such as converting the storage class or deletion, will be performed.
Note: The above instructions apply to buckets without versioning enabled
Expiration time and operations for parts
- Expiration days: Define an expiration period of N days. File parts will be deleted N days after their last modified time.
Operation types
Related APIs
The above operation types are API-based at the core. If your program has high custom requirements, you can directly initiate a REST API request. Initiating a REST API request directly requires manually writing code to calculate the signature. For more information, refer to PutBucketLifecycle.