Docs

Torch Object Storage

Managing lifecycle

Lifecycle overview

You can reduce storage costs by using the lifecycle feature in TOS to periodically transition objects to lower-cost storage types or delete expired objects and parts.

Introduction

With the lifecycle feature, you can configure rules to periodically move objects between storage types or delete expired objects, such as cold data stored in Archive or Deep Cold Archive.

Transition process

The transition of objects between different storage types is as follows:

Below are the rules for object transition.

Category	Description
Object	The transition of objects can go only one way: Standard Storage > Infrequent Access Storage > Intelligent Tiering > Flashback Archive > Archive > Cold Archive > Deep Cold Archive. Cross-level transitions are also supported, such as moving from Standard Storage to Cold Archive. Reverse transitions are not permitted, such as moving from Flashback Archive to Standard Storage.
Intelligent Tiering	You can use lifecycle rules to transition objects from Standard Storage or Infrequent Access Storage to Intelligent Tiering: When an object is transitioned from Standard Storage to Intelligent Tiering, it is placed in the frequent access tier. To transition an object from Infrequent Access Storage to Intelligent Tiering, it must have been uploaded more than 30 days ago. It will then be placed in the infrequent access tier of Intelligent Tiering. Changes in capacity and billing metrics may be delayed by several hours, but typically no longer than 24 hours. tip Objects smaller than 64 KiB cannot be transitioned to Intelligent Tiering via lifecycle rules.

Supported operations

You can configure lifecycle rules to delete latest and historical versions of objects, or to transition objects. The specific operations depend on whether versioning is enabled for the bucket. The details are as follows:

Operation	Nonversioned	Versioning-enabled	Versioning-suspended
Deleting latest object versions	Permanently deletes objects.	Adds a deletion mark to the latest object version and converts it into an earlier version.	Deletes objects if they are null. Adds a deletion mark to any non-null object and converts it to an earlier version.
Deleting historical object versions	Not applicable.	Permanently deletes historical object versions.	Permanently deletes objects, regardless of whether they are null.
Transitioning latest object versions	Transitions objects.	Transitions latest object versions.	Transitions latest object versions.
Transitioning historical object versions	Not applicable.	Transitions historical object versions.	Transitions historical object versions.

Effective time

A lifecycle rule does not take effect immediately after it is created. The overall timeline is as follows:

Rule loading: TOS loads a rule within 24 hours of its creation.

Object list fetch: Before executing a lifecycle rule, TOS retrieves a list of matching objects, including their prefixes and tags. This list is only fetched once every 24 hours. If you modify an object's prefix or tag after the list has been retrieved, the changes will not take effect until the next cycle.

Rule execution: Rule execution begins 24 hours after loading.

The maximum number of lifecycle-related operations that can be performed within a 24-hour period varies depending on the scenario, as shown in the table below. These operations include transitions, the deletion of expired objects and parts, and the deletion of specified objects. If the number of operations exceeds these limits, processing may take more than 24 hours.

Scenario	China (Beijing)/China (Guangzhou)/China (Shanghai)	Other regions
When versioning is not enabled for a bucket	1 billion	100 million
When versioning is enabled for a bucket	500 million	50 million
When lifecycle rules are configured for multiple buckets under one account	2 billion	200 million

Remarks

For buckets with versioning enabled, each object version is counted as a separate operation.

After you edit or delete a lifecycle rule, there will usually be a brief delay of a few minutes before TOS stops executing the original rule. Frequent updates to lifecycle rules are not recommended.

Rule priority

The priority of lifecycle rules depends on whether prefix overlap is allowed:

Prefix overlap disabled

The transition time varies depending on the storage type. Multiple expiration policies do not take effect simultaneously for the same object. Therefore, it is unnecessary to determine the priority of lifecycle rules.

Prefix overlap enabled

If an object matches multiple lifecycle rules, the rule with the shorter expiration period takes priority.

If the expiration periods are equal, the rule with the lower cost is applied.

TOS executes the lifecycle rules in the following order:

Delete Object > Transition to Deep Cold Archive > Transition to Cold Archive > Transition to Archive > Transition to Flashback Archive > Transition to Infrequent Access Storage > Add Deletion Mark to Object

Notes

Category	Description
Quantity	The maximum number of lifecycle rules permitted for a bucket is 1,000. Additionally, each bucket enforces a 20 KB cumulative limit for all JSON-formatted lifecycle policies.
Default expiration time	When creating a lifecycle rule, if you do not specify when objects will expire, the default expiration rules will apply. These rules are as follows: Objects are transitioned to Infrequent Access Storage 30 days after they are uploaded. Objects are transitioned to Intelligent Tiering 60 days after they are uploaded. Objects are transitioned to Flashback Archive 90 days after they are uploaded. Objects are transitioned to Archive 180 days after they are uploaded. Objects are transitioned to Cold Archive 270 days after they are uploaded. Objects are transitioned to Deep Cold Archive 450 days after they are uploaded. Objects are deleted 630 days after they are uploaded.
Storage type	You can transition objects in a single-AZ bucket to one of the following storage types: Infrequent Access Storage, Intelligent Tiering, Flashback Archive, Archive, Cold Archive, and Deep Cold Archive. You can transition objects in a multi-AZ bucket to one of the following storage types: Infrequent Access Storage (Multi-AZ), Intelligent Tiering (Multi-AZ), and Flashback Archive (Multi-AZ). For more information on multi-AZ, see Multi-AZ redundancy. tip Multi-AZ redundancy is currently only available in China (Beijing), China (Shanghai), China (Guangzhou), and Asia Pacific (Johor).