Backup Management
You can back up Kubernetes resources within a cluster. This document details how to create backup tasks and set up scheduled backup policies for a target cluster.
Prerequisites
- The CCE Backup Controller backup component has been successfully installed in the target cluster. For details, see CCE Backup Controller Description.
Operation steps
Create a scheduled backup policy
A scheduled backup policy will automatically create backup tasks at intervals defined by the scheduling rules until the policy is removed. The task creation time is based on the specified scheduling rules, whether they are periodic or set for certain times daily, weekly, monthly, etc.
- Sign in to Cloud Container Engine Console (CCE).
- On the cluster list page, click the name of the target cluster. Then, in the left navigation bar, select Operations and Management - Application Backup - Backup Management.
- After enabling, click Create Scheduled Backup Policy on the scheduled backup policy page, and complete the relevant configurations on the creation page.
| ConfigMap | Required/Optional | Configuration |
|---|---|---|
| Task name | Required | Create a custom name for the scheduled backup task. |
| Backup repository | Required | Choose the backup repository linked to the backup task to store the backup data. |
| Scheduling rule | Required | Specify the scheduling rule for automatically creating backup tasks. Crontab expressions are supported, in the format of minute, hour, day, month and week. For details, see How to Use Crontab. |
| Backup scope | Required | All namespaces: Back up resources in all namespaces of the cluster. Among them, kube-system, kube-publish, kube-node-lease and cce-back have strong dependencies, and it is not recommended to directly perform backup and recovery. Therefore, backing up these four namespaces is not supported. Specified namespaces: Back up resources in one or more specified namespaces |
| Backup namespace | Required | Required only when the "Backup Scope" is set to Specified Namespaces. You can select one or more backup namespaces. You can select one or more namespaces to back up their resources. |
| Backup validity period | Required | The validity period for storing backup data. Once expired, the data will be deleted and cannot be recovered. The range is 1–65,536 days. |
| Exclude namespace | Optional | Required only when the "Backup Scope" is set to All Namespaces, used to filter out namespaces that do not need to be backed up. |
| Specified backup objects | Optional | Back up only specific Kubernetes resource objects. Selecting "All Resource Objects" will back up all resources within the namespace. |
| Exclude backup objects | Optional | Required only when "Specified Backup Objects" is set to All Resource Objects, used to filter out resource objects that do not need to be backed up. |
| Specify label backup | Optional | Filter resource objects further by specified labels, and only back up resources that match the label in the target namespace. |
- Click OK to complete creation.
Create backup tasks
An immediate backup will create a single backup task right away at the current time.
- Sign in to Cloud Container Engine Console (CCE).
- On the cluster list page, click the name of the target cluster. Then, in the left navigation bar, select Operations and Management - Application Backup - Backup Management.
- Click Create Backup Task on the backup task page and complete the relevant configurations.
| ConfigMap | Required/Optional | Configuration |
|---|---|---|
| Task name | Required | Customize the name of the backup task. |
| Backup repository | Required | Choose the backup repository linked to the backup task to store the backup data. |
| Backup scope | Required | All namespaces: Back up resources in all namespaces of the cluster. Among them, kube-system, kube-publish, kube-node-lease and cce-back have strong dependencies, and it is not recommended to directly perform backup and recovery. Therefore, backing up these four namespaces is not supported. Specified namespaces: Back up resources in one or more specified namespaces. |
| Backup namespace | Required | Required only when the "Backup Scope" is set to Specified Namespaces. You can select one or more backup namespaces. You can select one or more namespaces to back up their resources. |
| Backup validity period | Required | The validity period for storing backup data. Once expired, the data will be deleted and cannot be recovered. The range is 1–65,536 days. |
| Exclude namespace | Optional | Required only when the "Backup Scope" is set to All Namespaces, used to filter out namespaces that do not need to be backed up. |
| Specified backup objects | Optional | Back up only specific Kubernetes resource objects. Selecting "All Resource Objects" will back up all resources within the namespace. |
| Exclude backup objects | Optional | Required only when "Specified Backup Objects" is set to All Resource Objects, used to filter out resource objects that do not need to be backed up. |
| Specify label backup | Optional | Filter resource objects further by specified labels, and only back up resources that match the label in the target namespace. |
- Click OK to complete creation.
View backup information
Both scheduled backup policies and immediate backups will issue backup tasks in the cluster. You can view the Backup Task List and Scheduled Backup Policy List on the Backup Management page.
View backup status
You can check the backup status through the Status attribute in the Backup Task List. The status descriptions are as follows:
| Status | Description |
|---|---|
| Initializing | Create backup task resource objects |
| Execution in progress | The backup task is currently being executed. |
| Succeeded | The backup task has been successfully executed. |
| Partially succeeded | Some resource objects were backed up successfully, while others failed. You can check the number of successful items and the reasons for failure through the status field in the YAML on the console. |
| Failed | The backup task failed to execute. You can find the failure reason on the console or in the status field within the YAML. |
