v2: remove BackupSchedule and CompactBackup CR related description (#3078)

Author: yiduoyunQ

en/backup-restore-cr.md

@@ -5,7 +5,7 @@ summary: Learn the fields in the Backup and Restore custom resources (CR).
 
 # Backup and Restore Custom Resources
 
-This document describes the fields in the `Backup`, `CompactBackup`, `Restore`, and `BackupSchedule` custom resources (CR). You can use these fields to better perform the backup or restore of TiDB clusters on Kubernetes.
+This document describes the fields in the `Backup` and `Restore` custom resources (CR). You can use these fields to better perform the backup or restore of TiDB clusters on Kubernetes.
 
 ## Backup CR fields
 
@@ -193,32 +193,6 @@ To back up data for a TiDB cluster on Kubernetes, you can create a `Backup` cust
 * `.spec.local.volume`: the persistent volume configuration.
 * `.spec.local.volumeMount`: the persistent volume mount configuration.
 
-## CompactBackup CR fields
-
-For TiDB v9.0.0 and later versions, you can use `CompactBackup` to accelerate PITR (Point-in-time recovery). To compact log backup data into structured SST files, you can create a custom `CompactBackup` CR object to define a backup task. The following introduces the fields in the `CompactBackup` CR:
-
-* `.spec.startTs`: the start timestamp for log compaction backup.
-* `.spec.endTs`: the end timestamp for log compaction backup.
-* `.spec.concurrency`: the maximum number of concurrent log compaction tasks. The default value is `4`.
-* `.spec.maxRetryTimes`: the maximum number of retries for failed compaction tasks. The default value is `6`.
-* `.spec.toolImage`: the tool image used by `CompactBackup`. BR is the only tool image used in `CompactBackup`. When using BR for backup, you can specify the BR version with this field:
-    - If not specified or left empty, the `pingcap/br:${tikv_version}` image is used for backup by default.
-    - If a BR version is specified, such as `.spec.toolImage: pingcap/br:v9.0.0`, the image of the specified version is used for backup.
-    - If an image is specified without a version, such as `.spec.toolImage: private/registry/br`, the `private/registry/br:${tikv_version}` image is used for backup.
-
-* `.spec.env`: the environment variables for the Pod that runs the compaction task.
-* `.spec.affinity`: the affinity configuration for the Pod that runs the compaction task. For details on affinity, refer to [Affinity and anti-affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity).
-* `.spec.tolerations`: specifies that the Pod that runs the compaction task can schedule onto nodes with matching [taints](https://kubernetes.io/docs/reference/glossary/?all=true#term-taint). For details on taints and tolerations, refer to [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/).
-* `.spec.podSecurityContext`: the security context configuration for the Pod that runs the compaction task, which allows the Pod to run as a non-root user. For details on `podSecurityContext`, refer to [Run Containers as a Non-root User](containers-run-as-non-root-user.md).
-* `.spec.priorityClassName`: the name of the priority class for the Pod that runs the compaction task, which sets priority for the Pod. For details on priority classes, refer to [Pod Priority and Preemption](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/).
-* `.spec.imagePullSecrets`: the [imagePullSecrets](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) for the Pod that runs the compaction task.
-* `.spec.serviceAccount`: the name of the ServiceAccount used for compact.
-* `.spec.useKMS`: whether to use AWS-KMS to decrypt the S3 storage key used for the backup.
-* `.spec.br`: BR-related configuration. For more information, refer to [BR fields](#br-fields).
-* `.spec.s3`: S3-related configuration. For more information, refer to [S3 storage fields](#s3-storage-fields).
-* `.spec.gcs`: GCS-related configuration. For more information, refer to [GCS fields](#gcs-fields).
-* `.spec.azblob`: Azure Blob Storage-related configuration. For more information, refer to [Azure Blob Storage fields](#azure-blob-storage-fields).
-
 ## Restore CR fields
 
 To restore data to a TiDB cluster on Kubernetes, you can create a `Restore` CR object. For detailed restore process, refer to documents listed in [Restore data](backup-restore-overview.md#restore-data). This section introduces the fields in the `Restore` CR.
@@ -258,21 +232,3 @@ To restore data to a TiDB cluster on Kubernetes, you can create a `Restore` CR o
 * `.spec.gcs`: GCS-related configuration. Refer to [GCS fields](#gcs-fields).
 * `.spec.azblob`: Azure Blob Storage-related configuration. Refer to [Azure Blob Storage fields](#azure-blob-storage-fields).
 * `.spec.local`: persistent volume-related configuration. Refer to [Local storage fields](#local-storage-fields).
-
-## BackupSchedule CR fields
-
-The `backupSchedule` configuration consists of three parts: the configuration of the snapshot backup `backupTemplate`, the configuration of the log backup `logBackupTemplate`, and the unique configuration of `backupSchedule`.
-
-* `backupTemplate`: the configuration of the snapshot backup. Specifies the configuration related to the cluster and remote storage of the snapshot backup, which is the same as the `spec` configuration of [the `Backup` CR](#backup-cr-fields).
-* `logBackupTemplate`: the configuration of the log backup. Specifies the configuration related to the cluster and remote storage of the log backup, which is the same as the `spec` configuration of [the `Backup` CR](#backup-cr-fields). The log backup is created and deleted along with `backupSchedule` and recycled according to `.spec.maxReservedTime`. The log backup name is saved in `status.logBackup`.
-* `compactBackupTemplate`: the configuration template of the log compaction backup. The fields are the same as those in the `spec` configuration of [the `CompactBackup` CR](#compactbackup-cr-fields). The compaction backup is created and deleted along with `backupSchedule`. The log backup names are stored in `status.logBackup`. The storage settings of the compaction backup should be the same as that of `logBackupTemplate` in the same `backupSchedule`.
-
-    > **Note:**
-    >
-    > Before you delete the log backup data, you need to stop the log backup task to avoid resource waste or the inability to restart the log backup task in the future because the log backup task in TiKV is not stopped.
-
-* The unique configuration items of `backupSchedule` are as follows:
-    * `.spec.maxBackups`: a backup retention policy, which determines the maximum number of backup files to be retained. When the number of backup files exceeds this value, the outdated backup file will be deleted. If you set this field to `0`, all backup items are retained.
-    * `.spec.maxReservedTime`: a backup retention policy based on time. For example, if you set the value of this field to `24h`, only backup files within the recent 24 hours are retained. All backup files older than this value are deleted. For the time format, refer to [`func ParseDuration`](https://golang.org/pkg/time/#ParseDuration). If you have set `.spec.maxBackups` and `.spec.maxReservedTime` at the same time, the latter takes effect.
-    * `.spec.schedule`: the time scheduling format of Cron. Refer to [Cron](https://en.wikipedia.org/wiki/Cron) for details.
-    * `.spec.pause`: `false` by default. If this field is set to `true`, the scheduled scheduling is paused. In this situation, the backup operation will not be performed even if the scheduling time point is reached. During this pause, the backup garbage collection runs normally. If you change `true` to `false`, the scheduled snapshot backup process is restarted. Because currently, log backup does not support pause, this configuration does not take effect for log backup.

en/backup-restore-overview.md

@@ -39,28 +39,31 @@ To recover the SST files exported by BR to a TiDB cluster, use BR. For more info
 
 ## Backup and restore process
 
-To make a backup of the TiDB cluster on Kubernetes, you need to create a [`Backup` CR](backup-restore-cr.md#backup-cr-fields) object to describe the backup or create a [`BackupSchedule` CR](backup-restore-cr.md#backupschedule-cr-fields) object to describe a scheduled backup.
+To make a backup of the TiDB cluster on Kubernetes, you need to create a [`Backup` CR](backup-restore-cr.md#backup-cr-fields) object to describe the backup.
+
+> **Warning:**
+>
+> Currently, TiDB Operator v2 does not support the `BackupSchedule` CR. To perform scheduled snapshot backups, scheduled log backups, or scheduled compact log backups, use TiDB Operator v1.x and see [BackupSchedule CR fields](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/backup-restore-cr/#backupschedule-cr-fields).
 
 To restore data to the TiDB cluster on Kubernetes, you need to create a [`Restore` CR](backup-restore-cr.md#restore-cr-fields) object to describe the restore.
 
 After creating the CR object, according to your configuration, TiDB Operator chooses the corresponding tool and performs the backup or restore.
 
 ## Delete the Backup CR
 
-You can delete the `Backup` CR or `BackupSchedule` CR by running the following commands:
+You can delete the `Backup` CR by running the following commands:
 
 ```shell
 kubectl delete backup ${name} -n ${namespace}
-kubectl delete backupschedule ${name} -n ${namespace}
 ```
 
 If you set the value of `spec.cleanPolicy` to `Delete`, TiDB Operator cleans the backup data when it deletes the CR.
 
 TiDB Operator automatically attempts to stop running log backup tasks when you delete the Custom Resource (CR). This automatic stop feature only applies to log backup tasks that are running normally and does not handle tasks in an error or failed state.
 
-In such cases, if you need to delete the namespace, it is recommended that you first delete all the `Backup` or `BackupSchedule` CRs and then delete the namespace.
+In such cases, if you need to delete the namespace, it is recommended that you first delete the `Backup` CR and then delete the namespace.
 
-If you delete the namespace before you delete the `Backup` or `BackupSchedule` CR, TiDB Operator will keep creating jobs to clean the backup data. However, because the namespace is in `Terminating` state, TiDB Operator fails to create such a job, which causes the namespace to be stuck in this state.
+If you delete the namespace before you delete the `Backup` CR, TiDB Operator will keep creating jobs to clean the backup data. However, because the namespace is in `Terminating` state, TiDB Operator fails to create such a job, which causes the namespace to be stuck in this state.
 
 To address this issue, delete `finalizers` by running the following command: