Object Storage Service:Configuration elements

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 following sections describe the elements that you can configure in the configuration file of lifecycle rules for objects, such as the ID and Operation elements.

ID

The ID element specifies the ID of the lifecycle rule that is configured for a bucket. The ID of a lifecycle rule can be up to 255 bytes in length. If you do not configure this element or you leave this element empty, Object Storage Service (OSS) automatically generates a unique ID for the lifecycle rule.

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

The Prefix element specifies the object name prefix based on which the lifecycle rule is applied to all or specific objects in a 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.

Examples:

• You configure a lifecycle rule whose ID is rule1 and specify that the objects whose names contain the dir1 prefix are deleted 30 days after the objects are last modified.

• You configure a lifecycle rule whose ID is rule2, specify that the storage classes of objects whose names contain the dir1 prefix are converted to Infrequent Access (IA) 20 days after the objects are last modified, and specify that the storage classes of objects in the dir1/dir2/ directory are not converted by specifying the Not element.

<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

  The <CreatedBeforeDate> child element specifies a fixed date. All objects that were last modified before the date are deleted, or the storage classes of the objects that were last modified before the date are converted.

• Days

  The <Days> child element specifies the validity period of the objects after the objects were last modified. After the validity period ends, the objects are deleted, or the storage classes of the objects are converted.

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 the operations varies based on the versioning status of the bucket in which the objects are stored. 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.
  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 inserts a delete marker that has a unique version ID. Then, the current version of the object is replaced by the inserted delete marker. If versioning is suspended for the bucket that stores the object, OSS inserts a delete marker whose version ID is null. The inserted delete marker overwrites the current version of the object whose version ID is null to ensure that only one version of the object whose version ID is null exists. 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 only one version of the object exists, the delete marker is removed when the delete marker expires based on the date or validity period that is specified in the lifecycle rule or when the ExpiredObjectDeleteMarker child element is set to true in the lifecycle rule. Important If the Expiration operation of a lifecycle rule that is configured for an object is triggered to delete the current version of the object or a delete operation is initiated without a specified object version, the current version of the object becomes a previous version of the object. If the Expiration operation of a lifecycle rule that is configured for an object is triggered to delete a previous version of the object or a delete operation is initiated on a specified previous version of the object, the previous version of the object is permanently deleted, and only the expired delete marker of the object is retained. You cannot configure the ExpiredObjectDeleteMarker child element and specify a tag in a lifecycle rule 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 number of days from the time when the current versions become previous versions to the time when the previous versions are permanently deleted. Note For example, a version was the current version of an object before May 1, 2019. On May 1, 2019, the PutObject operation was called, and this version became a previous version. In the NoncurrentVersionExpiration element, <NoncurrentDays> is set to 3. On May 4, 2019, the version was permanently deleted. Each time the PutObject operation is called for an object, the current version of the object becomes the most recent previous version. The uploaded version becomes the current version of the object. OSS determines when a version becomes a previous version based on the time when the next version is created.
    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 number of days from the time when the current versions become previous versions to the time when the storage class of the objects is converted. The <StorageClass> child element specifies the storage class to which the storage class of the objects is converted.