Help Center/ Cloud Container Engine/ User Guide/ Cluster Backup/ Intra-Cluster Application Backup and Restoration
Updated on 2026-06-18 GMT+08:00
View PDF
Share

Intra-Cluster Application Backup and Restoration

Cluster Backup enables backup and restoration of applications within a Kubernetes cluster, providing disaster recovery capabilities. It offers integrated protection for both resource objects (such as Deployments, Services, and ConfigMaps) and persistent volume data (PVs and PVCs). You can perform automated backups and rapid restoration for entire namespaces or specific applications, mitigating risks from human error, application faults, or data corruption.

Prerequisites

  • Velero is installed in the cluster.
  • Velero uses OBS buckets as backend storage. Before using Cluster Backup, ensure an OBS bucket is available.

Precautions

  • During backup or restoration, ensure the cluster is running stably. Do not add, delete, or modify resources, as this may cause the operation to fail or produce incomplete results.
  • If the cluster has recently changed, wait 15 minutes for it to stabilize before performing a backup.
  • PV backup creates EVS snapshots only, which are subject to snapshot constraints. For details, see Creating an EVS Snapshot.
  • When PV backup is used, ensure a single backup job does not include more than 10,000 EVS PVCs/PVs in the selected namespace. Exceeding this limit may cause snapshot creation to fail.
  • Backups capture only current data. Restoration automatically skips existing resources.
  • If a restored PV is not bound to any PVC, deleting the PV will not delete the underlying EVS disk. You must delete the disk manually from the EVS console.

Billing

  • Backup repositories require an OBS bucket, which generates OBS fees. For details, see OBS Billing Overview.
  • PV backup automatically creates EVS snapshots, which incur snapshot fees. For details, see Billing for EVS Snapshots.

Creating a Backup Repository

A backup repository stores application backups for one or more clusters. If no repository exists when you create a backup, create one by following the steps below.

  1. Log in to the CCE console and click the cluster name to access the cluster console.
  2. In the navigation pane, choose Cluster Backup. On the displayed page, click the Backup Repositories tab and click Create Backup Repository.
  3. Configure the backup repository.

    Table 1 Backup repository parameters

    Parameter

    Mandatory

    Description

    Backup Repository Name

    Yes

    The name of the backup repository.

    Bucket Region

    Yes

    Region where the OBS bucket is located. Resources are region-specific. They can be connected through an internal network within the same region. For lower latency and faster access, select the region closest to where your bucket will be accessed.

    Bucket Name

    Yes

    Select an OBS bucket for storing backups.

    Subpath

    No

    Path within the bucket for storing backups. By default, backups are stored in the bucket root. Only backup and restore files or folders can be placed in this path. Other items may cause task failures or overwrite existing data.

    Access Mode

    Yes
    • Read/Write: You can use the backup repository to back up clusters or restore clusters from existing backups.
    • Read-only: You can restore clusters from existing backups in the repository, but you cannot perform new backups to it.

  4. Click OK.

Creating a Backup Plan or Performing an Immediate Backup

You can create a scheduled backup plan or perform an immediate backup. Task status is recorded on the Backup Records tab.

Once created, the backup plan executes periodically according to your configured schedule, for example, at a specified interval or at a specific time daily, weekly, or monthly.

  1. Log in to the CCE console and click the cluster name to access the cluster console.
  2. In the navigation pane, choose Cluster Backup and click Create Backup Plan.
  3. Configure backup plan parameters.

    Table 2 Backup plan parameters

    Parameter

    Mandatory

    Description

    Backup Plan Name

    Yes

    The name of the backup plan. A maximum of 48 characters is allowed. Exceeding this limit causes plan execution to fail.

    Backup Repository

    Yes

    The repository used for cluster backup storage.

    Namespace to Back Up

    No

    All namespaces are backed up by default. Choose a namespace from the drop-down list or enter one manually. Wildcards such as app-* are supported. Enter an asterisk (*) only to include all namespaces.

    Excluded Namespaces

    No

    You can add namespaces using either of the following methods:

    • Choose one or more existing namespaces from the drop-down list.
    • Enter a namespace name manually. Wildcards are supported for pattern matching:
      • app-* matches all namespaces starting with app-, ns? matches namespaces with exactly 3 characters, and test[a-c] matches testa, testb, and testc.
      • The following wildcards are allowed: * (any number of characters), ? (a single character), [abc] (any one character in the brackets), and [a-z] (any character within the specified range).
      • Do not use {} () | !, consecutive asterisks (**), or empty square brackets ([]).
      • Do not use a single asterisk (*) alone, as excluding all namespaces is not permitted.
    CAUTION:

    Backing up or restoring applications in system namespaces (kube-system, kube-public, and kube-node-lease) may cause cluster workload exceptions. Exercise caution when including these namespaces.

    PV Backup

    No

    PV backup is enabled by default. When enabled, snapshots are automatically created for EVS-backed PVs in the source namespace during cluster backup.

    CAUTION:

    A maximum of 256 snapshots can be created for a single EVS disk. Ensure that the snapshot count for each EVS disk remains below this limit and that your tenant snapshot quota is sufficient. Exceeding either limit causes PV backup to fail.

    Backup Interval

    Yes

    Specifies when a backup job executes. The following modes are supported:

    • The CronJob executes at a fixed interval. The unit can be minute, hour, day, or month. For example, a CronJob executed every 30 minutes uses the expression */30 * * * *. The job runs at 30-minute intervals starting from the top of the hour, for example, 00:00:00, 00:30:00, 01:00:00, and ....
    • The CronJob executes at a fixed time on a specified day each month. For example, a CronJob executed at 00:00 on the first day of each month uses the expression 0 0 1 */1 *. The job runs at ****-01-01 00:00:00, ****-02-01 00:00:00, and ....
    • The CronJob executes at a fixed time on a specified day each week. For example, a CronJob executed at 00:00 every Monday uses the expression 0 0 * * 1. The job runs at ****-**-01 00:00:00 on Monday, ****-**-08 00:00:00 on Monday, and ....
    • Custom cron expression: For details about how to use cron expressions, see How Do I Customize a Cron Expression When Creating a Backup Plan?.
    NOTE:
    • If a CronJob is scheduled for a fixed date each month and that date does not exist in a given month, the CronJob skips that month. For example, a CronJob set to run on the 30th will not execute in February.
    • Due to cron's definition, fixed periods are not strictly periodic. Cron intervals are calculated from zero within each time unit range. For minutes, the range is 0 to 59. If the range cannot be evenly divided by the interval, the final period is truncated at the boundary. Consequently, an accurate period is achievable only when the interval divides the range exactly.

      Example: For an hourly CronJob, intervals that divide 24 exactly, such as /2, /3, /4, /6, /8, and /12, produce consistent periods. Other intervals cause the final period to be truncated at the day boundary. The expression * */12 * * * runs the job at 00:00:00 and 12:00:00 daily, while * */13 * * * runs it at 00:00:00 and 13:00:00 daily. In the latter case, the final period is truncated at 00:00:00 the following day, even though 13 hours have not elapsed.

    Advanced Settings (Optional)

    Label-Based Backup

    No

    Resources are backed up based on Kubernetes labels.

    Included Resources (Optional)

    No

    When this parameter is specified, only the selected resource types, for example, Deployments and ConfigMaps are backed up.

    Resource names support the following matching modes:

    • By resource name only: For example, deployments matches all Deployment resources across all API groups.
    • By resource name and exact API group: For example, deployments.apps matches only Deployment resources in the apps API group.
    • By API group wildcard: For example, *.apps matches all Kubernetes resources in the apps API group.

    Resource name matching rules:

    • Multiple resource names can be specified concurrently, or the wildcard (*) can be used.
    • If you enter only a wildcard (*), all resources are included. No additional items can be added in this case.
    NOTE:

    Only the format of manually entered content is validated. During backup or restoration, only resource names that actually exist in the cluster are processed.

    Excluded Resources (Optional)

    No

    After filtering resources by label, you can exclude specific resource types, for example, pods and secrets.

    Resource names support the following matching modes:

    • By resource name only: For example, deployments matches all Deployment resources across all API groups.
    • By resource name and exact API group: For example, deployments.apps matches only Deployment resources in the apps API group.
    • By API group wildcard: For example, *.apps matches all Kubernetes resources in the apps API group.

    Resource name matching rules:

    • Multiple resource names can be specified concurrently, or the wildcard (*) can be used.
    • An asterisk (*) alone is not allowed.
    NOTE:
    • Only the format of manually entered content is validated. During backup or restoration, only resource names that actually exist in the cluster are processed.
    • By default, VolumeSnapshot and VolumeSnapshotContent resources are excluded from backup. These are temporary objects created dynamically by the CSI driver when Velero backs up PVCs. They trigger the underlying storage system to perform actual snapshot operations. They form part of Velero's internal implementation rather than user-deployed application resources. Therefore, Velero does not back them up by default.

    Retention Period

    No

    Expired backups are automatically deleted every hour. This action is permanent and cannot be undone.

    The default backup retention period is 30 days.

  4. Click OK.

The backup process starts immediately and runs to completion. This mode is commonly used for cloning and migration. Before performing an immediate backup, ensure a backup repository is available.

  1. Log in to the CCE console and click the cluster name to access the cluster console.
  2. In the navigation pane, choose Backup Center and click Back Up.
  3. Configure backup parameters.

    Table 3 Immediate backup parameters

    Parameter

    Mandatory

    Description

    Name

    Yes

    The name of the backup.

    Backup Repository

    Yes

    The repository used for cluster backup storage.

    Namespace to Back Up

    No

    All namespaces are backed up by default. Choose a namespace from the drop-down list or enter one manually. Wildcards such as app-* are supported. Enter an asterisk (*) only to include all namespaces.

    Excluded Namespaces

    No

    You can add namespaces using either of the following methods:

    • Choose one or more existing namespaces from the drop-down list.
    • Enter a namespace name manually. Wildcards are supported for pattern matching:
      • app-* matches all namespaces starting with app-, ns? matches namespaces with exactly 3 characters, and test[a-c] matches testa, testb, and testc.
      • The following wildcards are allowed: * (any number of characters), ? (a single character), [abc] (any one character in the brackets), and [a-z] (any character within the specified range).
      • Do not use {} () | !, consecutive asterisks (**), or empty square brackets ([]).
      • Do not use a single asterisk (*) alone, as excluding all namespaces is not permitted.
    CAUTION:

    Backing up or restoring applications in system namespaces (kube-system, kube-public, and kube-node-lease) may cause cluster workload exceptions. Exercise caution when including these namespaces.

    PV Backup

    No

    When enabled, snapshots are automatically created for EVS-backed PVs in the source namespace during cluster backup.

    CAUTION:

    A maximum of 256 snapshots can be created for a single EVS disk. Ensure that the snapshot count for each EVS disk remains below this limit and that your tenant snapshot quota is sufficient. Exceeding either limit causes PV backup to fail.

    Advanced Settings (Optional)

    Label-Based Backup

    No

    Resources are backed up based on Kubernetes labels.

    Included Resources (Optional)

    No

    When this parameter is specified, only the selected resource types, for example, Deployments and ConfigMaps are backed up.

    Resource names support the following matching modes:

    • By resource name only: For example, deployments matches all Deployment resources across all API groups.
    • By resource name and exact API group: For example, deployments.apps matches only Deployment resources in the apps API group.
    • By API group wildcard: For example, *.apps matches all Kubernetes resources in the apps API group.

    Resource name matching rules:

    • Multiple resource names can be specified concurrently, or the wildcard (*) can be used.
    • If you enter only a wildcard (*), all resources are included. No additional items can be added in this case.
    NOTE:

    Only the format of manually entered content is validated. During backup or restoration, only resource names that actually exist in the cluster are processed.

    Excluded Resources (Optional)

    No

    After filtering resources by label, you can exclude specific resource types, for example, pods and secrets.

    Resource names support the following matching modes:

    • By resource name only: For example, deployments matches all Deployment resources across all API groups.
    • By resource name and exact API group: For example, deployments.apps matches only Deployment resources in the apps API group.
    • By API group wildcard: For example, *.apps matches all Kubernetes resources in the apps API group.

    Resource name matching rules:

    • Multiple resource names can be specified concurrently, or the wildcard (*) can be used.
    • An asterisk (*) alone is not allowed.
    NOTE:
    • Only the format of manually entered content is validated. During backup or restoration, only resource names that actually exist in the cluster are processed.
    • By default, VolumeSnapshot and VolumeSnapshotContent resources are excluded from backup. These are temporary objects created dynamically by the CSI driver when Velero backs up PVCs. They trigger the underlying storage system to perform actual snapshot operations. They form part of Velero's internal implementation rather than user-deployed application resources. Therefore, Velero does not back them up by default.

    Retention Period

    No

    Expired backups are automatically deleted every hour. This action is permanent and cannot be undone.

  4. Click OK.

Performing an Immediate Restoration

  1. Log in to the CCE console and click the cluster name to access the cluster console.
  2. In the navigation pane, choose Backup Center and click Restore.
  3. Configure restoration parameters.

    Table 4 Immediate restoration parameters

    Parameter

    Mandatory

    Description

    Restoration Name

    Yes

    The name of the restoration.

    Backup Repository

    Yes

    Select a repository for storing backups.

    Backup Record

    Yes

    Select a backup record.

    Namespace to Restore

    No

    By default, all namespaces in the backup record are restored. You can choose a namespace from the drop-down list or manually enter one (wildcards such as app-* are supported). If all namespaces were backed up, only All namespaces will be available in the drop-down list. You can also manually enter specific namespaces.

    Namespace Remapping

    No

    Change the target namespace during restoration to recover resources from namespace A into namespace B.

Helpful Links

If you encounter any errors or issues, refer to the documentation first. For details, see Cluster Backup FAQs.

Parent Topic: Cluster Backup