Object Storage Service:Lifecycle configuration elements

Lifecycle rule XML example

<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 configuration elements in a lifecycle rule, such as the ID and Operation elements.

ID element

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

Status element

Indicates the status of the lifecycle rule. You can set the status to Enabled or Disabled. If a rule is Disabled, OSS ignores its defined actions.

Prefix element

Use the <Prefix> element to apply the lifecycle rule to all or a subset of objects in a bucket based on their name prefix.

Filter element

The Filter element specifies the conditions for a lifecycle rule. An object matches the rule only if it meets all conditions within the Filter element.

Not element

To exclude specific objects from a rule that matches both a prefix and a tag, use the Not element. Within Not, specify the prefix and tags of the objects to exclude from the rule's actions.

<LifecycleConfiguration>
  <Rule>
    <ID>rule1</ID>
    <Prefix>dir/</Prefix>
    <Filter>
      <Not><Prefix>dir/p1/</Prefix></Not>
    </Filter>
    <Status>Enabled</Status>
    <Expiration><Days>30</Days></Expiration>
  </Rule>
  <Rule>
    <ID>rule2</ID>
    <Prefix>dir/</Prefix>
    <Filter>
      <Not><Prefix>dir/p2/</Prefix></Not>
    </Filter>
    <Status>Enabled</Status>
    <Expiration><Days>30</Days></Expiration>
  </Rule>
</LifecycleConfiguration>

<LifecycleConfiguration>
  <Rule>
    <ID>rule1</ID>
    <Prefix>dir/</Prefix>
    <Filter>
      <Not><Prefix>dir/p1/</Prefix></Not>
      <Not><Prefix>dir/p2/</Prefix></Not>
    </Filter>
    <Status>Enabled</Status>
    <Expiration><Days>30</Days></Expiration>
  </Rule>
</LifecycleConfiguration>

The following is a configuration example:

• Rule rule1 deletes objects with the prefix dir1/ 30 days after their last modified date.

• Rule rule2 is configured to transition objects with the prefix dir1/ to the Infrequent Access (IA) storage class 20 days after their last modified date, and to exclude objects under dir1/dir2/. However, this rule is inactive because its status is Disabled.

<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>

The Not element is effective only for rule2. Objects with the prefix dir1/ are still subject to rule1, which will delete them 30 days after their last modified date.

For more information, see Rules based on the last modified date.

Time elements

• By specific date

  Use the <CreatedBeforeDate> child element to specify a fixed date. The Expiration or Transition action applies to objects whose last modified date is before this date.

• By a number of days

  Use the <Days> child element to specify a relative number of days. The Expiration or Transition action applies to an object N days after its last modified date.

Operation elements

Operation elements in a lifecycle rule instruct OSS to perform specific actions on objects. The effect of these actions depends on the versioning state of the bucket. The following sections summarize the behavior of lifecycle rule actions based on the bucket's versioning state.

• Buckets with versioning disabled

  Actions	Description
  Transition	Transitions an object to a specified storage class after a specified number of days or on a specific date. For more information about the storage classes that a lifecycle rule supports for transition, see Automatically convert the storage class of objects by using lifecycle rules.
  Expiration	Permanently deletes matching objects after a specified number of days or on a specific date.

• Version-controlled buckets

  The following describes the lifecycle-related elements for objects in version-controlled buckets (buckets with versioning enabled or suspended):

  • Expiration and transition actions for current versions

    Actions	Description
    Expiration	The expiration behavior depends on whether the current version of the object is a delete marker: If the current version is not a delete marker: If versioning is enabled, OSS inserts a delete marker with a unique version ID as the current version. The original current version becomes a noncurrent version. If versioning is suspended, OSS inserts a delete marker with a null version ID as the current version. OSS overwrites the existing version with a null version ID to ensure that an object has only one version with a null version ID. If the current version is a delete marker: If the object has one or more noncurrent versions, OSS performs no action when the Expiration action is triggered. If it is the only version of the object, OSS automatically removes the delete marker if the Expiration rule includes the ExpiredObjectDeleteMarker element set to true, or if the rule is set to delete the current version. Important When you configure a lifecycle rule to delete the current version of an object or perform a non-version-specific delete operation, the action converts the current version into a noncurrent version. When you configure a lifecycle rule to delete all noncurrent versions of an object or perform a version-specific delete operation, the action permanently deletes all noncurrent versions. If only the delete marker remains as the current version, it is called an expired delete marker. The ExpiredObjectDeleteMarker child element cannot be configured together with a tag-based rule.
    Transition	Transitions the current version of an object to a specified storage class when a specified date or time period in the object's lifecycle is reached.

  • Expiration and transition actions for noncurrent versions

    Actions	Description	Associated elements
    NoncurrentVersionExpiration	Expires noncurrent versions of an object.	The <NoncurrentDays> child element specifies the number of days to retain a noncurrent version before OSS permanently deletes it. The period starts from the time the version becomes noncurrent. Note For example, a version becomes noncurrent on May 1, 2019, due to a PutObject overwrite operation. If <NoncurrentDays> in the NoncurrentVersionExpiration element is set to 3, OSS permanently deletes this noncurrent version on May 4, 2019. Due to version continuity, each upload operation makes the current version the first noncurrent version, and the newly added version becomes its successor. OSS determines when a version became noncurrent by checking the creation time of its successor.
    NoncurrentVersionTransition	Transitions the storage class of noncurrent versions of an object.	The <NoncurrentDays> child element specifies the number of days after a version becomes noncurrent to wait before transitioning its storage class. The <StorageClass> child element specifies the target storage class for the object.