About Transition

You can configure the transition function in the lifecycle configuration to allow OBS to transit objects from one storage class to another. For example:

• For infrequently accessed objects, transit them to Infrequent Access.
• For objects involving no real-time access, transit them Archive.

The supported transition paths are as follows:

• From Standard to Infrequent Access
  • The Standard objects must be stored in OBS for at least 30 days before the transition. For example, if you set the transition time to be 1 day after object creation, the transition will fail.
  • If versioning control is enabled, noncurrent object versions can be transited after they have become noncurrent version for more than 30 days.
• From Standard or Infrequent Access to Archive
  • Archive objects cannot be accessed in real time.

    To access an Archive object, you must retrieve it first to create a temporary copy. This copy is valid for a period that you have specified in the retrieval request. Once the copy becomes invalid, OBS deletes it while the source object remains in archive.

  • Archive objects cannot be transited to Standard or Infrequent Access objects.
  • If you have specified the transition times both to Infrequent Access and to Archive, the transition time to Infrequent Access must be at least 30 days earlier than that to Archive. For example, if the time for transition to Infrequent Access is set to 30 days after object creation, the time for transition to Archive cannot be shorter than 60 days after object creation.

    OBS does not support transition from Archive to Standard. If you want to change the storage class of an object from Archive to Standard or Infrequent Access, retrieve it first to generate a temporary copy. Then, use the copy to overwrite the current object version and set the storage class to Standard or Infrequent Access.

You can use these lifecycle rules together to manage the whole lifecycle of an object, including transition to Infrequent Access, transition to Archive, and expiration.

Suppose you have created objects with a specific lifecycle. At the first 30 days, these objects are frequently accessed. Then, in the next 60 days, these objects are infrequently accessed. And then, real-time access to these objects is no longer needed. You can choose to archive or delete them. In such cases, you can set the transition rules as follows:

• Transit objects to Infrequent Access 30 days after creation.
• Transit objects to Archive 90 days after creation.
• Specify the validity duration of these objects, after which they will expire.

Objects are transited to Archive objects in an asynchronous manner. The time when transition actually takes place may not be exactly the same as the transition time specified in the lifecycle rule.

About Object Archiving (Transition to Archive)

For objects requiring no real-time access, OBS provides the Archive storage class that is perfectly suitable for archiving objects.

Every object in OBS is classified into one storage class. When an object is uploaded, OBS associates it with the storage classes of the bucket by default. For example, if the storage class of the bucket is Standard, the object is also Standard by default. You can also specify the storage class of the object as Standard, Infrequent Access or Archive when uploading it.

The lifecycle configuration allows only unidirectional conversion from Standard or Infrequent Access to Archive storage class. If you want to change the storage class of an object from Archive to Standard or Infrequent Access, you must retrieve the object of Archive storage class, copy the object, and specify the storage type of the new object.

About Expiration

Some objects stored in a bucket may have defined survival periods. Suppose you periodically upload logs to your bucket and these logs only need to be retained for a certain period. You can set the expiration rules for these logs. After doing this, OBS will permanently or logically delete the expired ones based on the versioning status.

OBS provides the Expiration action which allows you to set the expiration time for objects. In addition, for buckets with versioning enabled, OBS provides the NoncurrentVersionExpiration operation which allows you to set the expiration time for noncurrent object versions.

For buckets with versioning disabled, the Expiration action allows you to delete the expired objects permanently.

If versioning control is enabled (or suspended) for a bucket, the Expiration action will logically delete the current version of an object by creating a delete marker for the current version and recognizing the delete marker as the new current version. The NoncurrentVersionExpiration action deletes objects of noncurrent versions permanently.

Beside buckets, you can also configure the expiration time for objects during object uploads. The expiration time of objects prevails against that of buckets.

After an object expires, OBS adds the object to the deletion queue and delete it asynchronously. This may cause the deletion time to be later than the expiration time. After an object expires, you will not be charged for the related storage duration fee.

To query the planned expiration time of an object, you can the GET object API or HEAD object API. The APIs return response headers that provide expiration information about the object.

Lifecycle for Versioning Control

Lifecycle configuration can be added to a bucket with versioning control enabled or disabled. By default, versioning control is disabled. You can enable it. If versioning control is enabled for a bucket, the bucket will maintain the current object version and zero or more noncurrent object versions. You can manage object storage costs using versioning control and lifecycle rules. The predefined lifecycle configuration actions can facilitate management over the lifecycle of the current object versions and non-current object versions.