# Configuring Bucket Lifecycle Rules

#### Functions

This operation configures lifecycle rules that can delete or migrate objects from a bucket at a specified time. Typical application scenarios:

- Delete periodically uploaded files. Some files uploaded periodically need only to be retained for only one week or one month.
- Delete files that are frequently accessed within a certain period of time but are seldom accessed afterward. You can archive these files and then schedule the time for deletion.
- The minimum time for the transition of the bucket storage to Warm or to Cold can be configured. The value ranges from 24 to 8640.

You can perform this operation to create or update the lifecycle configuration of a bucket.

Objects are permanently deleted upon the expiration of their lifecycle time, and the deleted objects cannot be restored.

To perform this operation, you must have the PutLifecycleConfiguration permission. By default, only the bucket owner can perform this operation. The bucket owner can grant the permission to other users by configuring the bucket policy or user policy.

The lifecycle configuration enables OBS to delete objects and transition object storage classes at a scheduled time. To prevent a user from doing so, the following permissions granted to the user must be revoked:

- DeleteObject
- DeleteObjectVersion
- PutLifecycleConfiguration

If you want to forbid a user to set the bucket lifecycle configuration, revoke the PutLifecycleConfiguration permission from the user.

#### Request Syntax

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39

    PUT /?lifecycle HTTP/1.1
    Host: bucketname.obs.region.example.com
    Content-Length: length
    Date: date
    Authorization: authorization
    Content-MD5: MD5
    <?xml version="1.0" encoding="UTF-8"?>
    <LifecycleConfiguration>
        <Rule>
            <ID>id</ID>
            <Prefix>prefix</Prefix>
            <Status>status</Status>
            <Expiration>
                <Days>days</Days>
            </Expiration>
            <NoncurrentVersionExpiration>
                <NoncurrentDays>days</NoncurrentDays>
            </NoncurrentVersionExpiration>
            <Transition>
             <Days>30</Days>
              <StorageClass>WARM</StorageClass>
            </Transition>
            <Transition>
             <Days>60</Days>
             <StorageClass>COLD</StorageClass>
            </Transition>
            <NoncurrentVersionTransition>
             <NoncurrentDays>30</NoncurrentDays>
             <StorageClass>WARM</StorageClass>
            </NoncurrentVersionTransition>
            <NoncurrentVersionTransition>
             <NoncurrentDays>60</NoncurrentDays>
             <StorageClass>COLD</StorageClass>
            </NoncurrentVersionTransition>
            <AbortIncompleteMultipartUpload>
                <DaysAfterInitiation>10</DaysAfterInitiation>
            </AbortIncompleteMultipartUpload>
        </Rule>
    </LifecycleConfiguration>

#### Request Parameters

This request contains no parameter.

#### Request Headers

Table 1 lists the request header.

Table 1 Request headers
Header | Description | Mandatory
--- | --- | ---
Content-MD5 | Base64-encoded 128-bit MD5 digest of the message according to RFC 1864. Type: string Example: n58IG6hfM7vqI4K0vnWpog== | Yes

#### Request Elements

In this request, you need to specify the lifecycle configuration in the request body. The lifecycle configuration can be uploaded in the form of an XML file with elements described in Table 2.

- If the versioning of a bucket is enabled or suspended, you can set NoncurrentVersionTransition or NoncurrentVersionExpiration to control the lifecycle of historical object versions. The lifecycle of a historical version depends on the time when it becomes a historical one (time when the version is replaced by a new version) and the value of NoncurrentDays. For object deletion, if NoncurrentDays is set to 1, an object version will be deleted only after it becomes a historical one for one day. If the version V1 of object A is created on the first date of a month and new version V2 is uploaded on the fifth date of the month, V1 becomes a historical version. At 00:00 on the seventh date of the month, V1 will expire. If an object version does not meet the deletion conditions, but NoncurrentDays is set to 1 and StorageClass is set to WARM, the version transitions to the Warm storage class one day after it has become a historical version. For example, the V1 version of object A is created on the first day of a month, and its new version V2 is uploaded on the fifth day of the month. Then V1 becomes a historical version. One day later, that is, at 0 o'clock of the seventh day, V1 transitions to the Warm storage class. The deletion or transition of the object after the expiration time may be delayed. The delay is within 48 hours.
- Objects are processed according to the following procedures, if their latest versions meet the expiration rule and versioning is enabled or suspended for the bucket.
  - Versioning enabled:

    If the latest version of the object does not have the DeleteMarker, the object generates a new DeleteMarker.

    If the object of the latest version has the DeleteMarker and the object has this version only, this version will be deleted.

    If the object of the latest version has the DeleteMarker and the object has other versions, all versions of the object remain unchanged.

  - Versioning suspended:

    If the latest version of the object does not have the DeleteMarker and is not the null version, the object generates a new DeleteMarker for the null version.

    If the latest version of the object does not have the DeleteMarker but is the null version, this null version is overwritten by a new DeleteMarker generated for the null version.

    If the object of the latest version has the DeleteMarker and the object has this version only, this version will be deleted.

    If the object of the latest version has the DeleteMarker and the object has other versions, all versions of the object remain unchanged.

- The following lists the processing when the versioning is enabled or suspended for a bucket and objects of the latest versions meet the transition rules:
- If the latest version of the object has the DeleteMarker, the storage class of this version will not be transitioned.
- If the latest version of the object does not have the DeleteMarker and meets the transition rule, the storage class of this version will be transitioned.

Table 2 Response elements for lifecycle configuration
Name | Description | Mandatory
--- | --- | ---

Date

Specifies that OBS executes lifecycle rules for objects before the specified date. The date must be compliant with the ISO8601 format, and the time must be compliant with the UTC format of 00:00:00. For example: 2018-01-01T00:00:00.000Z, which indicates that objects whose last modification time is earlier than 2018-01-01T00:00:00.000Z are deleted or transitioned to other storage classes. Objects whose last modification time is equal to or later than the specified time are not deleted or dumped.

Type: string

Ancestor node: Expiration, Transition

Required if the Days element is absent.

Days | Specifies the number of days (since the latest update to the latest object version) after which the lifecycle rule takes effect. Type: positive integer Ancestor node: Expiration, Transition | Required if the Date element is absent.
StorageClass | The storage class to which the object is transitioned. Type: string Value options: WARM or COLD Ancestor node: Transition, NoncurrentVersionTransition | Required if the Transition or NoncurrentVersionTransition element is present.
Transition | Transition time and the object storage class after transition (valid only for the latest object version). Type: XML Children node: Date or Days, StorageClass Ancestor node: Rule | Required if the NoncurrentVersionTransition, Expiration, AbortIncompleteMultipartUpload, or NoncurrentVersionExpiration element is absent.
Expiration | Container for the object expiration rule (only applicable to the latest versions of objects). Type: XML Children node: Date or Days Ancestor node: Rule | Required if Transition, NoncurrentVersionTransition, AbortIncompleteMultipartUpload, or NoncurrentVersionExpiration is absent.
ID | Unique identifier of a rule. The value can contain a maximum of 255 characters. Type: string Ancestor node: Rule | No
LifecycleConfiguration | Container for lifecycle rules. You can add multiple rules. The total size of the rules cannot exceed 20 KB. Type: XML Children node: Rule Ancestor node: none | Yes
NoncurrentDays | Number of days when the specified rule takes effect after the object becomes a historical version (only applicable to an object's historical version). Type: positive integer Ancestor node: NoncurrentVersionExpiration, NoncurrentVersionTransition | Required if the NoncurrentVersionExpiration or NoncurrentVersionTransition element is present.
NoncurrentVersionTransition | Transition time of historical object versions and the object storage class after transition. Type: XML Children node: NoncurrentDays, StorageClass Ancestor node: Rule | Required if the Transition, Expiration, AbortIncompleteMultipartUpload, or NoncurrentVersionExpiration element is absent.
NoncurrentVersionExpiration | Container for the expiration time of objects' historical versions. If versioning is enabled or suspended for a bucket, you can set NoncurrentVersionExpiration to delete historical versions of objects that match the lifecycle rule (only applicable to the historical versions of objects). Type: XML Children node: NoncurrentDays Ancestor node: Rule | No
AbortIncompleteMultipartUpload | Container for specifying when the not merged parts (fragments) in an incomplete upload will be deleted. Type: XML Children node: DaysAfterInitiation Ancestor node: Rule | Required if the Transition, Expiration, NoncurrentVersionExpiration, or NoncurrentVersionTransition element is absent.
DaysAfterInitiation | Specifies the number of days since the initiation of an incomplete multipart upload that OBS will wait before deleting the not merged parts (fragments) of the upload. Type: positive integer Ancestor node: AbortIncompleteMultipartUpload | Required if the AbortIncompleteMultipartUpload element is absent.

Prefix

Object name prefix identifying one or more objects to which the rule applies.

Type: string

Ancestor node: Rule

Constraints:

1. When you configure a lifecycle rule by specifying a prefix, if the specified prefix and the prefix of an existing lifecycle rule overlap, OBS regards these two rules as one and forbids you to configure this rule. For example, if there is a rule with the object prefix abc configured in the system, another rule with the object prefix starting with abc cannot be configured.
2. If there is already a lifecycle rule that is based on an object prefix, you are not allowed to configure another rule that is applied to the entire bucket.

Yes

Rule | Container for a specific lifecycle rule. Type: container Ancestor node: LifecycleConfiguration | Yes
Status | Indicates whether the rule is enabled. Type: string Ancestor node: Rule Value options: Enabled, Disabled | Yes

#### Response Syntax

    1
    2
    3

    HTTP/1.1 status_code
    Date: date
    Content-Length: length

#### Response Headers

The response to the request uses common headers. For details, see Table 1.

#### Response Elements

This response contains no elements.

#### Error Responses

No special error responses are returned. For details about error responses, see Table 2.

#### Sample Request

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42

    PUT /?lifecycle HTTP/1.1
    User-Agent: curl/7.29.0
    Host: examplebucket.obs.region.example.com
    Accept: */*
    Date: WED, 01 Jul 2015 03:05:34 GMT
    Authorization: OBS H4IPJX0TQTHTHEBQQCEC:DpSAlmLX/BTdjxU5HOEwflhM0WI=
    Content-MD5: ujCZn5p3fmczNiQQxdsGaQ==
    Content-Length: 919

    <?xml version="1.0" encoding="utf-8"?>
    <LifecycleConfiguration>
      <Rule>
        <ID>delete-2-days</ID>
        <Prefix>test/</Prefix>
        <Status>Enabled</Status>
        <Expiration>
          <Days>70</Days>
        </Expiration>
        <NoncurrentVersionExpiration>
          <NoncurrentDays>70</NoncurrentDays>
        </NoncurrentVersionExpiration>
        <Transition>
          <Days>30</Days>
          <StorageClass>WARM</StorageClass>
        </Transition>
        <Transition>
          <Days>60</Days>
          <StorageClass>COLD</StorageClass>
        </Transition>
        <NoncurrentVersionTransition>
          <NoncurrentDays>30</NoncurrentDays>
          <StorageClass>WARM</StorageClass>
        </NoncurrentVersionTransition>
        <NoncurrentVersionTransition>
          <NoncurrentDays>60</NoncurrentDays>
          <StorageClass>COLD</StorageClass>
        </NoncurrentVersionTransition>
        <AbortIncompleteMultipartUpload>
            <DaysAfterInitiation>10</DaysAfterInitiation>
        </AbortIncompleteMultipartUpload>
      </Rule>
    </LifecycleConfiguration>

#### Sample Response

    1
    2
    3
    4
    5
    6

    HTTP/1.1 200 OK
    Server: OBS
    x-obs-request-id: BF26000001643670AC06E7B9A7767921
    x-obs-id-2: 32AAAQAAEAABSAAgAAEAABAAAQAAEAABCSvK6z8HV6nrJh49gsB5vqzpgtohkiFm
    Date: WED, 01 Jul 2015 03:05:34 GMT
    Content-Length: 0

Parent topic: Advanced Bucket Settings