El contenido no se encuentra disponible en el idioma seleccionado. Estamos trabajando continuamente para agregar más idiomas. Gracias por su apoyo.
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.
NOTE:
- 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.
Using OBS Console
- Log in to OBS Console. In the navigation pane, choose Object Storage.
- 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.
- Choose a new storage class and click OK.
Figure 1 Manually changing the storage class of a bucket
Using the CLI Tool - obsutil
Command Line Structure
- In Windows
obsutil stat obs://bucket [-acl] [-bf=xxx] [-config=xxx] [-e=xxx] [-i=xxx] [-k=xxx] [-t=xxx]
- In Linux or macOS
./obsutil stat obs://bucket [-acl] [-bf=xxx] [-config=xxx] [-e=xxx] [-i=xxx] [-k=xxx] [-t=xxx]
Examples
- Take the Windows OS as an example. Run the obsutil chattri obs://bucket-test -acl=private command to change the access control policy of the bucket to private read and write.
obsutil chattri obs://bucket-test -acl=private Start at 2024-09-29 07:58:46.0506904 +0000 UTC Set the acl of bucket [bucket-test] to [private] successfully, request id [04050000016836C5DA6FB21F14A2A0C0]
Parameter Description
|
Parameter |
Optional or Mandatory |
Description |
|---|---|---|
|
bucket |
Mandatory |
Bucket name |
|
acl |
No |
Queries the access control policies of the bucket. |
|
bf |
Optional (additional parameter) |
How the used bucket capacity is displayed, in raw bytes or human-readable format. Possible values are:
NOTE:
If this parameter is not configured, how the used bucket capacity is displayed is determined by the humanReadableFormat parameter in the configuration file. |
|
config |
Optional (additional parameter) |
User-defined configuration file for executing a command. For details about parameters that can be configured, see Parameter Description. |
|
e |
Optional (additional parameter) |
Specifies the endpoint. |
|
i |
Optional (additional parameter) |
Specifies the user's AK. |
|
k |
Optional (additional parameter) |
Specifies the user's SK. |
|
t |
Optional (additional parameter) |
Specifies the user's security token. |
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.
NOTE:
- 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.
- Even though objects that are in the Infrequent Access storage class do not need to be restored manually, you still need to pay for restoration requests and traffic.
- When changing the storage class of objects that are in the Archive or Deep Archive storage, you are charged for restoration requests, traffic, and temporary copy storage.
You can change the storage class of objects using OBS Console, APIs, OBS SDKs, OBS Browser+, or obsutil.
Using OBS Console
- Log in to OBS Console. In the navigation pane, choose Object Storage.
- In the bucket list, click the bucket name you want. The Objects page is displayed.
- Restore objects that are in the Archive or Deep Archive storage class if there are any. For details, see Restoring an Object from Archive or Deep Archive Storage.
- Change the storage class of objects individually or in a batch.
- Individually: In the object list, locate the desired object and choose More > Change Storage Class in the Operation column on the right.
Figure 2 Changing object storage classes individually
- In a batch: In the object list, select the desired objects and choose More > Change Storage Class above the object list.
NOTE:
Changing object storage classes in a batch is currently only available in some regions. If you cannot find the button for the batch operation, check whether this operation is supported in your region.
Figure 3 Changing object storage classes in a batch
- Individually: In the object list, locate the desired object and choose More > Change Storage Class in the Operation column on the right.
- Choose a new storage class and click OK.
Figure 4 Choosing a new storage class
Using the API
OBS provides two APIs for you to manually change the storage class of objects. You can call an API to:
NOTE:
If you want to change the storage class of Archive or Deep Archive objects, make sure you have restored them before you change their storage classes.
- Modify object metadata (adding the x-obs-storage-class header).
- Copy an object (adding the x-obs-storage-class header). If a bucket has versioning enabled, OBS automatically generates a unique version ID for a new object copy. If a bucket has versioning disabled or suspended, the existing object will be overwritten by a new object copy.
Using SDKs
NOTE:
If you want to change the storage class of objects that are in the Archive or Deep Archive storage, make sure you have restored them by calling an API before you change their storage class.
Using the CLI Tool - obsutil
obsutil allows you to change the storage class of an object by modifying its properties.
NOTE:
If you want to change the storage class of objects that are in the Archive or Deep Archive storage, make sure you have restored them before you change their storage classes. For commands for restoring objects, see Restoring Objects.
- In Windows
- Setting properties of a single object
obsutil chattri obs://bucket/key [-meta=aaa:bbb#ccc:ddd] [-sc=xxx] [-acl=xxx] [-aclXml=xxx] [-versionId=xxx] [-fr] [-o=xxx] [-config=xxx] [-e=xxx] [-i=xxx] [-k=xxx] [-t=xxx]
- Setting properties of objects in batches
obsutil chattri obs://bucket[/key] -r [-f] [-v] [-meta=aaa:bbb#ccc:ddd] [-sc=xxx] [-acl=xxx] [-aclXml=xxx] [-o=xxx] [-j=1] [-config=xxx] [-e=xxx] [-i=xxx] [-k=xxx] [-t=xxx]
- Setting properties of a single object
- In Linux or macOS
- Setting properties of a single object
./obsutil chattri obs://bucket/key [-meta=aaa:bbb#ccc:ddd] [-sc=xxx] [-acl=xxx] [-aclXml=xxx] [-versionId=xxx] [-fr] [-o=xxx] [-config=xxx] [-e=xxx] [-i=xxx] [-k=xxx] [-t=xxx]
- Setting properties of objects in batches
./obsutil chattri obs://bucket[/key] -r [-f] [-v] [-meta=aaa:bbb#ccc:ddd] [-sc=xxx] [-acl=xxx] [-aclXml=xxx] [-o=xxx] [-j=1] [-config=xxx] [-e=xxx] [-i=xxx] [-k=xxx] [-t=xxx]
- Setting properties of a single object
Examples
- Take the Windows OS as an example, run the obsutil chattri obs://bucket-test/key -acl=public-read command to set the access permission to an object to public read.
obsutil chattri obs://bucket-test/key -acl=public-read Start at 2024-09-30 08:17:15.5572914 +0000 UTC Set the acl of object [key] in the bucket [bucket-test] to [public-read] successfully, request id [04050000016836DDFA73B2B5320E2651]
- Take the Windows OS as an example, run the obsutil chattri obs://bucket-test -r -f -acl=public-read command to set the access permission to all objects in the bucket to public read.
obsutil chattri obs://bucket-test -r -f -acl=public-read Start at 2024-09-30 08:18:03.105373 +0000 UTC [------------------------------------------------] 100.00% tps:155.15 5/5 233ms Succeed count: 5 Failed count: 0 Metrics [max cost:177 ms, min cost:53 ms, average cost:102.40 ms, average tps:20.41] Task id: 9d7f73ff-f747-4fdd-9b2a-815ba2dc3b07
Parameter Description
|
Parameter |
Optional or Mandatory |
Description |
|---|---|---|
|
bucket |
Mandatory |
Bucket name |
|
key |
Mandatory when setting properties for a single object. Optional when setting properties for a batch of objects. |
The name of a single object whose properties are to be set, or the name prefix of a batch of objects whose properties are to be set. NOTE:
If this parameter is left blank for a batch operation, properties of all objects in a bucket are set. |
|
meta |
Optional (additional parameter) |
Standard or custom metadata specified for object copies in object replication. This parameter should be configured in the following format: key1:value1#key2:value2#key3:value3. NOTE:
|
|
direct |
Optional (additional parameter) |
Metadata operation indicator. The value can be REPLACE_NEW or REPLACE. REPLACE_NEW: The existing metadata value is replaced with a new one, the metadata lacking a value is assigned one, and the metadata not specified remains unchanged. REPLACE: The metadata is replaced with the header included in the current request and the metadata not specified is deleted. NOTE:
This parameter takes effect only when it is used together with meta. |
|
sc |
Optional (additional parameter) |
Storage class of an object. Possible values are:
NOTE:
For an object whose storage class is cold, restore the object first and then configure its storage class. |
|
acl |
Optional (additional parameter) |
Access control policies that can be specified for objects. Possible values are:
NOTE:
These four values indicate, respectively, private read and write, public read, public read and write, and bucket owner full control. |
|
aclXml |
Optional (additional parameter) |
Access control policy of the bucket, in XML format. <AccessControlPolicy>
<Owner>
<ID>ownerid</ID>
</Owner>
<AccessControlList>
<Grant>
<Grantee>
<ID>userid</ID>
</Grantee>
<Permission>[WRITE|WRITE_ACP|READ|READ_ACP|FULL_CONTROL]</Permission>
</Grant>
<Grant>
<Grantee>
<Canned>Everyone</Canned>
</Grantee>
<Permission>[WRITE|WRITE_ACP|READ|READ_ACP|FULL_CONTROL]</Permission>
</Grant>
</AccessControlList>
</AccessControlPolicy> NOTE:
NOTICE:
Because angle brackets (<) and (>) are unavoidably included in the parameter value, you must use quotation marks to enclose them for escaping when running the command. Use single quotation marks for Linux and macOS and double quotation marks for Windows. |
|
fs |
Optional (additional parameter) |
Specifies whether the method of listing parallel file systems is applied. If you are listing parallel file systems, you are recommended to add this parameter.
CAUTION:
|
|
versionId |
Optional when setting properties of a single object (additional parameter) |
Version ID of the object whose properties are to be set |
|
fr |
Optional when setting properties of a single object (additional parameter) |
Generates an operation result list when setting properties of a single object. |
|
f |
Optional when setting properties of objects in batches (additional parameter) |
Runs in force mode. |
|
r |
Mandatory when setting properties of objects in batches (additional parameter) |
Sets properties of objects in batches based on a specified object name prefix. |
|
v |
Optional when setting properties of objects in batches (additional parameter) |
Sets properties of versions of objects in batches based on a specified object name prefix. |
|
o |
Optional (additional parameter) |
Indicates the folder where operation result lists reside. After the command is executed, result lists (including success and failure files) are generated in the folder. The default value is .obsutil_output, the subfolder in the home directory of the user who executes obsutil commands. NOTE:
|
|
j |
Optional when setting properties of objects in batches (additional parameter) |
Indicates the maximum number of concurrent tasks for setting object properties in batches. The default value is the value of defaultJobs in the configuration file. NOTE:
The tool ensures that the value is at least 1. |
|
config |
Optional (additional parameter) |
User-defined configuration file for executing a command. For details about parameters that can be configured, see Parameter Description. |
|
e |
Optional (additional parameter) |
Specifies the endpoint. |
|
i |
Optional (additional parameter) |
Specifies the user's AK. |
|
k |
Optional (additional parameter) |
Specifies the user's SK. |
|
t |
Optional (additional parameter) |
Specifies the user's security token. |
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.
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.
NOTE:
- 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.
Using OBS Console
- In the navigation pane of OBS Console, choose Object Storage.
- In the bucket list, click the bucket you want to operate. The Objects page is displayed.
- In the navigation pane, choose Overview.
- 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.
- Click Create. A dialog box as shown in Figure 6 is displayed.
- 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.
- 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.
NOTE:
- If Object name prefix is selected and the specified prefix and the prefix in an existing lifecycle rule overlap, OBS regards the two rules as one and forbids you to configure the current rule. 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:
NOTE:
- 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. An object uploaded most recently is called Current Version, while an object uploaded previously is called Historical Version. For details, see Versioning.
- Either the Current Version or Historical Version must be configured, or you can configure both of them.
- Transition to Infrequent Access After (Days): After a specified number of days have passed 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 a specified number of days have passed since the last update, objects meeting specified conditions will be transitioned to Archive. If you configure objects to transition first to Infrequent Access and then to Archive, make sure the objects stay in Infrequent Access at least 30 days before they are transitioned to Archive. There are, however, no such constraints on time if you configure objects to transition to only Archive.
- Transition to Deep Archive After (Days): After a specified number of days have passed since the last update, objects meeting specified conditions will be transitioned to Deep Archive. If you configure objects to transition first to Infrequent Access and then to Deep Archive, make sure the objects stay in Infrequent Access at least 30 days before they are transitioned to Deep Archive. If you configure objects to transition first to Archive and then to Deep Archive, make sure the objects stay in Archive at least 90 days before they are transitioned to Deep Archive. There are, however, no such constraints on time if you configure objects to transition to only Deep Archive.
- Expiration Time: After a specified number of days have passed since the last update, objects meeting specified rules will be automatically expired and deleted. This number must be an integer larger than that specified for any of the transition operations.
- Delete Fragments After (Days): After a specified number of days have passed since the fragment generation, OBS will automatically delete fragments in the bucket.
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
If you created a rule to delete the objects prefixed with log one day after the last update on January 10, 2015, the following situations may occur:
- 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 Infrequent Access 30 days and to Archive 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.
NOTE:
After an object is uploaded, OBS calculates its lifecycle from 00:00 UTC the next day. It takes 24 hours at most to execute a lifecycle rule. As a result, 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, when the changed rule takes effect will be recalculated.
- Click OK to complete the lifecycle rule configuration.
Using the GUI Tool - OBS Browser+
- Log in to OBS Browser+.
- Select the bucket you want to configure a lifecycle rule and choose More > Lifecycle Rules.
Figure 7 Lifecycle Rules
- Click Create. The window shown in Figure 8 is displayed.
- Configure related parameters.
- Status: Select Enable to enable this lifecycle rule after the configuration.
- Rule Name: Enter a rule name that is no longer than 255 characters.
- Applies To: By selecting Object name prefix, the lifecycle rule will apply to objects with the specified prefix contained in their name. You can also select Bucket for the lifecycle rule to apply to all objects in the bucket.
NOTE:
- If Object name prefix is selected, and the specified prefix and the prefix in an existing lifecycle rule overlap, OBS regards the two rules as one and forbids you to configure the current rule. For example, if there is a rule with prefix abc in the system, another rule whose prefix contains abc cannot be configured.
- 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.
- If there is already a lifecycle rule whose Applies To is set to Bucket, you are not allowed to configure a new rule whose Applies To is set to Object name prefix.
- You can use a lifecycle rule to specify the number of days after the last update objects that meet specified criteria are automatically transitioned to the Infrequent Access or Archive storage class, or are automatically deleted.
- Transition to Infrequent Access: This rule transitions the objects meeting the conditions to the Infrequent Access storage class the specified number of days after the last update.
- Transition to Archive: This rule transitions the objects meeting the conditions to the Archive storage class the specified number of days after the last update.
- Expiration Time: This determines when an object will expire and then be deleted, or the day after which objects matching the rule will be deleted.
Assume you stored the following files in OBS on January 7, 2022:
- log/test1.log
- log/test2.log
- doc/example.doc
- doc/good.txt
On January 10, 2022, you stored the following files in OBS:
- log/clientlog.log
- log/serverlog.log
- doc/work.doc
- doc/travel.txt
Suppose you configured a rule on January 10, 2022 to expire and delete objects with the log/ prefix one day after their upload, objects log/test1.log, log/test2.log, log/clientlog.log, and log/serverlog.log would deleted on January 12, 2022.
If you configure lifecycle rules that transition objects with the log prefix to Infrequent Access 30 days and to Archive 60 days after the upload and delete them 100 days after the upload. OBS performs those actions on log/clientlog.log, log/serverlog.log, log/test1.log, and log/test2.log one day after the defined transition periods end.
- Click OK to save the lifecycle rule.
Precautions
- Minimum billable object 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.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot
