br: fix typos and add correct aliases (#12044)

br/backup-and-restore-overview.md

@@ -49,7 +49,7 @@ TiDB 备份恢复功能可以用于满足以下业务的需求：
 #### 备份的性能，以及对集群的影响
 
 - 集群快照数据备份，对 TiDB 集群的影响可以保持在 20% 以下；通过合理的配置 TiDB 集群用于备份资源，影响可以降低到 10% 及更低；单 TiKV 存储节点的备份速度可以达到 50 MB/s ～ 100 MB/s，备份速度具有可扩展性；更详细说明请参考[备份性能和影响](/br/br-snapshot-guide.md#快照备份的性能与影响)。
-- 单独运行日志备份时影响约在 5%。日志备份每隔 5～10 分钟将新上次刷新后产生变更数据记录全部刷新到备份存储中，可以**实现低至十分钟 RPO 的集群容灾目标**。
+- 单独运行日志备份时影响约在 5%。日志备份每隔 5～10 分钟将上次刷新后产生的变更数据记录刷新到备份存储中，可以**实现低至十分钟 RPO 的集群容灾目标**。
 
 ### 恢复备份数据
 
@@ -66,7 +66,7 @@ TiDB 备份恢复功能可以用于满足以下业务的需求：
 #### 恢复的性能
 
 - 恢复集群快照数据备份，速度可以达到单 TiKV 存储节点 100 MiB/s，恢复速度具有可扩展性；BR 只支持恢复数据到新集群，会尽可能多的使用恢复集群的资源。更详细说明请参考[恢复性能和影响](/br/br-snapshot-guide.md#快照恢复的性能与影响)。
-- 恢复日志备份数据，速度可以达到 30 GiB/h。更详细说明请参考 [PITR 性能和影响](/br/br-pitr-guide.md#性能与影响)。
+- 恢复日志备份数据，速度可以达到 30 GiB/h。更详细说明请参考 [PITR 性能和影响](/br/br-pitr-guide.md#pitr-的性能与影响)。
 
 ## 备份存储
 

br/backup-and-restore-storages.md

@@ -1,7 +1,7 @@
 ---
 title: 备份存储
 summary: 了解 BR 支持的备份存储服务的 URL 格式、鉴权方案和使用方式。
-aliases: ['/zh/tidb/dev/backup-storage-S3/','/zh/tidb/dev/backup-storage-azblob/','/zh/tidb/dev/backup-storage-gcs/']
+aliases: ['/docs-cn/dev/br/backup-and-restore-storages/','/zh/tidb/dev/backup-storage-S3/','/zh/tidb/dev/backup-storage-azblob/','/zh/tidb/dev/backup-storage-gcs/']
 ---
 
 # 备份存储

br/br-log-architecture.md

@@ -21,7 +21,7 @@ summary: 了解 TiDB 的日志备份与 PITR 的架构设计。
 
 系统组件和关键概念：
 
-* **local meta**：表示单 TiKV 节点备份下来的数据元信息，主要包括：local checkpoint ts、global checkpoint ts、备份文件信息。
+* **local metadata**：表示单 TiKV 节点备份下来的数据元信息，主要包括：local checkpoint ts、global checkpoint ts、备份文件信息。
 * **local checkpoint ts** (in local metadata)：表示这个 TiKV 中所有小于 local checkpoint ts 的日志数据已经备份到目标存储。
 * **global checkpoint ts**：表示所有 TiKV 中小于 global checkpoint ts 的日志数据已经备份到目标存储。它由运行在 TiDB 中的 Coordinator 模块收集所有 TiKV 的 local checkpoint ts 计算所得，然后上报给 PD。
 * **TiDB Coordinator 组件**：TiDB 集群的某个节点会被选举为 Coordinator，负责收集和计算整个日志备份任务的进度 (global checkpoint ts)。该组件设计上无状态，在其故障后可以从存活的 TiDB 节点中重新选出一个节点作为 Coordinator。
@@ -59,7 +59,7 @@ PITR 的流程如下：
 
 1. BR 接收恢复命令 `br restore point`。
    * 解析获取全量备份数据地址、日志备份数据地址、恢复到的时间点。
-   * 查询备份数据中恢复数据对象（database 或 table），并检查要恢复的表是否符合要求不存在。
+   * 查询备份数据中恢复数据对象（database 或 table），并检查要恢复的表是否存在并符合要求。
 
 2. BR 恢复全量备份。
    * 进行快照备份数据恢复，恢复流程参考[恢复快照备份数据](/br/br-snapshot-architecture.md#恢复流程)。
@@ -88,7 +88,7 @@ PITR 的流程如下：
 日志备份会产生如下类型文件：
 
 - `{min_ts}-{uuid}.log` 文件：存储备份下来的 kv 数据变更记录。其中 `{min_ts}` 是该文件中所有 kv 数据变更记录数对应的最小 ts；`{uuid}` 是生成该文件的时候随机生成的。
-- `{checkpoint_ts}-{uuid}.meta` 文件：每个 TiKV 节点每次上传日志备份数据时会生成一个该文件，保存本次上传的所有日志备份数据文件其中 `{checkpoint_ts}` 是本节点的日志备份的 checkpoint，所有 TiKV 节点的最小的 checkpoint 就是日志备份任务最新的 checkpoint；`{uuid}` 是生成该文件的时候随机生成的。
+- `{checkpoint_ts}-{uuid}.meta` 文件：每个 TiKV 节点每次上传日志备份数据时会生成一个该文件，保存本次上传的所有日志备份数据文件。其中 `{checkpoint_ts}` 是本节点的日志备份的 checkpoint，所有 TiKV 节点的最小的 checkpoint 就是日志备份任务最新的 checkpoint；`{uuid}` 是生成该文件的时候随机生成的。
 - `{store_id}.ts` 文件：每个 TiKV 节点每次上传日志备份数据时会使用 global checkpoint ts 更新该文件。其中 `{store_id}` 是 TiKV 的 store ID。
 - `v1_stream_truncate_safepoint.txt` 文件：保存最近一次通过 `br log truncate` 删除日志备份数据后，存储中最早的日志备份数据对应的 ts。
 

br/br-monitoring-and-alert.md

@@ -44,7 +44,7 @@ aliases: ['/zh/tidb/dev/pitr-monitoring-and-alert/']
 | **tikv_log_backup_flush_file_size**                   | Histogram | 备份产生的文件的大小统计。                                                                                                                                   |
 | **tikv_log_backup_initial_scan_duration_sec**         | Histogram | 增量扫的整体耗时统计。                                                                                                                                     |
 | **tikv_log_backup_skip_retry_observe**                | Counter   | 在日志备份过程中，遇到的可忽略错误的统计，即放弃 retry 的原因。 <br/>`reason :: {"region-absent", "not-leader", "stale-command"}`                                           |
-| **tikv_log_backup_initial_scan_operations**           | Counter   | 增量扫过程中， RocksDB 相关的操作统计。<br/>`cf :: {"default", "write", "lock"}, op :: RocksDBOP`                                                              |
+| **tikv_log_backup_initial_scan_operations**           | Counter   | 增量扫过程中，RocksDB 相关的操作统计。<br/>`cf :: {"default", "write", "lock"}, op :: RocksDBOP`                                                              |
 | **tikv_log_backup_enabled**                           | Counter   | 日志备份功能是否开启，若值大于 0，表示开启                                                                                                                          |
 | **tikv_log_backup_observed_region**                   | Gauge     | 被监听的 Region 数量                                                                                                                                  |
 | **tikv_log_backup_task_status**                       | Gauge     | 日志备份任务状态，0-Running 1-Paused 2-Error <br/>`task :: string`                                                                                       |

br/br-pitr-guide.md

@@ -14,7 +14,7 @@ aliases: ['/zh/tidb/dev/pitr-usage/']
 
 ### 开启日志备份
 
-执行 `br log start` 命令启动日志备份任务，一个集群只能启动一个日志备份任务。该命令输出结果如下：
+执行 `br log start` 命令启动日志备份任务，一个集群只能启动一个日志备份任务。
 
 ```shell
 tiup br log start --task-name=pitr --pd "${PD_IP}:2379" \
@@ -98,9 +98,7 @@ Restore KV Files <--------------------------------------------------------------
     rm -rf s3://backup-101/snapshot-${date}
     ```
 
-## 性能与影响
-
-### PITR 的性能与影响
+## PITR 的性能与影响
 
 ### 能力指标
 
@@ -131,5 +129,5 @@ Restore KV Files <--------------------------------------------------------------
 ## 探索更多
 
 * [TiDB 集群备份与恢复实践示例](/br/backup-and-restore-use-cases.md)
-* [br 命令行手册](/br/use-br-command-line-tool.md)
+* [`br` 命令行手册](/br/use-br-command-line-tool.md)
 * [日志备份与 PITR 架构设计](/br/br-log-architecture.md)

br/br-snapshot-architecture.md

@@ -59,7 +59,7 @@ summary: 了解 TiDB 快照备份与恢复功能的架构设计。
 
 2. BR 调度恢复数据。
     * **Pause Region schedule**：请求 PD 在恢复期间关闭自动 Region schedule。
-    * **Restore schema**：读取备份数据的 schema、恢复的 database 和 table（注意新建表的 table id 与备份数据可能不一样）。
+    * **Restore schema**：读取备份数据的 schema、恢复的 database 和 table（注意新建表的 table ID 与备份数据可能不一样）。
     * **Split & scatter Region**：BR 基于备份数据信息，请求 PD 分配 Region (split Region)，并调度 Region 均匀分布到存储节点上 (scatter Region)。每个 Region 都有明确的数据范围 [start key, end key)。
     * **Request TiKV to restore data**：根据 PD 分配的 Region 结果，发送恢复请求到对应的 TiKV 节点，恢复请求包含要恢复的备份数据及 rewrite 规则。
 

br/br-snapshot-guide.md

@@ -66,7 +66,7 @@ tiup br restore full --pd "${PD_IP}:2379" \
 --storage "s3://backup-101/snapshot-202209081330?access_key=${access_key}&secret_access_key=${secret_access_key}"
 ```
 
-在恢复快照备份数据过程中，终端会显示备份进度条。在完成恢复后，会输出恢复耗时、速度、恢复数据大小等信息。
+在恢复快照备份数据过程中，终端会显示恢复进度条。在完成恢复后，会输出恢复耗时、速度、恢复数据大小等信息。
 
 ```shell
 Full Restore <------------------------------------------------------------------------------> 100.00%
@@ -174,4 +174,4 @@ TiDB 备份功能对集群性能（事务延迟和 QPS）有一定的影响，
 
 * [TiDB 集群备份与恢复实践示例](/br/backup-and-restore-use-cases.md)
 * [`br` 命令行手册](/br/use-br-command-line-tool.md)
-* [快照备份与恢复架构设计](/br/br-snapshot-architecture.md)
+* [快照备份与恢复架构设计](/br/br-snapshot-architecture.md)

br/br-use-overview.md

@@ -77,7 +77,7 @@ Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 是 BR 推荐的存
 TiDB 支持使用 br 工具进行备份恢复。
 
 * 安装方法可以使用[使用 TiUP 在线安装](/migration-tools.md#使用-tiup-快速安装)：`tiup install br`。
-* 了解如何使用 `br` 命令含工具进行备份与恢复，请参阅：
+* 了解如何使用 `br` 命令行工具进行备份与恢复，请参阅：
 
     * [TiDB 快照备份与恢复功能使用](/br/br-snapshot-guide.md)
     * [TiDB 日志备份与 PITR 功能使用](/br/br-pitr-guide.md)
@@ -93,7 +93,7 @@ TiDB 支持使用 SQL 语句进行全量快照备份和恢复：
 
 ### 在 Kubernetes 环境下通过 TiDB Operator
 
-在 Kubernetes 环境下，支持通过 TiDB Operator 支持以 S3、GCS、Azure blob storage 作为备份存储。使用文档请参阅[使用 TiDB Operator 进行备份恢复](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/backup-restore-overview)。
+在 Kubernetes 环境下，支持通过 TiDB Operator 支持以 S3、GCS、Azure blob storage 作为备份存储，并从这些存储系统中恢复备份数据。使用文档请参阅[使用 TiDB Operator 进行备份恢复](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/backup-restore-overview)。
 
 ## 探索更多
 

br/external-storage.md

@@ -1,7 +1,6 @@
 ---
 title: 外部存储
 summary: 了解 BR、TiDB Lightning 和 Dumpling 中所用外部存储服务的 URL 参数。
-aliases: ['/docs-cn/dev/br/backup-and-restore-storages/']
 ---
 
 # 外部存储

faq/backup-and-restore-faq.md

@@ -119,7 +119,7 @@ checkpoint[global]: 2022-07-25 14:46:50.118 +0000; gap=6m28s
 >
 > 由于此功能会备份集群的多版本数据，当任务发生错误且状态变更为 `ERROR` 时，同时会将当前任务的备份进度点的数据设为一个 `safe point`，`safe point` 的数据将保证 24 小时不被 GC 掉。所以，当任务恢复之后，会从上一个备份点继续备份日志。如果任务失败时间超过 24 小时，前一次备份进度点的数据就已经 GC，此时恢复任务操作会提示失败。这种场景下，只能执行 `br log stop` 命令先停止本次任务，然后重新开启新的备份任务。
 
-## 执行 `br log resume` 命令恢复处于暂停状态的任务时报 `ErrBackupGCSafepointExceeded` 错误，该如何处理？
+### 执行 `br log resume` 命令恢复处于暂停状态的任务时报 `ErrBackupGCSafepointExceeded` 错误，该如何处理？
 
 ```shell
 Error: failed to check gc safePoint, checkpoint ts 433177834291200000: GC safepoint 433193092308795392 exceed TS 433177834291200000: [BR:Backup:ErrBackupGCSafepointExceeded]backup GC safepoint exceeded
@@ -131,7 +131,7 @@ Error: failed to check gc safePoint, checkpoint ts 433177834291200000: GC safepo
 
 ## 功能兼容性问题
 
-### BR 恢复到 TiCDC / Drainer 的上游集群时，要注意些什么？
+### 为什么 BR 恢复的数据无法同步到 TiCDC / Drainer 的上游集群？
 
 - **BR 恢复的数据无法被同步到下游**，因为 BR 直接导入 SST 文件，而下游集群目前没有办法获得上游的 SST 文件。
 - 在 4.0.3 版本之前，BR 恢复时产生的 DDL jobs 还可能会让 TiCDC / Drainer 执行异常的 DDL。所以，如果一定要在 TiCDC / Drainer 的上游集群执行恢复，请将 BR 恢复的所有表加入 TiCDC / Drainer 的阻止名单。
@@ -270,9 +270,9 @@ BR 在 v6.0.0 之前不支持[放置规则](/placement-rules-in-sql.md)。BR v6.
 
     由以上命令输出结果可知，`tikv-server` 实例由用户 `tidb_ouo` 启动，但该账号没有 `backup` 目录的写入权限， 所以备份失败。
 
-## 恢复集群的时候，在 MySQL 下的业务表为什么没有恢复？
+### 恢复集群的时候，在 MySQL 下的业务表为什么没有恢复？
 
-自 BR v5.1.0 开始，全量备份会备份**mysql schema 下的表**。BR v6.2.0 以前的版本，在默认设置不会恢复**mysql schema 下的表**。
+自 BR v5.1.0 开始，全量备份会备份 **mysql schema 下的表**。BR v6.2.0 以前的版本，在默认设置不会恢复 **mysql schema 下的表**。
 
 如果需要恢复 `mysql` 下的用户创建的表（非系统表），可以通过 [table filter](/table-filter.md#表库过滤语法) 来显式地包含目标表。以下示例中命令会在执行正常的恢复的同时恢复 `mysql.usertable`。