All Products
Search
Document Center

Object Storage Service:Configure lifecycle rules based on the last modified time for versioning-enabled buckets to reduce storage costs

Last Updated:May 15, 2024

Object Storage Service (OSS) saves overwritten or deleted data in a versioning-enabled bucket as previous versions. To reduce storage costs and improve object listing performance, you can configure lifecycle rules to delete expired delete markers and previous versions that you no longer need.

Prerequisites

Versioning is enabled for the bucket. For more information, see Enable versioning.

Scenarios

For example, a user uploaded the example.txt file to the versioning-enabled examplebucket bucket on February 8, 2020, and later within the same year, performed several overwrite operations on the example.txt object or deletion operations with no version IDs specified, as shown in the following figure. OSS generated a globally unique version ID for each overwrite operation or delete operation, and saved overwritten and deleted data as previous versions in the bucket. The version IDs in the following figure are not real version IDs and are provided in simple forms for readability.versioning

To meet business requirements, the user wants to manage the versions of the example.txt object to achieve the following goals:

  • Retain only the versions that were generated on May 8, 2020 and September 10, 2020.

  • Restore the latest previous version generated on May 8, 2020 to the current version.

Usage notes

When you configure lifecycle rules to manage object versions, take note of the following items:

  • Expiration policy for the current version of an object

    • In a versioning-enabled bucket, if the expiration policy specified in a lifecycle rule is implemented on the current version of an object, OSS adds a delete marker to the object and stores the current version as a previous version. The delete marker becomes the current version of the object.

    • In a versioning-suspended bucket, if the expiration policy specified in a lifecycle rule is implemented on the current version of an object, OSS adds a delete marker whose version ID is null to the object as the new current version. If the object has an existing version whose version ID is null, the existing version is overwritten by the delete marker because an object can have only one version whose version ID is null.

  • Expiration policy for a previous version of an object

    In a bucket for which versioning is enabled or suspended, if the expiration policy specified in a lifecycle is implemented on a previous version of an object, the previous version is permanently deleted and cannot be restored.

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

Procedure

  1. Retain specified object versions

    Assume that the current date is September 10, 2020. In this case, the user can perform the following steps to configure a lifecycle rule to retain only the versions uploaded on May 8, 2020 and September 10, 2020.

    1. Log on to the OSS console.

    2. In the left-side navigation pane, click Buckets. On the Buckets page, click examplebucket.

    3. In the left-side navigation tree, choose Data Management > Lifecycle.

    4. On the Lifecycle page, click Create Rule. In the Create Rule panel, configure the parameters described in the following table and retain the default settings for other parameters.

      Section

      Parameter

      Description

      Basic Settings

      Status

      Select Enabled.

      Applied To

      Select Whole Bucket.

      Policy for Current Versions

      Object Lifecycle

      Select Removal of Delete Marker.

      Policy for Previous Versions

      Object Lifecycle

      Select Validity Period (Days).

      Lifecycle-based Rules

      Enter 90 in the text box. An object version expires 90 days after it is stored as a previous version and is deleted the next day after it expires.

      Policy for Parts

      Part Lifecycle

      Select Validity Period (Days).

      Rules for Parts

      Enter 90 in the text box. Parts that are generated in multipart upload tasks expire 90 days after they are generated and are deleted the next day after they expire.

    5. Click OK.

  2. Restore a specific object version

    To restore the previous version that is generated on May 8 to the current version, perform the following steps:

    1. In the left-side navigation tree of the examplebucket bucket, choose Object Management > Objects.

    2. In the upper-right corner of the object list, click Show next to Previous Versions.

    3. On the Objects page, find the object version that you want to restore to the current version.

    4. Click Restore in the Actions column.

References

You can call API operations to restore objects. To restore a previous version of an object to the current version, you can copy the previous version of the object to the bucket in which the object is stored. OSS stores the previous version of the object as the current version. For more information, see CopyObject.