在 TiDB 中，BR（Backup & Restore）工具支持断点续传功能，主要用于在备份或恢复过程中因网络中断、节点故障等意外情况中断后，能够从断点处继续操作，避免重新执行整个流程，提高效率。
从 TiDB v7.1.0 起，备份恢复特性引入了断点恢复的功能
以下是关于 BR 断点续传的关键信息：
1. 断点续传的支持场景
BR 的断点续传主要针对 备份（br backup） 和 恢复（br restore） 操作，具体支持的场景包括：
- 全量备份 / 恢复
- 增量备份 / 恢复（基于 SST 文件的增量同步）
- 单表 / 多表备份 / 恢复
- 分区表备份 / 恢复
测试案例，在pingcap库中保留fund 表，然后对pingcap库做全库br restore操作，提示 "Full Restore failed summary"
MySQL [pingcap]> delete from fund where f_id = 3;
Query OK, 1 row affected (0.02 sec)
MySQL [pingcap]> select * from fund;
+-----------------+------+-----------+----------+------------+-----------+
| f_name | f_id | f_type | f_amount | risk_level | f_manager |
+-----------------+------+-----------+----------+------------+-----------+
| 股票 | 1 | 股票型 | 10000 | 高 | 1 |
| 投资 | 2 | 债券型 | 10000 | 中 | 2 |
| 沪深300指数 | 4 | 指数型 | 10000 | 中 | 4 |
+-----------------+------+-----------+----------+------------+-----------+
3 rows in set (0.00 sec)
MySQL [pingcap]> exit
Bye
[tidb@tidb01 pingcap]$
[tidb@tidb01 pingcap]$
[tidb@tidb01 pingcap]$
[tidb@tidb01 pingcap]$
[tidb@tidb01 pingcap]$ tiup br restore full \
> --pd "192.168.2.73:2379" \
> --filter 'pingcap.*' \
> --ratelimit 128 \
> -s "local:///tidb/backup/pingcap" \
> --log-file /tidb/backup/pingcap/restore_pingcap_1023.log
Starting component br: /home/tidb/.tiup/components/br/v8.5.2/br restore full --pd 192.168.2.73:2379 --filter pingcap.* --ratelimit 128 -s local:///tidb/backup/pingcap --log-file /tidb/backup/pingcap/restore_pingcap_1023.log
Detail BR log in /tidb/backup/pingcap/restore_pingcap_1023.log
Full Restore <-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%
[2025/10/23 15:45:54.020 +08:00] [INFO] [collector.go:77] ["Full Restore failed summary"] [total-ranges=27] [ranges-succeed=27] [ranges-failed=0] [restore-ranges=14]
Error: failed to validate checksum: [BR:Restore:ErrRestoreChecksumMismatch]restore checksum mismatch
2. 断点续传的实现原理
在br恢复过程中因异常中断，会在数据库中产生一个新库，名字 "_TiDB_BR_Temporary_Snapshot_Restore_Checkpoint"
MySQL [(none)]> show databases;
+-------------------------------------------------+
| Database |
+-------------------------------------------------+
| INFORMATION_SCHEMA |
| METRICS_SCHEMA |
| PERFORMANCE_SCHEMA |
| __TiDB_BR_Temporary_Snapshot_Restore_Checkpoint |
| mysql |
| pingcap |
| sys |
| test |
+-------------------------------------------------+
8 rows in set (0.00 sec)
MySQL [(none)]> use "__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint"
Database changed
MySQL [__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint]> show tables;
+-----------------------------------------------------------+
| Tables_in___TiDB_BR_Temporary_Snapshot_Restore_Checkpoint |
+-----------------------------------------------------------+
| cpt_checksum |
| cpt_data |
| cpt_metadata |
+-----------------------------------------------------------+
3 rows in set (0.00 sec)
在 TiDB BR（Backup & Restore）工具中，__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint 是一个临时内部表，主要用于在快照恢复（Snapshot Restore） 过程中记录恢复进度，支持断点续传功能。以下是关于该表的详细说明：
2.1 作用与功能
该表是 BR 在执行恢复操作时，自动在目标 TiDB 集群中创建的临时表，用于：
- 记录恢复进度：存储已成功恢复的 KV 数据范围、SST 文件信息等 checkpoint（检查点）数据。
- 支持断点续传：当恢复过程因网络中断、节点故障等原因中断后，重新执行恢复命令时，BR 会通过读取该表的记录，跳过已完成的部分，从断点继续恢复，避免重复处理。
2.2 表的特性
- 临时性：仅在恢复过程中存在，恢复完成后会被 BR 自动删除（无论成功或失败，正常情况下都会清理）。
- 内部性：由 BR 工具自动创建和维护，用户无需手动操作，也不建议直接修改该表的数据，否则可能导致恢复异常。
- 存储位置：创建在目标 TiDB 集群的
mysql系统数据库中，表名固定为__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint。
2.3 与断点续传的关联
BR 的快照恢复断点续传依赖该表的记录：
-
恢复开始时，BR 会创建该表并初始化进度信息。
-
恢复过程中，BR 会定期将已完成的任务进度（如已导入的 SST 文件、KV 范围）写入该表。
-
若恢复中断，重新执行恢复命令时，BR 会先检查该表是否存在：
- 若存在，读取进度信息，跳过已完成部分，继续处理剩余数据。
- 若不存在（如首次恢复、或上次恢复已清理），则从头开始恢复。
3. 使用方法
断点续传无需显式开启，只需在操作中断后，使用相同的命令参数重新执行备份或恢复命令即可。BR 会自动检测已完成的进度并从断点继续。
测试，我们drop table fund 后继续执行上一次的br restore 命令，提示"Full Restore success summary"，同时因异常产生的保存断点信息的库消失
MySQL [pingcap]> drop table fund;
Query OK, 0 rows affected (0.40 sec)
MySQL [pingcap]> exit
Bye
[tidb@tidb01 pingcap]$
[tidb@tidb01 pingcap]$ tiup br restore full --pd "192.168.2.73:2379" --filter 'pingcap.*' --ratelimit 128 -s "local:///tidb/backup/pingcap" --log-file /tidb/backup/pingcap/restore_pingcap_1023.log
Starting component br: /home/tidb/.tiup/components/br/v8.5.2/br restore full --pd 192.168.2.73:2379 --filter pingcap.* --ratelimit 128 -s local:///tidb/backup/pingcap --log-file /tidb/backup/pingcap/restore_pingcap_1023.log
Detail BR log in /tidb/backup/pingcap/restore_pingcap_1023.log
Full Restore <-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%
[2025/10/23 15:53:09.706 +08:00] [INFO] [collector.go:77] ["Full Restore success summary"] [total-ranges=27] [ranges-succeed=27] [ranges-failed=0] [restore-ranges=14] [total-take=6.474246733s] [BackupTS=461688651129028609] [RestoreTS=461689582670839832] [total-kv=491] [skipped-kv-count-by-checkpoint=487] [total-kv-size=7.363MB] [average-speed=1.137MB/s] [skipped-kv-size-by-checkpoint=7.363MB] [restore-data-size(after-compressed)=1.61MB] [Size=1609744]
[tidb@tidb01 pingcap]$
Your MySQL connection id is 1189104598
Server version: 8.0.11-TiDB-v8.5.2 TiDB Server (Apache License 2.0) Enterprise Edition, MySQL 8.0 compatible
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MySQL [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| INFORMATION_SCHEMA |
| METRICS_SCHEMA |
| PERFORMANCE_SCHEMA |
| mysql |
| pingcap |
| sys |
| test |
+--------------------+
7 rows in set (0.00 sec)
MySQL [(none)]>
通过断点续传，BR 工具能有效应对备份 / 恢复过程中的意外中断，减少重复操作的时间成本，尤其适合大规模数据场景。