All Products
Search

This Product

    Object Storage Service:Change the storage redundancy type of a bucket

    Document Center

    Object Storage Service:Change the storage redundancy type of a bucket

    Last Updated:Jan 29, 2024

    Locally redundant storage (LRS) provides data redundancy within only one zone and may fail to meet your increasing data durability and availability requirements. To protect your business applications from zone-level failures, you can change the storage redundancy type of your buckets from LRS to zone-redundant storage (ZRS). This topic describes how to change the storage redundancy type of a bucket from LRS to ZRS.

    Prerequisites

    • Storage redundancy type changing is supported in the region where your bucket is located. This feature is supported in the following regions: China (Hangzhou), China (Shanghai), China (Beijing), China (Zhangjiakou), China (Ulanqab), China (Shenzhen), China (Hong Kong), Japan (Tokyo), Singapore, Indonesia (Jakarta), and Germany (Frankfurt).

    • The existing storage redundancy type of the bucket is LRS. Object Storage Service (OSS) supports a storage redundancy type change only from LRS to ZRS.

    • The storage class of the bucket must be Standard, IA, or Archive. However, the storage class of objects in the bucket can be Cold Archive or Deep Cold Archive. Cold Archive and Deep Cold Archive objects are still stored as LRS objects after the change. You cannot change the storage redundancy type of a Cold Archive or Deep Cold Archive bucket.

    • The following permissions are granted to you if you want to change the storage redundancy type as a RAM user: oss:CreateBucketDataRedundancyTransition, oss:GetBucketDataRedundancyTransition, oss:ListBucketDataRedundancyTransition, and oss:DeleteBucketDataRedundancyTransition. For more information, see Attach a custom policy to a RAM user.

    Usage notes

    • Direction of change: You can change the storage redundancy type only from LRS to ZRS. You cannot change the storage redundancy type from ZRS to LRS.

    • Change methods: You can change the storage redundancy type only by using the OSS console and OSS API. You cannot use OSS SDKs or ossutil to change the storage redundancy type.

    • Time required for the change: The time required to change the storage redundancy type of a bucket varies with factors such as the data size, number of objects, and number of parts in the bucket. If a bucket contains a large number of parts, we recommend that you configure a lifecycle rule to delete parts before you change the storage redundancy type. Otherwise, the time required for the change may increase significantly. For more information about how to delete parts, see Overview.

    • Fees incurred: You are not charged for changing the storage redundancy type. However, you are charged storage fees based on ZRS instead of LRS after the storage redundancy type is changed. The unit price of ZRS is higher than that of LRS. For more information, visit the OSS pricing page.

    • Cross-region replication (CRR): If you change the storage redundancy type of a bucket for which a CRR rule is configured, the storage redundancy type of the other bucket in the CRR rule is not automatically changed. If you want to change the storage redundancy type of the other bucket, you need to do so manually.

    • OSS-HDFS: If you change the storage redundancy type from LRS to ZRS for a bucket that has OSS-HDFS enabled, LRS is still used to protect data in OSS-HDFS.

    Procedure

    Use the OSS console

    To change the storage redundancy type of a bucket from LRS to ZRS, perform the following steps:

    1. Log on to the OSS console.

    2. In the left-side navigation pane, click Buckets. On the Buckets page, find and click the desired bucket.

    3. In the left-side navigation tree, click Overview.

    4. In the Overview section of the Basic Information page, click Convert to ZRS next to the Redundancy Type field.

    5. In the Convert Redundancy Type from LRS to ZRS panel, check the estimated time required to complete the change and click Confirm.

    6. In the Confirm message, click OK.

      The following table describes the possible states of a storage redundancy type change task.

      Task status

      Description

      Queuing

      The task is in queue.

      • You can cancel a task in the Queuing state.

      • The Queuing state generally lasts for 2 to 3 hours. In unusual cases, the queuing time may be extended.

      Processing

      The task is being processed.

      • You cannot cancel a task in the Processing state.

      • You cannot delete a bucket whose task is in the Processing state.

      • The estimated time required to complete the task is for reference only.

      Finished

      The task is finished.

      • You can delete a task in the Finished state.

      • By default, a task in the Finished state is retained for three months and will be automatically deleted after three months. This task retention rule does not apply to tasks that are not in the Finished state.

      • If you delete a bucket whose storage redundancy type has been changed, you cannot create a same-name bucket within at least seven days after the deletion.

    Use the OSS API

    If your business requires a high level of customization, you can directly call RESTful APIs. To directly call an API, you must include the signature calculation in your code. For more information, see CreateBucketDataRedundancyTransition.

    References