Object Storage Service:Configuration examples

Specify a filter condition

Each lifecycle rule contains at least one filter condition, which determines whether the lifecycle rule applies to specific or all objects in a bucket. The following examples show how to specify a filter condition in lifecycle configurations:

Example 1: Convert the storage class of and delete the objects whose names contain a specific prefix after a specific number of days has elapsed

In the lifecycle rule configurations, the doc/ prefix is specified as a filter condition. This condition specifies that the lifecycle rule applies only to objects whose names are prefixed with doc/, such as doc/test1.txt and doc/test2.jpg. The rule specifies that the storage class of objects that match the rule is converted to Infrequent Access (IA) 180 days after the objects are last modified and the objects that match the rule are deleted 365 days after the objects are last modified.

The following examples show the configurations of the lifecycle rule in the XML format and in the Object Storage Service (OSS) console:

• Configurations in the XML format

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule0</ID>
      <Prefix>doc/</Prefix>
      <Status>Enabled</Status>
      <Expiration>
        <Days>365</Days>
      </Expiration>
      <Transition>
        <Days>180</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
    </Rule>
  </LifecycleConfiguration>

• Configurations in the OSS console

  Note

  The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.

  

Example 2: Delete all objects in the bucket after a specific number of days has elapsed

In the following lifecycle configuration example, the filter condition specifies that the lifecycle rule applies to all objects in the bucket. All objects in the bucket expire 300 days after the objects are last modified based on the lifecycle rule.

The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

• Configurations in the XML format

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule1</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Expiration>
        <Days>300</Days>
      </Expiration>
    </Rule>
  </LifecycleConfiguration>

• Configurations in the OSS console

  Note

  The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.

  

Example 3: Delete all objects that are modified before a specific date in the bucket

In the following lifecycle configuration example, the Prefix parameter is not configured and the filter condition specifies that the lifecycle rule applies to all objects in the bucket. All objects that are modified before December 30, 2021 expire based on the lifecycle rule.

The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

• Configurations in the XML format

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule0</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Expiration>
        <CreatedBeforeDate>2021-12-30T00:00:00.000Z</CreatedBeforeDate>
      </Expiration>
    </Rule>
  </LifecycleConfiguration>

• Configurations in the OSS console

  Note

  The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.

  

Specify overlapping filter conditions

The following examples show whether the operations specified in lifecycle rules conflict when the filter conditions of the lifecycle rules overlap.

Example 1: Operations specified by lifecycle rules based on overlapping prefixes (no conflicts)

Execution result: The two rules do not conflict. Therefore, the operations specified in the two lifecycle rules take effect.

The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

• Configurations in the XML format

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule1</ID>
      <Prefix>test/</Prefix>
      <Status>Enabled</Status>
      <Transition>
        <Days>30</Days>
        <StorageClass>Archive</StorageClass>
      </Transition>
    </Rule>
   <Rule>
      <ID>test-rule2</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Expiration>
        <Days>365</Days>
      </Expiration>
    </Rule>  
  </LifecycleConfiguration>

• Configurations in the OSS console

  Note

  The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.

  • Rule 1

  • Rule 2

Example 2: Operations specified by lifecycle rules based on tags (conflicts)

If an object has the two tags specified in the two lifecycle rules, both lifecycle rules apply to the object.

Execution result: The object expires 10 days after the object is last modified. After the object is deleted, the storage class conversion operation specified in the first lifecycle rule cannot be performed. Therefore, only the expiration operation specified in the second lifecycle rule takes effect.

The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

• Configurations in the XML format

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule1</ID>
      <Prefix></Prefix>
      <Tag>
        <Key>tag1</Key>
        <Value>value1</Value>
      </Tag>
      <Status>Enabled</Status>
      <Transition>
        <Days>180</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
    </Rule>
    <Rule>
      <ID>test-rule2</ID>
      <Prefix></Prefix>
      <Tag>
        <Key>tag2</Key>
        <Value>value2</Value>
      </Tag>
      <Status>Enabled</Status>
      <Expiration>
        <Days>10</Days>
      </Expiration>
    </Rule>
  </LifecycleConfiguration>

• Configurations in the OSS console

  Note

  The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.

  • Rule 1

  • Rule 2

Example 3: Operations specified by lifecycle rules based on the same time (conflicts)

Execution result: The objects that match the rules are deleted after the objects are last modified for more than 365 days.

The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

• Configurations in the XML format

  <LifecycleConfiguration>
    <Rule>
      <ID>rule1</ID>
      <Prefix></Prefix>    
      <Status>Enabled</Status>
      <Transition>
        <Days>365</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
    </Rule>
    <Rule>
      <ID>rule2</ID>
      <Prefix></Prefix>    
      <Status>Enabled</Status>
      <Expiration>
        <Days>365</Days>
      </Expiration>
    </Rule>
  </LifecycleConfiguration>

• Configurations in the OSS console

  Note

  The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.

  • Rule 1

  • Rule 2

Example 4: Operations specified by lifecycle rules based on overlapping prefixes and the same operations (conflicts)

This example shows how lifecycle rules are applied when the conditions specified in the lifecycle rules conflict. Assume that you specify the following lifecycle rules:

• Rule 1 specifies the storage class of all objects is converted to IA 30 days after the objects are last modified.

• Rule 2 specifies the storage class of objects whose names contain the logs/ prefix is converted to IA 180 days after the objects are last modified.

Execution result: The storage class of all objects is converted to IA 30 days after the objects are last modified.

The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

• Configurations in the XML format

  <LifecycleConfiguration>
    <Rule>
      <ID>rule1</ID>
      <Prefix>logs/</Prefix>
      <Status>Enabled</Status>
      <Transition>
        <Days>180</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
    </Rule>
   <Rule>
      <ID>rule2</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Transition>
        <Days>30</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
    </Rule>  
  </LifecycleConfiguration>

• Configurations in the OSS console

  Note

  The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.

  • Rule 1

  • Rule 2

Disable lifecycle rules

This example shows how lifecycle rules are applied when the conditions specified in the lifecycle rules conflict. Assume that you specify the following lifecycle rules:

• Rule 1 is enabled and specifies the storage class of objects whose names contain the logs/ prefix is converted to IA 100 days after the objects are created.

• Rule 2 is disabled and specifies the storage class of objects whose names contain the documents/ prefix is converted to Archive 50 days after the objects are created.

Execution result: Only the lifecycle rule in which the Status parameter is set to Enabled takes effect.

The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

• Configurations in the XML format

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule1</ID>
      <Prefix>logs/</Prefix>
      <Status>Disabled</Status>
      <Transition>
        <Days>100</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
    </Rule>
    <Rule>
      <ID>test-rule2</ID>
      <Prefix>documents/</Prefix>
      <Status>Enabled</Status>
      <Transition>
        <Days>50</Days>
        <StorageClass>Archive</StorageClass>
      </Transition>
    </Rule>
  </LifecycleConfiguration>

• Configurations in the OSS console

  Note

  The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.

  • Rule 1

  • Rule 2

Configure lifecycle rules for versioned buckets

In a versioned bucket, each object has a current version and may have previous versions. For more information about versioning, see Overview.

Example 1: Convert the storage class of and delete the previous versions of objects after a specific number of days has elapsed

The lifecycle rule specifies that the storage class of all objects in the bucket is converted to IA 10 days after the objects are last modified and to Archive 60 days after the objects become previous versions. In addition, objects are deleted 90 days after the objects become previous versions.

The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

• Configurations in the XML format

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule0</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Transition>
        <Days>10</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
      <NoncurrentVersionTransition>
        <NoncurrentDays>60</NoncurrentDays>
        <StorageClass>Archive</StorageClass>
      </NoncurrentVersionTransition>
      <NoncurrentVersionExpiration>
        <NoncurrentDays>90</NoncurrentDays>
      </NoncurrentVersionExpiration>
    </Rule>
  </LifecycleConfiguration>

• Configurations in the OSS console

  Note

  The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.

  

Example 2: Delete expired delete markers

If the current version of an object is a delete marker and other versions of the object are deleted, the delete marker expires. You can configure the following lifecycle rule to delete expired delete markers.

The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

• Configurations in the XML format

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule0</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Expiration>
        <ExpiredObjectDeleteMarker>true</ExpiredObjectDeleteMarker>
      </Expiration>
    </Rule>
  </LifecycleConfiguration>

• Configurations in the OSS console

  Note

  The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.

  

Configure lifecycle rules to delete expired parts

Assume that you use multipart upload to upload an object and do not call the CompleteMultipartUpload operation to complete the multipart upload task. In this case, you can configure a lifecycle rule to specify that parts whose names contain the logs prefix expire 5 days after the parts are uploaded.

The following examples show the configurations of the lifecycle rule in the XML format and in the OSS console:

• Configurations in the XML format

  <LifecycleConfiguration>
    <Rule>
      <ID>lifecyclerule1</ID>
      <Prefix>logs/</Prefix>
      <Status>Enabled</Status>
      <AbortMultipartUpload>
        <Days>5</Days>
      </AbortMultipartUpload>
    </Rule>
  </LifecycleConfiguration>

• Configurations in the OSS console

  Note

  The following figure shows the configurations of the preceding lifecycle rule in the OSS console. For more information, see Configure lifecycle rules.