Rules for Auto-deleting and Transitioning Objects Through Lifecycle Rules

This section describes the rules for auto-deleting and transitioning objects through lifecycle rules.

Constraints

Because multi-AZ redundancy is not supported for Archive and Deep Archive storage, you cannot transition objects in a multi-AZ bucket to Archive or Deep Archive through lifecycle rules.

Transitioning Objects Using Lifecycle Rules

Figure 1 Transitioning objects using lifecycle rules

As shown in Figure 1, OBS allows you to use lifecycle rules to transition objects as follows:

From Standard to Infrequent Access or Archive or Deep Archive
From Infrequent Access to Archive or Deep Archive
From Archive to Deep Archive

When a lifecycle rule is applied, OBS transitions objects based on the versioning state of your bucket.

Each object in an unversioned bucket has only one version. You can use lifecycle rules to transition such objects.

**Table 1** Transitioning objects in an unversioned bucket
Action Type	Effect of Action	Timer Start Time
Transitioning between storage classes	The object is transitioned to the target storage class.	Time when an object is uploaded

If versioning is not enabled for a bucket, there are no noncurrent versions in the bucket. Therefore, the NoncurrentVersionTransition field is invalid.

You can use lifecycle rules to transition the current and noncurrent versions of objects in a versioning-enabled bucket.

**Table 2** Transitioning objects in a versioning-enabled bucket
Action Type	Effect of Action	Timer Start Time
Transitioning the current version	If the current version is not a delete marker version, it is transitioned to the target storage class. If the current version is a delete marker version, no action is taken.	Time when the current version is uploaded
Transitioning a noncurrent version	If the noncurrent version is not a delete marker version, it is transitioned to the target storage class. If the noncurrent version is a delete marker version, no action is taken.	Time when the current version becomes a noncurrent version

You can use lifecycle rules to transition the current and noncurrent versions of objects in a versioning-suspended bucket.

**Table 3** Transitioning the current and noncurrent versions of objects in a versioning-suspended bucket
Action Type	Effect of Action	Timer Start Time
Transitioning the current version	If the current version is not a delete marker version, it is transitioned to the target storage class. If the current version is a delete marker version, no action is taken.	Time when the current version is uploaded
Transitioning a noncurrent version	If the noncurrent version is not a delete marker version, it is transitioned to the target storage class. If the noncurrent version is a delete marker version, no action is taken.	Time when the current version becomes a noncurrent version

Deleting Objects Using Lifecycle Rules

OBS uses lifecycle rules to delete objects based on the versioning state of your bucket.

If versioning is not enabled for a bucket, each object has only one version. You can use lifecycle rules to delete objects and fragments from this bucket.

**Table 4** Deleting objects and fragments from an unversioned bucket
Action Type	Effect of Action
Deleting an object	The object is permanently deleted and cannot be restored.
Deleting fragments	The fragments are permanently deleted and cannot be restored.

If versioning is not enabled for a bucket, the bucket does not have noncurrent versions or delete markers. Therefore, the NoncurrentVersionExpiration and ExpiredObjectDeleteMarker fields are invalid.

You can use lifecycle rules to delete the current version, noncurrent versions, expired delete markers, and fragments of objects from a versioning-enabled bucket.

**Table 5** Deleting objects and fragments from a versioning-enabled bucket
Action Type	Effect of Action
Deleting the current version of an object	If the current version is not a delete marker version, a delete marker with a unique version ID is created. The current version becomes a noncurrent version, and the delete marker version becomes the current version. If the current version is a delete marker version, no action is taken.
Deleting a noncurrent version of an object	The noncurrent version is deleted and cannot be restored.
Deleting an expired delete marker	The expired delete marker is deleted. After all noncurrent versions of an object are deleted, the current delete marker version will be deleted to improve the List performance.
Deleting fragments	The fragments are permanently deleted and cannot be restored.

You can use lifecycle rules to delete the current version, noncurrent versions, expired delete markers, and fragments of objects from a versioning-suspended bucket.

**Table 6** Deleting objects and fragments from a versioning-suspended bucket
Action Type	Effect of Action
Deleting the current version of an object	If the current version is not a delete marker version and the version ID is not null, the current version becomes a noncurrent version, and the delete marker version with a null ID becomes the current version. NOTE: After versioning is suspended, a newly uploaded object will have the version ID of null. If the newly uploaded object has the same name as an existing object with a null version ID, this new object will overwrite the existing object. For details, see Versioning. If the current version is not a delete marker version and the current version ID is null, the delete marker version with the null ID overwrites the current version. The delete marker then becomes the current version, and the overwritten version cannot be recovered. If the current version is a delete marker version, no action is taken.
Deleting a noncurrent version of an object	The noncurrent version is deleted and cannot be restored.
Deleting an expired delete marker	The expired delete marker of the object is deleted. After all noncurrent versions of an object are deleted, the current delete marker version will be deleted to improve the List performance.
Deleting fragments	The fragments are permanently deleted and cannot be restored.

Overlapping Lifecycle Rules

Multiple lifecycle rules may overlap. For example:

If a rule has no prefix specified, this rule overlaps with any other rules.
If two rules have the same prefix, they overlap.
If the prefix of a rule is the substring of another rule's prefix, the rules overlap.

If a rule to be created overlaps with an existing one, the rule must meet the following requirements or it will fail to be created:

The rule uses either Days or Date.
The actions on an object take place in the following order: Transition to Infrequent Access > Transition to Archive > Transition to Deep Archive > Delete the object upon expiration.
The overlapping rules do not contain the same action, for example, deleting objects, transitioning to Infrequent Access, Archive, or Deep Archive storage.
If there are two overlapping rules, one can be configured to delete the current version of an object and the other to delete the expired delete markers.

Precautions

Encrypted objects remain encrypted when their storage class is transitioned.

Minimum storage duration

The minimum storage duration is the minimum billable storage duration. This means that objects will be billed for the minimum storage duration even if they are not stored for that long. For example, if an object is transitioned to Archive after being stored in Infrequent Access for 20 days, it will be billed for the storage of 30 days (the minimum storage duration for Infrequent Access).

Item	Standard	Infrequent Access	Archive	Deep Archive (in OBT)
Minimum storage duration	N/A	30 days	90 days	180 days

Related Operations

How Do I Check Whether an Object Version Has a Delete Marker?

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.
Enable Historical Version to check whether the versions of the object have a delete marker.