This is an automated cherry-pick of pingcap#20973

Signed-off-by: ti-chi-bot <[email protected]>

Author: qiancai

br/br-snapshot-guide.md

@@ -202,6 +202,7 @@ TiDB 备份功能对集群性能（事务延迟和 QPS）有一定的影响，
 ### 快照恢复的性能与影响
 
 - TiDB 恢复的时候会尽可能打满 TiKV CPU、磁盘 IO、网络带宽等资源，所以推荐在空的集群上执行备份数据的恢复，避免对正在运行的业务产生影响。
+<<<<<<< HEAD
 - 备份数据的恢复速度与集群配置、部署、运行的业务都有比较大的关系。在内部多场景仿真测试中，单 TiKV 存储节点上备份数据恢复速度能够达到 100 MiB/s。在不同用户场景下，快照恢复的性能和影响应以实际测试结论为准。
 - BR 提供了粗粒度的 Region 打散算法，用于提升大规模 Region 场景下的 Region 恢复速度。该算法通过命令行参数 `--granularity="coarse-grained"` 控制，并默认启用。在这个方式下每个 TiKV 节点会得到均匀稳定的下载任务，从而充分利用每个 TiKV 节点的所有资源实现并行快速恢复。在实际案例中，大规模 Region 场景下，集群快照恢复速度最高提升约 3 倍。使用示例如下：
 
@@ -215,6 +216,10 @@ TiDB 备份功能对集群性能（事务延迟和 QPS）有一定的影响，
     --log-file restorefull.log
     ```
 
+=======
+- 备份数据的恢复速度与集群配置、部署、运行的业务都有比较大的关系。在不同用户场景下，快照恢复的性能和影响应以实际测试结论为准。
+- BR 提供了粗粒度的 Region 打散算法，用于提升大规模 Region 场景下的 Region 恢复速度。在这个方式下每个 TiKV 节点会得到均匀稳定的下载任务，从而充分利用每个 TiKV 节点的所有资源实现并行快速恢复。在实际案例中，大规模 Region 场景下，集群快照恢复速度最高提升约 3 倍。
+>>>>>>> 5a952e79c6 (br: removed the sentence about the outdated restore speed (#20973))
 - 从 v8.0.0 起，`br` 命令行工具新增 `--tikv-max-restore-concurrency` 参数，用于控制每个 TiKV 节点的最大 download 和 ingest 文件数量。此外，通过调整此参数，可以控制作业队列的最大长度（作业队列的最大长度 = 32 \* TiKV 节点数量 \* `--tikv-max-restore-concurrency`），进而控制 BR 节点的内存消耗。
 
     通常情况下，`--tikv-max-restore-concurrency` 会根据集群配置自动调整，无需手动设置。如果通过 Grafana 中的 **TiKV-Details** > **Backup & Import** > **Import RPC count** 监控指标发现 download 文件数量长时间接近于 0，而 ingest 文件数量一直处于上限时，说明 ingest 文件任务存在堆积，并且作业队列已达到最大长度。此时，可以采取以下措施来缓解任务堆积问题：