diff --git a/docs/cbr/umn/cbr_02_0009.html b/docs/cbr/umn/cbr_02_0009.html index 3505de2e7..56e526a8c 100644 --- a/docs/cbr/umn/cbr_02_0009.html +++ b/docs/cbr/umn/cbr_02_0009.html @@ -34,7 +34,7 @@

  • On a backup page, locate the target vault and click Associate Server, Associate File System, or Associate Disk.
  • In the resource list, select the resources you want to associate with the vault. After resources are selected, they are added to the list of selected resources. See Figure 1.

    Figure 1 Associate Server

    -

    +

    diff --git a/docs/cbr/umn/cbr_03_0002.html b/docs/cbr/umn/cbr_03_0002.html index 03229a828..43e09b697 100644 --- a/docs/cbr/umn/cbr_03_0002.html +++ b/docs/cbr/umn/cbr_03_0002.html @@ -79,7 +79,7 @@

    An intermediate state

    An intermediate state displayed when a capacity expansion is in progress.

    -

    If a vault is in this state, you can perform operations, such as applying a policy and associating servers or disks. However, the following operations are not allowed on such a vault: expanding the vault capacity and changing the vault specifications. Once those operations are complete, the vault status will become Available.

    +

    If a vault is in this state, you can perform operations, such as applying a policy and associating servers, file systems, or disks. However, the following operations are not allowed on such a vault: expanding the vault capacity and changing the vault specifications. Once those operations are complete, the vault status will become Available.

    Deleting

    diff --git a/docs/cbr/umn/cbr_03_0016.html b/docs/cbr/umn/cbr_03_0016.html index c9448fc4a..9c5823be3 100644 --- a/docs/cbr/umn/cbr_03_0016.html +++ b/docs/cbr/umn/cbr_03_0016.html @@ -5,7 +5,7 @@

    Prerequisites

    +
  • The backup contains the system disk data.
  • Only ECS backups can be used to create images.

    • Notes

    @@ -13,7 +13,7 @@

  • Click the Backups tab. Locate the desired backup. For details, see Viewing a Backup.
  • In the row of the backup, choose More > Create Image. See Figure 1.

    Figure 1 Creating an image

    -

  • Create an image by referring to section "Creating a Full-ECS Image Using a Cloud Server Backup" in the Image Management Service User Guide.
  • Use the image to provision ECSs when needed. For details, see section "Creating an ECS from an Image" in the Image Management Service User Guide.
    • +

  • Create an image by referring to section "Creating a Full-ECS Image Using a Cloud Server Backup" in the Image Management Service User Guide.
  • Use the image to provision ECSs when needed. For details, see section "Creating an ECS from an Image" in the Image Management Service User Guide.
    • diff --git a/docs/cbr/umn/cbr_03_0025.html b/docs/cbr/umn/cbr_03_0025.html index 9fbae08b1..b85a282f8 100644 --- a/docs/cbr/umn/cbr_03_0025.html +++ b/docs/cbr/umn/cbr_03_0025.html @@ -3,7 +3,7 @@

    Creating a Backup Policy

    A backup policy allows CBR to automatically back up vaults at specified times or intervals. Periodic backups can be used to restore data quickly against data corruption or loss.

    To implement periodic backups, you need a backup policy first. You can use the default backup policy or create one as needed.

    -

    Constraints

    • Backup policies can be applied to the following types of vaults: server backup vaults, disk backup vaults
    • A backup policy must be enabled before it can be used for periodic backups.
    • A maximum of 32 backup policies can be created in each account.
    • When expired backups are deleted, automatic backups will be deleted, but manual backups will not.
    • Only servers in the Running or Stopped state and disks in the Available or In-use state can be backed up.
    +

    Constraints

    • Backup policies can be applied to the following types of vaults: server backup vaults, disk backup vaults
    • A backup policy must be enabled before it can be used for periodic backups.
    • A maximum of 32 backup policies can be created in each account.
    • When expired backups are deleted, automatic backups will be deleted, but manual backups will not.
    • Only servers in the Running or Stopped state and disks in the Available or In-use state can be backed up.

    Procedure

    1. Log in to CBR Console.

      1. Log in to the management console.
      2. Click in the upper left corner and select a region.
      3. Click and choose Storage > Cloud Backup and Recovery.

    2. Choose Policies in the left navigation pane and click the Backup Policies tab. In the upper right corner, click Create Policy. See Figure 1.

      Figure 1 Creating a backup policy
      @@ -53,14 +53,14 @@

    00:00, 02:00

    - +

    Backup Cycle

    Select a backup frequency.

    Every day

    diff --git a/docs/cbr/umn/cbr_03_0027.html b/docs/cbr/umn/cbr_03_0027.html index e820f933c..a805d97ea 100644 --- a/docs/cbr/umn/cbr_03_0027.html +++ b/docs/cbr/umn/cbr_03_0027.html @@ -6,6 +6,7 @@

    Procedure

    1. Log in to CBR Console.

      1. Log in to the management console.
      2. Click in the upper left corner and select a region.
      3. Click and choose Storage > Cloud Backup and Recovery. Select a backup type from the left navigation pane.

    2. Find the target vault and click the vault name to view its details.
    3. In the Policies area, click Edit in the row of the policy to be edited. See Figure 1.

      Figure 1 Editing a backup policy
      +

      diff --git a/docs/cbr/umn/cbr_03_0116.html b/docs/cbr/umn/cbr_03_0116.html index 1aaa0a8e6..2506cc658 100644 --- a/docs/cbr/umn/cbr_03_0116.html +++ b/docs/cbr/umn/cbr_03_0116.html @@ -9,7 +9,7 @@

      Figure 1 Migrating a resource

      -

    4. Select the destination vault and click Yes.
    5. View the migration progress on the Tasks page. If Status changes to Successful, the resource has been migrated.
    6. Go to the destination vault to confirm that the resource has been associated and all its backups have been migrated.
    +

  • Select the destination vault and click OK.
  • View the migration progress on the Tasks page. If Status changes to Successful, the resource has been migrated.
  • Go to the destination vault to confirm that the resource has been associated and all its backups have been migrated.
    • diff --git a/docs/cbr/umn/cbr_06_0026.html b/docs/cbr/umn/cbr_06_0026.html index 12f053d59..d0cb23e49 100644 --- a/docs/cbr/umn/cbr_06_0026.html +++ b/docs/cbr/umn/cbr_06_0026.html @@ -4,7 +4,7 @@

    Symptoms

    • There is no difference or an increase in size between the original backup and a backup generated after a file is deleted.
    • The ECS backup size is larger than the used disk space obtained from the file system.

    Possible Causes

    Possible causes are as follows:

    -
    • The backup mechanism itself causes this problem. The cloud server backups, cloud disk backups, and SFS Turbo backups created using CBR are all block-level backups. Different from file-level backups, block-level backups are performed by sector (512 bytes) each time.
    • The metadata of the file systems on the disk occupies disk space.
    • To reduce performance overhead, the file system adds a delete marker for the deleted file, but does not erase the data that has been written to the sector, and the metadata on the sector still exists. Block-level backups cannot detect whether data on a sector is deleted or not, but only determine whether a backup needs to be performed by checking whether all data blocks are zero blocks.
    • CBR determines whether data in each sector changes by comparing two snapshots. Data changes include data addition, modification, and deletion. Backup is not performed if there are no data changes. If there are data changes, CBR further checks whether data blocks in the sector are all zero blocks. If so, backup is also not performed. Backups are performed only when there are non-zero blocks. If the data is deleted but metadata in the sector is not, the data block is also recognized as a non-zero block, and backups will be performed.
    +
    • The backup mechanism itself causes this problem. The cloud server backups, SFS Turbo backups, and cloud disk backups created using CBR are all block-level backups. Different from file-level backups, block-level backups are performed by sector (512 bytes) each time.
    • The metadata of the file systems on the disk occupies disk space.
    • To reduce performance overhead, the file system adds a delete marker for the deleted file, but does not erase the data that has been written to the sector, and the metadata on the sector still exists. Block-level backups cannot detect whether data on a sector is deleted or not, but only determine whether a backup needs to be performed by checking whether all data blocks are zero blocks.
    • CBR determines whether data in each sector changes by comparing two snapshots. Data changes include data addition, modification, and deletion. Backup is not performed if there are no data changes. If there are data changes, CBR further checks whether data blocks in the sector are all zero blocks. If so, backup is also not performed. Backups are performed only when there are non-zero blocks. If the data is deleted but metadata in the sector is not, the data block is also recognized as a non-zero block, and backups will be performed.
    diff --git a/docs/cbr/umn/en-us_image_0000001628917242.png b/docs/cbr/umn/en-us_image_0000001628917242.png index 7e7e563c4..dd753a41c 100644 Binary files a/docs/cbr/umn/en-us_image_0000001628917242.png and b/docs/cbr/umn/en-us_image_0000001628917242.png differ