Changing the Storage Classes of Buckets and Objects

Scenarios

This section describes how to change the storage classes of buckets and objects.

Constraints

• The storage class of a bucket can only be manually changed. The storage class of an object can be changed manually or automatically based on lifecycle rules.
• The data redundancy policy remains unchanged when the storage class is changed. If a bucket is configured with multi-AZ redundancy, it can only be moved to a storage class that supports multi-AZ redundancy, such as the Standard or Warm storage class. However, it cannot be moved to the Cold storage class, which does not support multi-AZ redundancy.

Manually Changing the Storage Class of a Bucket

1. Log in to OBS Console. In the navigation pane, choose Object Storage.
2. In the bucket list, locate the bucket whose storage class you want to change and click Change Storage Class in the Operation column on the right.
3. Choose a new storage class and click OK.

Manually Changing the Storage Class of an Object

1. Log in to OBS Console. In the navigation pane, choose Object Storage.
2. In the bucket list, click the bucket name you want. The Objects page is displayed.
3. Restore objects that are in the Cold storage class if there are any. For details, see Restoring an Object from Cold Storage.
4. Change the storage class of objects individually or in a batch.
   1. Individually: In the object list, locate the desired object and choose More > Change Storage Class in the Operation column on the right.
   2. In a batch: In the object list, select the desired objects and choose More > Change Storage Class above the object list.

5. Choose a new storage class and click OK.

Changing the Storage Class of an Object Using Lifecycle Rules

1. In the bucket list, click the bucket you want to operate. The Overview page is displayed.
2. In the navigation pane, choose Basic Configurations > Lifecycle Rules.
3. Click Create.
4. Configure a lifecycle rule.
   Basic Information:

   • Status: Select Enable to enable this lifecycle rule after the configuration.
   • Rule Name: It identifies a lifecycle rule. The rule name must be no longer than 255 characters.
   • Applies To: It can be set to Object name prefix or Bucket.
     • Object name prefix: Objects with this 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: \:*?"<>|
     • Bucket: 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 a lifecycle rule based on prefix, you cannot create any rule to apply to the entire bucket.
   • If there is a lifecycle rule applied to the entire bucket, you cannot create any rule based on prefix.

   Current Version or Historical Version:

   • If Versioning is disabled for a bucket, only Current Version can be configured.
   • If Versioning was ever enabled for a bucket, both Current Version and Historical Version can be configured.

     The Historical Version appears only when versioning is enabled or suspended for the bucket.

   

   • Current Version and Historical Version are two concepts related to 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 details, see Versioning.
   • You can configure either Current Version or Historical Version or both of them.
   • Transition to Warm After (Days): After a specified number of days have passed since the last update, objects meeting specified conditions will be transitioned to Warm. This number must be at least 30.
   • Transition to Cold After (Days): After a specified number of days have passed since the last update, objects meeting specified conditions will be transitioned to Cold. If you configure objects to transition first to Warm and then to Cold, make sure the objects stay in Warm at least 30 days before they are transitioned to Cold. There are, however, no such constraints on time if you configure objects to transition to only Cold.
   • 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 an integer larger than that specified for any of the transition operations.
   Assume you stored the following files in OBS on January 7, 2015:

   • log/test1.log
   • log/test2.log
   • doc/example.doc
   • doc/good.txt
   Then, you stored the following files in OBS on January 10, 2015:

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

   On January 10, 2015, you created a rule to delete the objects prefixed with log 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 upon the next system scan. The deletion could happen on January 10, 2015 or January 11, 2015, depending on the time of the system scan.
   • For objects log/clientlog.log and log/serverlog.log uploaded on January 10, 2015, each system scan would determine whether one full day had passed since their last update. If any scan determined one full day had passed, those objects would be deleted upon that scan. The deletion might happen on January 11, 2015 or January 12, 2015.

   Suppose you configured the objects with the log prefix to be transitioned to Warm 30 days and to Cold 60 days and to be deleted 100 days after their last update. OBS would perform those actions on log/clientlog.log, log/serverlog.log, log/test1.log, and log/test2.log as you defined.

   

   After an object is uploaded, OBS calculates its lifecycle from 00:00 UTC the next day. In theory, it takes 24 hours at most to execute a lifecycle rule. As a result, there may be a delay in transitioning objects or deleting expired objects, but it does not exceed 48 hours. If you make changes to an existing lifecycle rule, when the changed rule takes effect will be recalculated.

5. Click OK to complete the lifecycle rule configuration.

Precautions

• Minimum measurement object size

  Objects smaller than 64 KB are regarded as 64 KB in size.

• Minimum storage duration

  This means that the minimum storage duration will be used even if objects are not stored for that long. For example, if an object is transitioned to Cold after being stored in Warm for 20 days, its minimum storage duration is still 30 days (the minimum storage duration for Warm).

  Item	Standard	Warm	Cold
  Minimum storage duration	N/A	30 days	90 days

• Object restoration duration

  Object restoration is required for accessing Cold objects. The restoration will take some time. If your services require real-time data access, these two storage classes are not recommended.

  Table 1 Object restoration duration

  Restoration Mode	Duration of Restoration from Cold
  Standard	3 to 5 hours
  Expedited	1 to 5 minutes