概述

全量备份包含集群某个时间点的全量数据，但是不包含其他时间点的更新数据，而 TiDB 日志备份能够将业务写入 TiDB 的数据记录及时备份到指定存储中。如果你需要灵活的选择恢复的时间点，即实现 Point-in-time recovery (PITR)，可以开启日志备份，并定期执行快照（全量）备份。

开启日志备份

执行 tiup br log start 命令启动日志备份任务，一个集群只能启动一个日志备份任务。

tiup br log start --task-name=pitr --pd "${PD_IP}:2379" \
--storage 's3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}'

我们在测试环境执行：

cd /home/tidb/.tiup/bin
tiup br log start --task-name=pitr_test1   --pd "10.0.8.88:2379" --storage "/backup/tidb_backup/2024_1021_log" 

日志备份任务启动后，会在 TiDB 集群后台持续地运行，直到你手动将其暂停。
在这过程中，TiDB 变更数据将以小批量的形式定期备份到指定存储中。
如果需要查询日志备份任务当前状态，执行如下命令：

tiup br log status --task-name=pitr_test1 --pd "10.0.8.88:2379"

输出结果如下：

Starting component br: /home/tidb/.tiup/components/br/v8.1.1/br log status --task-name=pitr_test1 --pd 10.0.8.88:2379
Detail BR log in /tmp/br.log.2024-10-21T17.55.26+0800
● Total 1 Tasks.
> #1 <
              name: pitr_test1
            status: ● NORMAL
             start: 2024-10-21 17:53:16.74 +0800
               end: 2090-11-18 22:07:45.624 +0800
           storage: local:///backup/tidb_backup/2024_1021_log
       speed(est.): 0.00 ops/s
checkpoint[global]: 2024-10-21 17:53:16.74 +0800; gap=2m11s

停止任务：

tiup br log stop --task-name=pitr_test1 

进行 PITR

想恢复到备份保留期内的任意时间点，可以使用 tiup br restore point 命令。
要指定要恢复的时间点、恢复时间点之前最近的快照备份以及日志备份数据。
br 命令行工具会自动判断和读取恢复需要的数据，然后将这些数据依次恢复到指定的集群。
命令参考：

tiup br restore point --pd "${PD_IP}:2379" \
--storage='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}' \
--full-backup-storage='s3://backup-101/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}' \
--restored-ts '2022-05-15 18:00:00+0800'

注：

• PITR 仅支持恢复到全新的空集群。
• PITR 仅支持集群粒度的恢复，不支持对单个 database 或 table 的恢复。
• PITR 不支持恢复系统表中用户表和权限表的数据。
• PITR 数据恢复任务运行期间，不支持同时运行日志备份任务，也不支持通过 TiCDC 同步数据到下游集群。

我们先重新开启一个日志备份任务，然后执行一次完整快照备份：

tiup br log start --task-name=pitr_test2   --pd "10.0.8.88:2379" --storage "/backup/tidb_backup/2024_1022_log"
tiup br  backup full --pd "10.0.8.88:2379" --storage "/backup/tidb_backup/2024_1022"    --ratelimit 128

对测试库进行一系列操作，然后停止log备份任务后，进行PITR不完全恢复：

cd .tiup/bin/
tiup br log stop --task-name=pitr_test2
tiup br restore point --pd "10.0.8.88:2379" --storage='/backup/tidb_backup/2024_1022_log' --full-backup-storage='/backup/tidb_backup/2024_1022' --restored-ts '2024-10-22 13:50:00.00 +0800'

正常情况下会打印类似如下内容：

Full Restore <---------------------------------------------------------------------------------------------------------------------------------------> 100.00%
[2024/10/22 13:56:21.351 +08:00] [INFO] [collector.go:77] ["Full Restore success summary"] [total-ranges=6] [ranges-succeed=6] [ranges-failed=0] [split-region=381.419µs] [restore-ranges=4] [total-take=8.302965218s] [BackupTS=453397986787983370] [RestoreTS=453398122171990017] [total-kv=4] [total-kv-size=176B] [average-speed=21.2B/s] [restore-data-size(after-compressed)=6.576kB] [Size=6576]
Restore Meta Files <---------------------------------------------------------------------------------------------------------------------------------> 100.00%
Restore KV Files <-----------------------------------------------------------------------------------------------------------------------------------> 100.00%
[2024/10/22 13:56:24.974 +08:00] [INFO] [collector.go:77] ["restore log success summary"] [total-take=3.622599251s] [restore-from=453397986787983370] [restore-to=453398023372800000] [restore-from="2024-10-22 13:47:40.44 +0800"] [restore-to="2024-10-22 13:50:00 +0800"] [total-kv-count=6] [skipped-kv-count-by-checkpoint=0] [total-size=6.067kB] [skipped-size-by-checkpoint=0B] [average-speed=1.675kB/s]

报错汇总

• PITR仅支持恢复到全新的空集群，如果是测试环境本集群恢复，则不删这些备份的库的话就无法进行PITR：

Error: databases lightning_task_info,test_collation,test_restore,pingcap_test01,dm_meta existed in restored cluster, please drop them before execute PiTR: [BR:Restore:ErrDatabasesAlreadyExisted]databases already existed in restored cluster

• PITR数据恢复任务运行期间，不支持同时运行日志备份任务，如果不停止log备份任务就进行PITR则会报错：

Error: failed to check task exists: log backup task is running: pitr_test2, please stop the task before restore, and after PITR operation finished, create log-backup task again and create a full backup on this cluster

• 如果全备和日志备份不连续则会报错：

Error: it has gap between full backup ts:453377312893173767(2024-10-21 15:53:15.79 +0800 CST) and log backup ts:453379200579010562(2024-10-21 17:53:16.74 +0800 CST). : [BR:Common:ErrInvalidArgument]invalid argument

因此一般备份策略是日志备份会持续不断的运行，结合定期的快照备份进行恢复。

• 此报错有可能是还原时间点问题，因为日志备份是批量执行的，还原的时间点在日志备份的checkpoint之后就无法还原：

Error: restore log from 453400246731145222(2024-10-22 16:11:21.439 +0800 CST) to 453400260771840000(2024-10-22 16:12:15 +0800 CST),  but the current existed log from 453400238958575619(2024-10-22 16:10:51.789 +0800 CST) to 453400238958575619(2024-10-22 16:10:51.789 +0800 CST): [BR:Common:ErrInvalidArgument]invalid argument

日志备份维护

进行 PITR 不仅需要恢复时间点之前的全量备份，还需要全量备份和恢复时间点之间的日志备份，因此，对于超过备份保留期的日志备份，应执行 tiup br log truncate 命令删除指定时间点之前的备份。
建议只清理全量快照之前的日志备份。

按照以下步骤清理超过备份保留期的备份数据：
查找备份保留期之外的最近一次全量备份。
使用 validate 指令获取该备份对应的时间点。假如需要清理 2022/09/01 之前的备份数据，则应查找该日期之前的最近一次全量备份，且保证它不会被清理。
FULL_BACKUP_TS为：

tiup br validate decode --field="end-version" --storage "s3://backup-101/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}"| tail -n1

清理该快照备份 FULL_BACKUP_TS 之前的日志备份数据。

tiup br log truncate --until=${FULL_BACKUP_TS} --storage='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}'

我们这里命令是：

tiup br log truncate --until=453397986787983370 --storage='/backup/tidb_backup/2024_1022_log'

打印结果是：

Starting component br: /home/tidb/.tiup/components/br/v8.1.1/br log truncate --until=453397986787983370 --storage=/backup/tidb_backup/2024_1022_log
Detail BR log in /tmp/br.log.2024-10-22T14.22.16+0800
Reading Metadata... DONE { take = 1ms }
We are going to remove 2 files, until 2024-10-22 13:47:40.4400.
Sure? (y/N) y
Clearing Data Files and Metadata  ::  DONE { take = 2ms, kv-count = 107, kv-size = 8361(8.361kB) }