Configuring a Lifecycle Rule

Creating a Lifecycle Rule

1. In the navigation pane of OBS Console, choose Object Storage.
2. In the bucket list, click the bucket you want to operate to go to the Objects page.
3. In the navigation pane, choose Overview.
4. In the Basic Configurations area, click Lifecycle Rules. The Lifecycle Rules page is displayed.

   Alternatively, you can choose Basic Configurations > Lifecycle Rules in the navigation pane.

5. Click Create. A dialog box shown in Figure 1 is displayed.
   Figure 1 Creating a lifecycle rule
   

6. Configure a lifecycle rule.
   Basic Information:

   • Status:

     Select Enable to enable the lifecycle rule.

   • Rule Name:

     It identifies a lifecycle rule. A rule name can contain a maximum of 255 characters.

   • Prefix: It is optional.
     • If this field is configured, objects with the specified prefix will be managed by the lifecycle rule. The prefix cannot start with a slash (/) or contain two consecutive slashes (//), and cannot contain the following special characters: \:*?"<>|
     • If this field is not configured, all objects in the bucket will be managed by the lifecycle rule.

   

   • If the specified prefix overlaps with the prefix of an existing lifecycle rule, OBS regards these two rules as one and forbids you to configure the one you are configuring. For example, if there is already a rule with prefix abc in OBS, you cannot configure another rule whose prefix starts with abc.
   • If there is already a lifecycle rule based on an object prefix, you are not allowed to configure another rule that is applied to the entire bucket.

   Current Version or Historical Version:

   

   • Current Version and Historical Version are two concepts for versioning. If versioning is enabled for a bucket, uploading objects with the same name to the bucket creates different object versions. The last uploaded object is called the current version, while those previously uploaded are called historical versions. For more information, see Versioning.
   • You can configure either the Current Version or Historical Version, or both of them.
   • Transition to Infrequent Access After (Days): After this number of days since the last update, objects meeting specified conditions will be transitioned to Infrequent Access. This number must be at least 30.
   • Transition to Archive After (Days): After this number of days since the last update, objects meeting specified conditions will be transitioned to Archive. If you configure to transition objects first to Infrequent Access and then Archive, the objects must stay Infrequent Access at least 30 days before they can be transitioned to Archive. If transition to Archive is used, but transition to Infrequent Access is not, there is no limit on the number of days for transition.
   • Transition to Deep Archive After (Days): After this number of days since the last update, objects meeting specified conditions will be transitioned to Deep Archive. If you configure to transition objects first to Infrequent Access or Archive and then Deep Archive, the objects must stay Infrequent Access at least 30 days or stay Archive at least 90 days before they can be transitioned to Deep Archive. If only transition to Deep Archive is used, and transition to Infrequent Access or Archive is not, there is no limit on the number of days for transition.
   • Delete Objects After (Days): After this number of days since the last update, objects meeting certain conditions will be expired and then deleted. This number must be larger than that specified for any of the transition operations.
   • Delete Fragments After (Days): After this number of days since the fragment generation, OBS will automatically delete fragments in the bucket.
   For example, on January 7, 2015, you saved the following files in OBS:

   • log/test1.log
   • log/test2.log
   • doc/example.doc
   • doc/good.txt
   On January 10, 2015, you saved another four files:

   • log/clientlog.log
   • log/serverlog.log
   • doc/work.doc
   • doc/travel.txt

   On January 10, 2015, you set the objects prefixed with log to expire one day later. You might encounter the following situations:

   • Objects log/test1.log and log/test2.log uploaded on January 7, 2015 might be deleted after the last system scan. The deletion could happen on January 10, 2015 or January 11, 2015, depending on the time of the last system scan.
   • Objects log/clientlog.log and log/serverlog.log uploaded on January 10, 2015 might be deleted on January 11, 2015 or January 12, 2015, depending on whether they have been stored for over one day (since their last update) when the system scan happened.

   One day, supposed you configure objects with the log prefix to be transitioned to Infrequent Access 30 days later, to Archive 60 days later, and then to be deleted 100 days later. OBS would perform these actions on log/clientlog.log, log/serverlog.log, log/test1.log, and log/test2.log as you defined.

   

   In theory, it takes 24 hours at most to execute a lifecycle rule. Because OBS calculates the lifecycle of an object from the next 00:00 (UTC time) after the object is uploaded, there may be a delay in transitioning objects between storage classes and deleting expired objects. Generally, the delay does not exceed 48 hours. If you make changes to an existing lifecycle rule, the rule will take effect again.

7. Click OK to complete the lifecycle rule configuration.

Replicating Lifecycle Rules

1. In the navigation pane of OBS Console, choose Object Storage.
2. In the bucket list, click the bucket you want to operate to go to the Objects page.
3. In the navigation pane, choose Overview.
4. In the Basic Configurations area, click Lifecycle Rules. The Lifecycle Rules page is displayed.

   Alternatively, you can choose Basic Configurations > Lifecycle Rules in the navigation pane.

5. Choose More > Replicate.
6. Select a replication source, which is the bucket whose lifecycle rules you want to replicate.
   

   • The lifecycle rules replicated from a source bucket will not overwrite existing rules in the destination bucket, and any that conflict with the existing ones will not be replicated.
   • Both source and destination buckets must be of the 3.0 version.
   • You can remove the rules that you do not want to replicate.
   • If the destination bucket does not have versioning enabled, rules related to versioning will not be replicated.
   Figure 2 Replicating lifecycle rules
   

7. Click OK to replicate the rules to the destination bucket.

Follow-up Procedure

You can click Enable, Edit, or Disable in the Operation column of a lifecycle rule to enable, edit, or disable the rule.

If you want to delete more than one lifecycle rule at a time, select them and click Delete above the list.