Configuration elements - Object Storage Service - Alibaba Cloud Documentation Center

This topic describes the elements that you can configure in the configuration file of lifecycle rules for objects.

Example in the XML format

<LifecycleConfiguration>
<Rule>
 <ID>rule1</ID>
 <Prefix>logs/</Prefix>
 <Status>Enabled</Status>
 <Filter>
    <Not>
      <Prefix>logs1/</Prefix>
      <Tag><Key>key1</Key><Value>value1</Value></Tag>
    </Not>
 </Filter>
 <Expiration>
   <Days>10</Days>
  </Expiration>
</Rule>
<Rule>
 <ID>rule2</ID>
 <Prefix>doc/</Prefix>
 <Status>Disabled</Status>
 <Expiration>
   <CreatedBeforeDate>2017-12-31T00:00:00.000Z</CreatedBeforeDate>
 </Expiration>
</Rule>
<Rule>
 <ID>rule3</ID>
 <Prefix>logs2/</Prefix>
 <Tag><Key>xx</Key><Value>1</Value></Tag>
 <Status>Enabled</Status>
 <Transition>
   <Days>60</Days>
   <StorageClass>Archive</StorageClass>
</Transition>
</Rule>
</LifecycleConfiguration>

The preceding example contains three rules with the following meanings:

The first rule deletes objects whose prefix is logs/ and that were last modified 10 days ago. Objects with the prefix logs1/ and the tag key1:value1 will not be deleted.
The second rule specifies to delete objects with the prefix doc/ that were modified before December 31, 2017. However, because the Status of this rule is Disabled, this rule will not take effect.
The third rule changes the storage class of objects with the prefix logs2/, the tag xx:1, and that were last modified 60 days ago to Archive Storage.

The following sections describe in detail the configuration elements involved in lifecycle rules, such as the ID element and Operation element.

ID

The ID of the lifecycle rule configured for the bucket. The ID can contain up to 255 bytes. If the ID element is not specified or the value is empty, OSS automatically generates a unique ID.

Status

The Status element specifies the status of the lifecycle rule. You can set the status to Enabled or Disabled. Only the lifecycle rules for which the Status element is set to Enabled take effect.

Prefix

Based on the <Prefix> element you specify, the lifecycle rule is applied to all or part of the objects in the bucket.

Filter

The Filter element specifies the filter condition of a lifecycle rule. Objects that meet all conditions that are specified in the Filter element match the rule.

Not

When you use the lifecycle rule to process objects whose names contain a specific prefix and that have specific tags, you may want to skip specific objects. In this case, you can specify the name prefixes and tags of the objects that you want to skip in the Not element.

Note

If multiple lifecycle rules are configured for the bucket, the Not element only takes effect on the associated rule.

Examples:

Rule1 configures that objects with the prefix dir1 are deleted 30 days after they were last modified.
Rule2 configures that objects with the prefix dir1 are converted to Infrequent Access storage class 20 days after they were last modified, and specifies through the Not element not to convert the storage class of objects under dir1/dir2/.

<LifecycleConfiguration> 
  <Rule> 
    <ID>rule1</ID>  
    <Prefix>dir1/</Prefix>  
    <Status>Enabled</Status>  
    <Expiration> 
      <Days>30</Days> 
    </Expiration> 
  </Rule>  
  <Rule> 
    <ID>rule2</ID>  
    <Prefix>dir1/</Prefix>  
    <Status>Disabled</Status>  
    <Filter> 
      <Not> 
        <Prefix>dir1/dir2/</Prefix> 
      </Not> 
    </Filter>  
    <Transition> 
      <Days>20</Days>  
      <StorageClass>IA</StorageClass> 
    </Transition> 
  </Rule> 
</LifecycleConfiguration>

As a result, the Not element takes effect only on rule2. The objects whose names contain the dir1 prefix are deleted 30 days after the objects are last modified based on rule1.

For more information, see Lifecycle rules based on the last modified time.

Time

Date
Use the <CreatedBeforeDate> child element to specify a specific date, and perform expiration (Expiration) or storage class conversion (Transition) operations on objects that were last modified before this date.
Days
Use the <Days> child element to specify a relative number of days, and perform expiration or storage class conversion operations on specified objects N days after they were last modified.

Operation

You can configure one or more operation elements in a lifecycle rule for objects that match the lifecycle rule. OSS performs the specified operations on the objects when the objects expire. The effect of these operations depends on the versioning status of the bucket. The following tables describe how the versioning status of the bucket affects the operation that is specified in the lifecycle rule for objects.

Bucket for which versioning is disabled

Operation	Description
Transition	The storage classes of objects that match the lifecycle rule are converted when the objects expire based on the date or validity period that is specified in the lifecycle rule. For more information about the storage classes that you can specify in lifecycle rules, see Convert storage classes automatically through lifecycle rules.
Expiration	The objects that match the lifecycle rule are deleted when the objects expire based on the date or validity period that is specified in the lifecycle rule.

Bucket for which versioning is enabled

The following tables describe the Operation elements that can be specified in lifecycle rules for objects in versioned buckets. Versioned buckets include the buckets for which versioning is enabled and the buckets for which versioning is suspended:

Delete or storage class conversion operation on the current version of an object

Operation

Description

Expiration

The operation performed on an expired object varies based on whether the current version of the object is a delete marker.

If the current version of the object is not a delete marker, OSS processes the version based on the following rules:
- If versioning is enabled for the bucket that stores the object, OSS will insert a delete marker with a unique version ID as the current version, and the original current version will become a previous version.
- If versioning is suspended for the bucket that stores the object, OSS will insert a delete marker with a null version ID as the current version, and the version with a null version ID in the original current version will be overwritten to ensure that an object has only one version with a null version ID.
If the current version of the object is a delete marker, OSS processes the version based on the following rules:
- If one or more previous versions of the object exist, no operation that is specified in the lifecycle rule is triggered.
- If the object has only one version, OSS will automatically remove the delete marker if a rule with ExpiredObjectDeleteMarker set to true is configured through Expiration, or if a rule to delete the current version is configured through Expiration.
  Important
  - For the current version of an object, when you configure a lifecycle rule to delete it or initiate a deletion operation without specifying a version, the current version will be set as a previous version. For all previous versions of an object, after you configure a lifecycle rule to delete them or initiate a deletion operation with a specified version, all previous versions will be permanently deleted. At this point, only the unique delete marker remains as the current version, which is an expired delete marker.
  - The ExpiredObjectDeleteMarker child element cannot be configured with tag rules at the same time.

Transition

The storage class of the current version of the objects that match the lifecycle rule is converted when the objects expire based on the date or validity period that is specified in the lifecycle rule.

Delete or storage class conversion operation on the previous versions of objects

Operation	Description	Associated child element
NoncurrentVersionExpiration	The objects that match the lifecycle rule are deleted when the previous versions expire based on the date or validity period that is specified in the lifecycle rule.	The `<NoncurrentDays>` child element specifies the relative expiration time, which represents the retention period from when a version changes from the current version to a previous version until it is permanently deleted. Note For example, if a version was originally the current version and became a previous version on May 1, 2019 due to a PutObject overwrite operation. If the `<NoncurrentDays>` expiration time is set to 3 days in the NoncurrentVersionExpiration element, this version will be completely deleted on May 4, 2019. Due to version continuity, each time an upload operation is performed, the current version becomes the first previous version, and the newly added version becomes its successor version. OSS determines when a version becomes a previous version by checking the creation time of its successor version.
NoncurrentVersionTransition	The storage classes of objects that match the lifecycle rule are converted when the previous versions of the objects expire based on the date or validity period that is specified in the lifecycle rule.	The `< NoncurrentDays>` child element specifies the relative conversion time, which represents the time period from when a version changes from the current version to a previous version until the storage class conversion is performed. The `<StorageClass>` child element specifies the storage class to which the object will be converted.