diff --git a/en/backup-to-azblob-using-br.md b/en/backup-to-azblob-using-br.md index 49a7cf8f7..2ce3106bf 100644 --- a/en/backup-to-azblob-using-br.md +++ b/en/backup-to-azblob-using-br.md @@ -139,6 +139,24 @@ demo1-full-backup-azblob full snapshot Complete azure://my-container/my- You can use a `Backup` CR to describe the start and stop of a log backup task and manage the log backup data. In this section, the example shows how to create a `Backup` CR named `demo1-log-backup-azblob`. See the following detailed steps. +#### Log backup subcommands + +The logSubcommand field in the Backup CR allows you to control the status of a log backup task. There are three valid inputs for logSubcommand: + + • log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. + + • log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. + + • log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. + +These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. + + +In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. + +However, you must not mix logStop with logSubcommand in the same YAML file. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. + + #### Start log backup 1. In the `backup-test` namespace, create a `Backup` CR named `demo1-log-backup-azblob`. @@ -158,6 +176,7 @@ You can use a `Backup` CR to describe the start and stop of a log backup task an namespace: backup-test spec: backupMode: log + logSubcommand: log-start br: cluster: demo1 clusterNamespace: test1 @@ -218,15 +237,87 @@ Conditions: Log Checkpoint Ts: 436569119308644661 ``` +#### Pause log backup + +Because you already created a `Backup` CR named `demo1-log-backup-azblob` when you started log backup, you can pause the log backup by modifying the same `Backup` CR. + +```shell +kubectl edit backup log-backup-azblob -n backup-test +``` + +To pause the log backup task, you only need to change the `logSubcommand` from `log-start` to `log-pause`. Then save and quit the editor. The modified content is as follows: + + ```yaml + --- + apiVersion: pingcap.com/v1alpha1 + kind: Backup + metadata: + name: demo1-log-backup-azblob + namespace: backup-test + spec: + backupMode: log + logSubcommand: log-pause + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + azblob: + secretName: azblob-secret + container: my-container + prefix: my-log-backup-folder + #accessTier: Hot + ``` + +You can view the log backup status by checking the information of the `Backup` CR: + +```shell +kubectl get backup -n backup-test +``` +``` +NAME MODE STATUS .... +log-backup-azblob log Pause .... +``` + +#### Resume log backup + +If a log backup task is paused, you could set `logSubcommand: log-start` to resume it. Be aware that, you couldn't resume a task from `Fail` or `Stopped` state. + +```shell +kubectl edit backup log-backup-azblob.yaml -n backup-test +``` + +To resume the log backup task, you only need to change the `logSubcommand` from `log-pause` to `log-start`. Then save and quit the editor. The modified content is as follows: + + ```yaml + --- + apiVersion: pingcap.com/v1alpha1 + kind: Backup + metadata: + name: demo1-log-backup-azblob + namespace: backup-test + spec: + backupMode: log + logSubcommand: log-start + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + azblob: + secretName: azblob-secret + container: my-container + prefix: my-log-backup-folder + #accessTier: Hot + ``` + #### Stop log backup -Because you already created a `Backup` CR named `demo1-log-backup-azblob` when you started log backup, you can stop the log backup by modifying the same `Backup` CR. The priority of all operations is: stop log backup > delete log backup data > start log backup. +Because you already created a `Backup` CR named `demo1-log-backup-azblob` when you started log backup, you can stop the log backup by modifying the same `Backup` CR. ```shell kubectl edit backup demo1-log-backup-azblob -n backup-test ``` -In the last line of the CR, append `spec.logStop: true`. Then save and quit the editor. The modified content is as follows: +Change the `logSubcommand` to `log-stop`. Then save and quit the editor. The modified content is as follows: ```yaml --- @@ -237,6 +328,7 @@ metadata: namespace: backup-test spec: backupMode: log + logSubcommand: log-stop br: cluster: demo1 clusterNamespace: test1 @@ -246,7 +338,6 @@ spec: container: my-container prefix: my-log-backup-folder #accessTier: Hot - logStop: true ``` You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-azblob` change from `Running` to `Stopped`: @@ -261,12 +352,14 @@ demo1-log-backup-azblob log Stopped .... ``` -You can stop log backup by taking the same steps as in [Start log backup](#start-log-backup). The existing `Backup` CR will be updated. +Stopped is the terminated state of a log backup CR, you couldn't change the state again, but you still could clean log backup data. + +In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. #### Clean log backup data -1. Because you already created a `Backup` CR named `demo1-log-backup-azblob` when you started log backup, you can clean the log data backup by modifying the same `Backup` CR. The priority of all operations is: stop log backup > delete log backup data > start log backup. The following example shows how to clean log backup data generated before 2022-10-10T15:21:00+08:00. +1. Because you already created a `Backup` CR named `demo1-log-backup-azblob` when you started log backup, you can clean the log data backup by modifying the same `Backup` CR. The following example shows how to clean log backup data generated before 2022-10-10T15:21:00+08:00. ```shell kubectl edit backup demo1-log-backup-azblob -n backup-test @@ -283,6 +376,7 @@ You can stop log backup by taking the same steps as in [Start log backup](#start namespace: backup-test spec: backupMode: log + logSubcommand: log-start/log-pause/log-stop br: cluster: demo1 clusterNamespace: test1 diff --git a/en/backup-to-gcs-using-br.md b/en/backup-to-gcs-using-br.md index 1ae57c95d..55955e0b0 100644 --- a/en/backup-to-gcs-using-br.md +++ b/en/backup-to-gcs-using-br.md @@ -142,7 +142,25 @@ demo1-full-backup-gcs full snapshot Complete gcs://my-bucket/my-full-bac ### Log backup -You can use a `Backup` CR to describe the start and stop of a log backup task and manage the log backup data. Log backup grants permissions to remote storages in the same way as snapshot backup. In this section, the example shows how to create a `Backup` CR named `demo1-log-backup-s3`. See the following detailed steps. +You can use a `Backup` CR to describe the start and stop of a log backup task and manage the log backup data. Log backup grants permissions to remote storages in the same way as snapshot backup. In this section, the example shows how to create a `Backup` CR named `demo1-log-backup-gcs`. See the following detailed steps. + +#### Log backup subcommands + +The logSubcommand field in the Backup CR allows you to control the status of a log backup task. There are three valid inputs for logSubcommand: + + • log-start: This command initiates a new log backup task or resumes an existing task that has been paused. It can be used to start the log backup process or resume from the paused state. + + • log-pause: This command temporarily pauses an active log backup task. The task can be resumed later using the log-start command. + + • log-stop: This command permanently stops the log backup task. When this command is issued, the Backup CR enters a stopped state and cannot be restarted. + +These commands allow fine-grained control over the lifecycle of log backup tasks, enabling start, pause, resume, and stop operations to manage log data retention in a Kubernetes environment. + + +In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. + +However, you must not mix logStop with logSubcommand in the same YAML file. Doing so is unsupported, and using logStop is not recommended in later versions. Stick to logSubcommand for better clarity and consistency. + #### Start log backup @@ -223,15 +241,99 @@ Conditions: Log Checkpoint Ts: 436569119308644661 ``` +#### Pause log backup + +Because you already created a `Backup` CR named `demo1-log-backup-gcs` when you started log backup, you can pause the log backup by modifying the same `Backup` CR. + +```shell +kubectl edit backup demo1-log-backup-gcs -n backup-test +``` + +To pause the log backup task, you only need to change the `logSubcommand` from `log-start` to `log-pause`. Then save and quit the editor. The modified content is as follows: + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-gcs + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-pause + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + gcs: + projectId: ${project_id} + secretName: gcs-secret + bucket: my-bucket + prefix: my-log-backup-folder +``` + +You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-gcs` change from `Running` to `Pause`: + +```shell +kubectl get backup -n backup-test +``` + +``` +NAME MODE STATUS .... +demo1-log-backup-gcs log Pause .... +``` + +#### Resume log backup + +If a log backup task is paused, you could set `logSubcommand: log-start` to resume it. Be aware that, you couldn't resume a task from `Fail` or `Stopped` state. + +```shell +kubectl edit backup demo1-log-backup-gcs -n backup-test +``` + +To resume the log backup task, you only need to change the `logSubcommand` from `log-pause` to `log-start`. Then save and quit the editor. The modified content is as follows: + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-gcs + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-start + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + gcs: + projectId: ${project_id} + secretName: gcs-secret + bucket: my-bucket + prefix: my-log-backup-folder +``` + +You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-gcs` change from `Running` to `Pause`: + +```shell +kubectl get backup -n backup-test +``` + +``` +NAME MODE STATUS .... +demo1-log-backup-gcs log Running .... +``` + #### Stop log backup -Because you already created a `Backup` CR named `demo1-log-backup-gcs` when you started log backup, you can stop the log backup by modifying the same `Backup` CR. The priority of all operations is: stop log backup > delete log backup data > start log backup. +Because you already created a `Backup` CR named `demo1-log-backup-gcs` when you started log backup, you can stop the log backup by modifying the same `Backup` CR. ```shell kubectl edit backup demo1-log-backup-gcs -n backup-test ``` -In the last line of the CR, append `spec.logStop: true`. Then save and quit the editor. The modified content is as follows: +Change the `logSubcommand` to `log-stop`. Then save and quit the editor. The modified content is as follows: ```yaml --- @@ -242,6 +344,7 @@ metadata: namespace: backup-test spec: backupMode: log + logSubcommand: log-stop br: cluster: demo1 clusterNamespace: test1 @@ -251,7 +354,6 @@ spec: secretName: gcs-secret bucket: my-bucket prefix: my-log-backup-folder - logStop: true ``` You can see the `STATUS` of the `Backup` CR named `demo1-log-backup-gcs` change from `Running` to `Stopped`: @@ -266,12 +368,14 @@ demo1-log-backup-gcs log Stopped .... ``` -You can also stop log backup by taking the same steps as in [Start log backup](#start-log-backup). The existing `Backup` CR will be updated. +Stopped is the terminated state of a log backup CR, you couldn't change the state again, but you still could clean log backup data. + +In v1.5.5 and earlier TiDB Operator versions, you could use the logStop: true/false field to stop or start a task. This field is retained for backward compatibility. #### Clean log backup data -1. Because you already created a `Backup` CR named `demo1-log-backup-gcs` when you started log backup, you can clean the log data backup by modifying the same `Backup` CR. The priority of all operations is: stop log backup > delete log backup data > start log backup. The following example shows how to clean log backup data generated before 2022-10-10T15:21:00+08:00. +1. Because you already created a `Backup` CR named `demo1-log-backup-gcs` when you started log backup, you can clean the log data backup by modifying the same `Backup` CR. The following example shows how to clean log backup data generated before 2022-10-10T15:21:00+08:00. ```shell kubectl edit backup demo1-log-backup-gcs -n backup-test @@ -288,6 +392,7 @@ You can also stop log backup by taking the same steps as in [Start log backup](# namespace: backup-test spec: backupMode: log + logSubcommand: log-start/log-pause/log-stop br: cluster: demo1 clusterNamespace: test1 diff --git a/zh/backup-to-aws-s3-using-br.md b/zh/backup-to-aws-s3-using-br.md index 153fb7627..007d867f5 100644 --- a/zh/backup-to-aws-s3-using-br.md +++ b/zh/backup-to-aws-s3-using-br.md @@ -325,7 +325,7 @@ Log Checkpoint Ts: 436569119308644661 #### 暂停日志备份 -由于在启动日志备份时已经创建了名为 demo1-log-backup-s3 的 Backup 自定义资源（CR），可以通过修改相同的 Backup CR 来暂停日志备份。 +由于在启动日志备份时已经创建了名为 `demo1-log-backup-s3` 的 Backup 自定义资源（CR），可以通过修改相同的 Backup CR 来暂停日志备份。 ```shell kubectl edit backup demo1-log-backup-s3 -n backup-test diff --git a/zh/backup-to-azblob-using-br.md b/zh/backup-to-azblob-using-br.md index 741626ad9..909bb5d07 100644 --- a/zh/backup-to-azblob-using-br.md +++ b/zh/backup-to-azblob-using-br.md @@ -219,15 +219,107 @@ Conditions: Log Checkpoint Ts: 436569119308644661 ``` +#### 暂停日志备份 + +由于在启动日志备份时已经创建了名为 `demo1-log-backup-azblob` 的 Backup 自定义资源（CR），可以通过修改相同的 Backup CR 来暂停日志备份。 + +```shell +kubectl edit backup demo1-log-backup-azblob -n backup-test +``` + +要暂停日志备份任务，只需将 logSubcommand 从 log-start 更改为 log-pause。然后保存并退出编辑器。修改后的内容如下： + + ```shell + kubectl apply -f log-backup-azblob.yaml + ``` + + `log-backup-azblob.yaml` 文件内容如下： + + ```yaml + --- + apiVersion: pingcap.com/v1alpha1 + kind: Backup + metadata: + name: demo1-log-backup-azblob + namespace: backup-test + spec: + backupMode: log + logSubcommand: log-pause + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + s3: + provider: aws + secretName: s3-secret + region: us-west-1 + bucket: my-bucket + prefix: my-log-backup-folder + ``` + +可以看到名为 `demo1-log-backup-azblob` 的 `Backup` CR 的 `STATUS` 从 `Running` 变成了 `Pause`： + +```shell +kubectl get backup -n backup-test +``` + +``` +NAME MODE STATUS .... +demo1-log-backup-azblob log Pause .... +``` + +#### 恢复日志备份 + +如果日志备份任务已暂停，可以将 logSubcommand 设置为 log-start 来恢复它。请注意，你无法从 Fail 或 Stopped 状态恢复任务。 + +```shell +kubectl edit backup demo1-log-backup-azblob -n backup-test +``` + +要恢复日志备份任务，只需将 logSubcommand 从 log-pause 更改为 log-start。然后保存并退出编辑器。修改后的内容如下： + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-azblob + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-start + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + s3: + provider: aws + secretName: s3-secret + region: us-west-1 + bucket: my-bucket + prefix: my-log-backup-folder +``` + +可以看到名为 demo1-log-backup-azblob 的 Backup CR 的 STATUS 从 Paused 状态变为 Running： + +```shell +kubectl get backup -n backup-test +``` + +``` +NAME MODE STATUS .... +demo1-log-backup-azblob log Running .... +``` + #### 停止日志备份 -由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-azblob` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活停止日志备份的操作。操作激活优先级从高到低分别是停止日志备份任务、删除日志备份数据和开启日志备份任务。 +由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-azblob` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，停止日志备份。 ```shell kubectl edit backup demo1-log-backup-azblob -n backup-test ``` -在最后新增一行字段 `spec.logStop: true`，保存并退出。更新后的内容如下： +将 logSubcommand 更改为 log-stop。然后保存并退出编辑器。修改后的内容如下： ```yaml --- @@ -238,6 +330,7 @@ metadata: namespace: backup-test spec: backupMode: log + logSubcommand: log-stop br: cluster: demo1 clusterNamespace: test1 @@ -247,7 +340,6 @@ spec: container: my-container prefix: my-log-backup-folder #accessTier: Hot - logStop: true ``` 可以看到名为 `demo1-log-backup-azblob` 的 `Backup` CR 的 `STATUS` 从 `Running` 变成了 `Stopped`： @@ -262,12 +354,14 @@ demo1-log-backup-azblob log Stopped .... ``` -你也可以采用和启动日志备份时相同的方法来停止日志备份，已经被创建过的 `Backup` CR 会因此被更新。 +Stopped 是日志备份的终止状态，此状态下无法再次更改状态，但你仍然可以清理日志备份的数据。 + +在 v1.5.5 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 #### 清理日志备份数据 -1. 由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-azblob` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活清理日志备份数据的操作。操作激活优先级从高到低分别是停止日志备份任务、删除日志备份数据和开启日志备份任务。执行如下操作来清理 2022-10-10T15:21:00+08:00 之前的所有日志备份数据。 +1. 由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-azblob` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活清理日志备份数据的操作。执行如下操作来清理 2022-10-10T15:21:00+08:00 之前的所有日志备份数据。 ```shell kubectl edit backup demo1-log-backup-azblob -n backup-test @@ -284,6 +378,7 @@ demo1-log-backup-azblob log Stopped .... namespace: backup-test spec: backupMode: log + logSubcommand: log-start/log-pause/log-stop br: cluster: demo1 clusterNamespace: test1 diff --git a/zh/backup-to-gcs-using-br.md b/zh/backup-to-gcs-using-br.md index 112f4fc32..ee8a20628 100644 --- a/zh/backup-to-gcs-using-br.md +++ b/zh/backup-to-gcs-using-br.md @@ -144,6 +144,24 @@ demo1-full-backup-gcs full snapshot Complete gcs://my-bucket/my-full-bac 你可以使用一个 `Backup` CR 来描述日志备份任务的启动、停止以及清理日志备份数据等操作。日志备份对远程存储访问授权方式与快照备份一致。本节示例创建了名为 `demo1-log-backup-gcs` 的 `Backup` CR，具体操作如下所示。 +#### 日志备份的`logSubcommand` + +Backup 自定义资源（CR）中的 logSubcommand 字段允许你控制日志备份任务的状态。logSubcommand 有三个有效输入： + + • log-start：该命令用于启动新的日志备份任务，或恢复已暂停的任务。它可用于启动日志备份进程或从暂停状态恢复任务。 + + • log-pause：该命令用于暂时暂停活动中的日志备份任务。稍后可以通过 log-start 命令恢复任务。 + + • log-stop：该命令永久停止日志备份任务。当执行此命令时，Backup CR 将进入停止状态且无法重启。 + +这些命令使日志备份任务的生命周期控制更加精细，支持启动、暂停、恢复和停止操作，以管理 Kubernetes 环境中的日志数据保留。 + + +在 v1.5.5 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 + +但请勿在同一个 YAML 文件中混用 logStop 和 logSubcommand，这属于不支持的用法。在较新版本中，不推荐使用 logStop，建议使用 logSubcommand 以确保配置清晰且一致。 + + #### 启动日志备份 1. 在 `backup-test` 这个 namespace 中创建一个名为 `demo1-log-backup-gcs` 的 `Backup` CR。 @@ -223,15 +241,99 @@ Conditions: Log Checkpoint Ts: 436569119308644661 ``` +#### 暂停日志备份 + +由于在启动日志备份时已经创建了名为 `demo1-log-backup-gcs` 的 Backup 自定义资源（CR），可以通过修改相同的 Backup CR 来暂停日志备份。 + +```shell +kubectl edit backup demo1-log-backup-gcs -n backup-test +``` + +要暂停日志备份任务，只需将 logSubcommand 从 log-start 更改为 log-pause。然后保存并退出编辑器。修改后的内容如下： + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-gcs + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-pause + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + gcs: + projectId: ${project_id} + secretName: gcs-secret + bucket: my-bucket + prefix: my-log-backup-folder +``` + +可以看到名为 `demo1-log-backup-gcs` 的 `Backup` CR 的 `STATUS` 从 `Running` 变成了 `Pause`： + +```shell +kubectl get backup -n backup-test +``` + +``` +NAME MODE STATUS .... +demo1-log-backup-gcs log Pause .... +``` + +#### 恢复日志备份 + +如果日志备份任务已暂停，可以将 logSubcommand 设置为 log-start 来恢复它。请注意，你无法从 Fail 或 Stopped 状态恢复任务。 + +```shell +kubectl edit backup demo1-log-backup-gcs -n backup-test +``` + +要恢复日志备份任务，只需将 logSubcommand 从 log-pause 更改为 log-start。然后保存并退出编辑器。修改后的内容如下： + +```yaml +--- +apiVersion: pingcap.com/v1alpha1 +kind: Backup +metadata: + name: demo1-log-backup-gcs + namespace: backup-test +spec: + backupMode: log + logSubcommand: log-start + br: + cluster: demo1 + clusterNamespace: test1 + sendCredToTikv: true + gcs: + projectId: ${project_id} + secretName: gcs-secret + bucket: my-bucket + prefix: my-log-backup-folder +``` + +可以看到名为 demo1-log-backup-gcs 的 Backup CR 的 STATUS 从 Paused 状态变为 Running： + +```shell +kubectl get backup -n backup-test +``` + +``` +NAME MODE STATUS .... +demo1-log-backup-gcs log Running .... +``` + #### 停止日志备份 -由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-gcs` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活停止日志备份的操作。操作激活优先级从高到低分别是停止日志备份任务、删除日志备份数据和开启日志备份任务。 +由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-gcs` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活停止日志备份的操作。 ```shell kubectl edit backup demo1-log-backup-gcs -n backup-test ``` -在最后新增一行字段 `spec.logStop: true`，保存并退出。更新后的内容如下： +将 logSubcommand 更改为 log-stop。然后保存并退出编辑器。修改后的内容如下： ```yaml --- @@ -242,6 +344,7 @@ metadata: namespace: backup-test spec: backupMode: log + logSubcommand: log-stop br: cluster: demo1 clusterNamespace: test1 @@ -266,12 +369,14 @@ demo1-log-backup-gcs log Stopped .... ``` -你也可以采用和启动日志备份时相同的方法来停止日志备份，已经被创建过的 `Backup` CR 会因此被更新。 +Stopped 是日志备份的终止状态，此状态下无法再次更改状态，但你仍然可以清理日志备份的数据。 + +在 v1.5.5 及更早版本的 TiDB Operator 中，可以使用 logStop: true/false 字段来停止或启动任务。此字段为了向后兼容而保留。 #### 清理日志备份数据 -1. 由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-gcs` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活清理日志备份数据的操作。操作激活优先级从高到低分别是停止日志备份任务、删除日志备份数据和开启日志备份任务。执行如下操作来清理 2022-10-10T15:21:00+08:00 之前的所有日志备份数据。 +1. 由于你在开启日志备份的时候已经创建了名为 `demo1-log-backup-gcs` 的 `Backup` CR，因此可以直接更新该 `Backup` CR 的配置，来激活清理日志备份数据的操作。执行如下操作来清理 2022-10-10T15:21:00+08:00 之前的所有日志备份数据。 ```shell kubectl edit backup demo1-log-backup-gcs -n backup-test @@ -288,6 +393,7 @@ demo1-log-backup-gcs log Stopped .... namespace: backup-test spec: backupMode: log + logSubcommand: log-start/log-pause/log-stop br: cluster: demo1 clusterNamespace: test1