You can set the lifecycle configuration format to XML. The configuration contains one or more lifecycle rules.

Each rule consists of the following contents:

• Metadata, specifying the rule ID and whether the rule is enabled or disabled. If the rule is disabled, OBS does not perform actions specified in the rule.
• Filtering criteria, specifying the objects to which the rule applies. You can set the object name prefix to be the filtering criteria.
• When (a date or a time period) will one transition or expiration action be performed on objects in the lifecycle.

The following are two examples:

Example 1: Lifecycle configuration of a bucket with versioning control disabled

By default, versioning control is disabled. Each object can have only one version. Assume that you have a bucket with versioning control disabled. You want objects whose name prefix is documents/ to be transited to Infrequent Access objects 30 days after creation, transited to Archive 60 days after creation, and permanently deleted 1 year after creation. To achieve these, you can add the following lifecycle configuration for your bucket. Define a rule that contains the Transition and Expiration actions. Set the Prefix element to documents.

<LifecycleConfiguration> 
    <Rule> 
        <ID>sample-rule</ID> 
        <Prefix>documents/</Prefix> 
        <Status>Enabled</Status> 
        <Expiration> 
             <Days>365</Days> 
        </Expiration> 
        <Transition>  
             <Days>30</Days> 
             <StorageClass>WARM</StorageClass>
        </Transition>  
        <Transition>  
             <Days>60</Days>  
             <StorageClass>COLD</StorageClass>  
        </Transition> 
    </Rule> 
</LifecycleConfiguration>

Example 2: Lifecycle configuration of a bucket with versioning control enabled

You can enable versioning control. If versioning control is enabled for a bucket, the bucket will maintain the current object version and zero or more noncurrent object versions. For more information, see the section about versioning control. Versioning control enables you to maintain the history records of objects and lifecycle management allows you to control the retention of object versions as well as the storage class transition.

For a bucket with versioning control enabled, lifecycle configuration provides multiple predefined actions that can be used to manage noncurrent object versions. In the following example, the lifecycle configuration contains a rule, which specifies the following:

• This rule applies to noncurrent object versions whose name prefix is logs/.
• One NoncurrentVersionTransition action transits objects to Infrequent Access 30 days after they have become noncurrent versions.
• The other NoncurrentVersionTransition action transits objects to Archive 60 days after they have become noncurrent versions.
• The NoncurrentVersionExpiration action makes the objects expire 180 days after they have become noncurrent versions.

<LifecycleConfiguration> 
    <Rule> 
        <ID>sample-rule</ID> 
        <Prefix>logs/</Prefix> 
        <Status>Enabled</Status>    
        <NoncurrentVersionExpiration>      
            <NoncurrentDays>180</NoncurrentDays>     
        </NoncurrentVersionExpiration> 
        <NoncurrentVersionTransition>  
            <NoncurrentDays>30</NoncurrentDays>  
            <StorageClass>WARM</StorageClass>  
        </NoncurrentVersionTransition>  
        <NoncurrentVersionTransition>  
            <NoncurrentDays>60</NoncurrentDays>  
            <StorageClass>COLD</StorageClass>  
        </NoncurrentVersionTransition> 
    </Rule> 
</LifecycleConfiguration>

You can use the predefined NoncurrentVersionTransition and NoncurrentVersionExpiration actions to manage noncurrent versions in your bucket. The following describes the rules and actions in details.

Generally, each lifecycle rule consists of the following parts:

• Metadata: specifying the rule ID (<ID> element) and whether the rule is enabled or disabled (<Status> element). If the rule is disabled, OBS does not perform actions specified in the rule.
• Prefix (<Prefix> element), which is used for identifying objects that the rule applies to.
• Actions that you want to perform on the specified objects (such as NoncurrentVersionTransition and NoncurrentVersionExpiration mentioned in the previous example). Each action includes the date when or time period after which the action will be performed.

The following describes the elements in lifecycle rules in details.

• Element ID

  One lifecycle configuration can have a maximum of 1000 rules. Each rule has a unique ID.

• Element Status

  The value can be Enabled or Disabled. If a rule is disabled, OBS does not perform any actions defined in the rule.

• Element Prefix

  A lifecycle rule applies to one or more objects with the name prefix specified in the rule. Suppose you have the following objects:

  • logs/day1
  • logs/day2
  • logs/day3
  • ExampleObject.jpg

    If you set Prefix to ExampleObject.jpg, the rule applies only to object ExampleObject.jpg. If you set Prefix to logs/, the rule applies to the first three objects whose name starting with logs/. If you leave Prefix null, the rule applies to all objects in your bucket.

• Element Action

  You can specify predefined actions in the lifecycle rule to perform them on your buckets in the lifecycle. The predefined actions include Transition, Expiration, NoncurrentVersionTransition, and NoncurrentVersionExpiration. The action effect depends on the status of versioning control of a bucket.

By default, bucket versioning control is disabled. You can enable bucket versioning control, so that each object has a concurrent version and may have one or more noncurrent versions. As well, you can disable versioning control. For more information about versioning control, see the section about versioning control.

• Action Transition

  This action transits objects to Infrequent Access or Archive. In the specified date or when a certain time period runs out, OBS transits objects that apply to the rule to Infrequent Access or Archive.

  • Bucket with versioning control disabled: The Transition action transits the objects to Infrequent Access or Archive.
  • Bucket with versioning control enabled: The Transition action transits objects of the current version to Infrequent Access or Archive. This action has no impact on noncurrent object versions.
• Action Expiration

  This action makes objects applying to the rule expire. Objects become unavailable once they expire. Whether the expired objects will be permanently deleted depends on the versioning control status of the bucket.

The Expiration action will not delete uploaded parts of an incomplete multipart upload.

• Bucket with versioning control disabled: The Expiration action deletes objects permanently and the deleted objects cannot be restored.
• Bucket with versioning control enabled: This action applies only to current object versions, instead of noncurrent object versions. This action logically deletes current object versions which are not delete markers, by adding delete markers for them as the new current object versions and saving the original ones as noncurrent object versions. This action will not be performed on current object versions who are delete markers. If the current object version is the only version of the object and has a delete marker, OBS will delete the current object version. Clearing a delete marker may take a while, because OBS needs to confirm that the delete marker is the only object version.

If you initiate a GET request on an object whose current version is a delete marker without specifying the version ID, OBS will identify the object as a deleted one and return error 404 Object Not Found. But you can specify the version ID in the GET request to restore the deleted object.

For example, you can set a rule to make the object named photo.gif expire 5 days after creation. If photo.gif is created at 10:30 UTC on January 1, 2016, the expiration rule will be executed at a time point after 00:00 UTC (five days after object creation) on January 7, 2016. The time will not be later than 23:59 UTC on January 7, 2016. For a bucket with versioning disabled, a deletion operation permanently deletes photo.gif. For a bucket with versioning enabled, after the expiration rule is executed, photo.gif (version 111111) is still stored in the bucket and can be accessed if needed, but the current version (version 4857693) of the object has a delete marker. The original object photo.gif turns to be a non-current version. For details about principles of delete markers, see the section about versioning control.

Bucket with versioning control suspended: OBS will create delete markers for expired objects whose version ID is null. Any existing null versions will be overwritten by new null versions, and data associated with this version cannot be restored. For more information about deleting objects from a bucket with versioning control suspended, see the section about versioning control.

• Actions specific to buckets with versioning control enabled (or suspended)

The Transition and Expiration lifecycle actions can manage the lifecycle of current object versions. The NoncurrentVersionTransition and NonCurrentVersionExpiration actions can manage the lifecycle of noncurrent object versions.

The following lifecycle configuration actions can be performed only on buckets with versioning control enabled (or suspended). In a bucket with versioning control enabled, an object may have multiple versions, including a current version and zero or more noncurrent versions. You can use these actions to request the OBS to perform specific operations on noncurrent object versions. These actions do not affect current object versions.

NoncurrentVersionTransition: Specifies the time period after which noncurrent versions will be transited from Standard to Infrequent Access or Archive.

NoncurrentVersionExpiration: Specifies the time period after which noncurrent object versions will be permanently deleted. A deleted object cannot be restored.

For example, if you want to enable a five-day period to correct any accidental deletion or overwriting, you can configure an expiration rule so that the object can be deleted 5 days after it has become a noncurrent version.

At 2016-01-01 10:30 (UTC time), you created an object named photo.gif whose version ID is 111111. At 2016-01-02 10:30 (UTC time), you accidentally deleted this object and OBS created a delete marker for this object using a new version ID, 4857693. In the next five days, you were allowed to restore the original object photo.gif whose version ID is 111111.

At 2016-01-08 00:00 (UTC time), the NoncurrentVersionExpiration action permanently deleted object photo.gif whose version ID is 111111 (after it became a noncurrent version for 5 days.)

How does OBS verify the number of days an object has become a noncurrent version

In a bucket with versioning control enabled, an object may have multiple versions, including a current version and zero or more noncurrent versions. Every time an object is uploaded, the existing current version is saved as a noncurrent version, while the uploaded version becomes the current version. To verify the days an object version has become a noncurrent version, OBS checks the creation time of the corresponding object of the current version. OBS uses the days that the object of the current version has been created as the days that the object of a noncurrent version has existed.

Restoring a noncurrent version using the lifecycle configuration

You can use either of the following methods to search for noncurrent object versions:

1. Copy a noncurrent object version to the same bucket. The copied version will become the current version and all object versions are reserved.
2. Delete the current object version permanently. After you delete the current version of an object, a noncurrent version of the object becomes the current version.

If the lifecycle rules are applied to a bucket with versioning control enabled, you are advised not to use the second method. Use method 1 instead.

Due to the consistency syntax of OBS, before the communication mode is changed, a current version that is permanently deleted may not disappear (OBS may be unaware of this deletion action). In addition, the expiration action for noncurrent versions, if you have configured, may delete the noncurrent object versions permanently, including those you want to restore. Therefore, method 1 is more secure.

The following table describes relationship between the actions executed on objects and versioning control status of the buckets to which the objects belong.

• Date-based lifecycle rules

You can specify the execution dates for Transition and Expiration actions. The dates must conform to the ISO8601 standards and the exact time is always 00:00 (UTC time). If a specified date in the past, the corresponding action will be immediately performed on all objects that apply to this lifecycle.

A lifecycle action with a date specified is not a one-off action. Even if the date has passed, OBS will adopt this action as long as the lifecycle is enabled.

Assume you have specified a date for performing the Expiration action to delete all objects (without setting any filtering criteria). On the specified date, OBS makes all objects in the bucket expire. In addition, OBS continues to make all new objects created in the bucket expire. To terminate the Expiration action, you have to delete this action from your lifecycle configuration, disable the rule, or delete the rule from the lifecycle configuration.

You cannot create date-based lifecycle rule on OBS Console.

• Time period-based lifecycle rule

You can specify how many days after an object is created will the Transition or Expiration action will be performed on the object. After the days are specified, OBS adds the specified days when setting time for an object and starts calculating the time from 00:00 (UTC time) of the next day. For example, you created an object at 2016-01-15 10:30 (UTC time) and you specified that objects would be transited 3 days after creation, the object would be transited at 2016-01-19 00:00 (UTC time).

OBS only records the last modification date for each object. On OBS Console, you can view the last modification time (LastModified) of an object on the object properties page. After an object is created, the date is the creation date. If the object is replaced, the date will also change. Therefore, the creation date is a synonym of the last modification date.

When using the NoncurrentVersionTransition or NoncurrentVersionExpiration action, you can specify how many days after an object changes to be a noncurrent version (due to overwrite or deletion) will the action be performed on the object.

After the days are specified, OBS adds the specified days to the date when the creation date of the object version and starts calculating the time from 00:00 (UTC time) of the next day. For example, in your bucket, the current version of an object was created at 2016-01-01 10:30 (UTC time), the later version that replaced this version was created at 2016-01-15 10:30 (UTC time), and you specified that an object would be transited 3 days after becoming a noncurrent version, the object was transited at 2016-01-19 00:00 (UTC time).

When configuring the lifecycle rules, within a rule and for rules whose prefixes have inclusion relationship, Date or Days of Transition and Expiration must be identical.