Help Center/ Object Storage Service/ User Guide/ Storage Class/ Changing the Storage Classes of Buckets and Objects
Updated on 2024-10-24 GMT+08:00

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 or object 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 Infrequent Access storage class. However, it cannot be moved to the Archive storage class, which does not support multi-AZ redundancy.

Manually Changing the Storage Class of a Bucket

OBS allows you to move a bucket to any storage class manually, but does not support using lifecycle rules to do that.

  • Changing the storage class of a bucket does not change the storage classes of existing objects in the bucket. The storage class of an object uploaded later will inherit the new storage class of the bucket by default. You can configure lifecycle rules to change storage classes of objects in batches.

    For example, suppose a bucket, bucket1, is in the Standard storage class and contains an object, object1, also in the Standard storage class. If bucket1's storage class is transitioned to Infrequent Access, then object1 will remain in the Standard storage class, but a new object, object2, uploaded after the change of the bucket storage class, will be in the Infrequent Access storage class.

  • After a bucket is changed from Archive or Deep Archive to Standard or Infrequent Access, existing Archive or Deep Archive objects in the bucket will not be automatically restored.

You can change the storage class of a bucket using OBS Console, APIs, OBS SDKs, or obsutil.

Manually Changing the Storage Class of an Object

OBS allows you to move an object to any storage class manually. For objects that are in the Archive or Deep Archive storage class, you must restore them first before changing their storage classes. OBS also supports automatic change of object storage classes. For details, see Changing the Storage Class of an Object Using Lifecycle Rules.

You can change the storage class of objects using OBS Console, APIs, OBS SDKs, OBS Browser+, or obsutil.

Changing the Storage Class of an Object Using Lifecycle Rules

For optimal storage costs, you can use lifecycle management to automatically change the storage classes of objects. Because multi-AZ redundancy is not supported for Archive and Deep Archive, you cannot use lifecycle rules to change the storage class of multi-AZ objects to Archive or Deep Archive. For more information, see Transitioning Object Storage Classes Through Lifecycle Rules.

If versioning is disabled, the lifecycle of an object starts when it is uploaded. If versioning is enabled, the lifecycle of a new object starts when it is uploaded. The lifecycle for historical objects starts when they become historical.

Figure 5 Changing the storage class of an object using lifecycle rules

As shown in the figure, OBS allows you to use lifecycle rules to change the storage class of objects:

  • From Standard to Deep Archive storage, Archive, or Infrequent Access.
  • From Infrequent Access to Archive or Deep Archive.
  • From Archive to Deep Archive.
    • When changing the storage class of objects that are in the Infrequent Access, Deep Archive, or Archive storage, there may be additional charges for the minimum storage duration.

You can use OBS Console, APIs, SDKs, or OBS Browser+ to configure storage classes for buckets at bucket creation.

Precautions

  • Minimum billable object size

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

  • Minimum storage duration

    The minimum storage duration refers to the least time that is eligible for billing. This means that objects will be billed for the minimum storage duration even if they are not stored for that long. For example, if an object is transitioned to Archive after being stored in Infrequent Access for 20 days, it will be billed for the storage of 30 days (the minimum storage duration for Infrequent Access).

    Item

    Standard

    Infrequent Access

    Archive

    Deep Archive (in OBT)

    Minimum storage duration

    N/A

    30 days

    90 days

    180 days

  • Object restoration duration

    Object restoration is required for accessing Archive and Deep Archive 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 Speed

    Duration of Restoration from Archive

    Duration of Restoration from Deep Archive

    Standard

    3–5 h

    5–12 h

    Expedited

    1–5 min

    3–5 h

  • Data restoration charges
    Table 2 Data restoration charges

    Operation

    Billing Item

    Description

    Infrequent Access objects

    Requests

    You are billed for the number of successfully restored objects.

    If N objects were successfully restored, you are billed for N requests.

    Data transfer

    You are billed for the bandwidth you consumed during data retrievals.

    Archive or Deep Archive objects

    Requests

    You are billed for the number of successfully restored objects.

    If N objects were successfully restored, you are billed for N requests.

    Data transfer

    You are billed for the bandwidth you consumed during data retrievals.

    Temporary file storage

    When an Archive or a Deep Archive object is restored, a copy in the Standard storage class will be generated for the object. That means the object and its Standard copy will co-exist in the bucket. During the validity period of a restoration, you will be billed for the space taken up by both the object and its copy. The copy will be automatically deleted once the validity period ends.