【赵渝强老师】TiDB的备份恢复策略

数据库在运行过程中会出现各种故障，因此对数据库进行必要的备份是非常重要的。有了数据库的备份就可以在数据库出现错误时保证数据的安全。因此TiDB数据库提供了强大的数据库备份与恢复机制。

基于Raft协议和合理的部署拓扑规划，TiDB实现了集群的高可用，当集群中少数节点挂掉时，集群依然能对外提供服务。在此基础上，为了更进一步保证用户数据的安全，TiDB还提供了集群的备份与恢复(Backup & Restore,BR)功能，作为数据安全的最后一道防线，使得集群能够免于严重的自然灾害，提供业务误操作"复原"的能力。

TiDB备份恢复功能可以用于满足以下业务的需求：

备份集群数据到灾备系统，并保证Recovery Point Objective(RPO)低至5分钟，减少灾难场景下数据的丢失。
处理业务数据写错的案例，提供业务操作的"复原"能力。
审计业务的历史数据，满足司法审查的需求。
复制(Clone)生产环境，方便问题诊断、性能调优验证、仿真测试等。

TiDB支持四种备份恢复策略，分别是：全量（快照）备份与恢复、日志备份与恢复、数据的逻辑导出和导入和闪回。下面分别进行介绍。

视频讲解如下
【赵渝强老师】TiDB的备份恢复策略

一、全量（快照）备份与恢复

全量备份是对集群某个时间点的全量数据进行备份，TiDB的全量备份也可以叫做快照备份。因为TiDB集群快照数据包含某个物理时间点上集群满足事务一致性的所有数据。

全量备份一般会占用较大的存储空间，且只包含某个时间点的集群数据。执行tiup br backup full命令，可以备份TiDB最新的或者指定时间点的快照数据。执行tiup br backup full --help可获取该命令的使用帮助。下面的步骤将对数据库集群进行全量备份。

（1）创建一个目录用于保存集群快照备份产生的文件

powershell 复制代码

mkdir -p /backup/snapshot/full
chown -R tidb:tidb /backup/snapshot/full

（2）执行备份集群快照

powershell 复制代码

tiup br backup full \
    --pd "192.168.79.10:2379" \
    --storage "local:///backup/snapshot/full" \
    --log-file /backup/snapshot/full/backupfull.log
	
# 输出的信息如下：
Starting component br: 
         /root/.tiup/components/br/v8.5.1/br backup full \
		 --pd 192.168.79.10:2379 \
		 --storage local:///backup/snapshot/full \
		 --log-file /backup/snapshot/full/backupfull.log
Detail BR log in /backup/snapshot/full/backupfull.log 
Full Backup <-------------------------------> 100.00%
Checksum <----------------------------------> 100.00%

（3）查看产生的快照备份文件。

powershell 复制代码

tree /backup/snapshot/full/

# 输出的信息如下：
/backup/snapshot/full/
├── 5
│   ├── ......
│   ├── 32_235_e4f50bb7685_1739865447022_write.sst
│   ├── 32_235_e5f8771bee7_1739865446968_write.sst
│   ├── 32_235_ea38515343d_1739865446917_write.sst
│   ├── 32_235_ed85b58a2c9_1739865447042_default.sst
│   ├── 32_235_ed85b58a2c9_1739865447042_write.sst
│   ├── 32_235_f0f9b1a4aa3_1739865446926_write.sst
│   ├── 32_235_f4dd8b9e556_1739865446922_write.sst
│   ├── 32_235_f70c98a950f_1739865446864_write.sst
│   ├── 32_235_fd54db249c0_1739865446984_write.sst
│   ├── ......
│   └── 32_235_fe4f4fe208b_1739865446841_write.sst
├── backupfull.log
├── backup.lock
├── backupmeta
├── backupmeta.datafile.000000001
├── backupmeta.json
├── backupmeta.schema.000000002
└── checkpoints
    └── backup

快照备份会产生如下类型文件：

SST文件：存储TiKV备份下来的数据信息。单个SST文件大小等于TiKV Region的大小。SST是Static Sorted Table的缩写。
Backup meta文件：存储本次备份的元信息，包括备份文件数、备份文件的Key区间、备份文件大小和备份文件Hash(sha256)值。
backup.lock文件：用于防止多次备份到同一目录。

当备份数据到本地磁盘上时，SST文件以下面的格式命名。其中

regionID：Region编号
regionEpoch：Region版本号
keyHash：Range startKey的Hash(sha256)值，以确保唯一性
timestamp：TiKV节点生成SST文件名时刻的Unix时间戳
cf：RocksDB的列族信息，取值：default或者write

完整的SST文件名格式如下：

powershell 复制代码

<regionID>_<regionEpoch>_<keyHash>_<timestamp>_<cf>.sst

二、日志备份与恢复

全量备份一般会占用较大的存储空间，且只包含某个时间点的集群数据。如果需要灵活地选择恢复的时间点（即：实现PITR，Point in Time Recovery），可以使用日志备份和日志恢复。有了日志备份后，通过tiup br restore point功能，可以指定要恢复的时间点。BR会自动判断和读取恢复需要的数据，然后将这些数据依次恢复到指定的集群。执行tiup br log命令来开启和管理日志备份任务，下面展示了该命令的帮助信息：

powershell 复制代码

# tiup br log --help

Usage:
  br log [command]

Available Commands:
  metadata    查询备份存储中备份数据的元信息
  pause       暂停日志备份任务
  resume      重启暂停的备份任务
  start       启动一个日志备份任务
  status      查询日志备份任务状态
  stop        停止备份任务
  truncate    从备份存储中清理日志备份数据

执行tiup br log start命令可以在备份集群启动一个日志备份任务。该任务在TiDB集群持续地运行，及时地将KV变更日志保存到备份存储中。执行tiup br log start --help命令可获取该子命令使用介绍：

powershell 复制代码

# tiup br log start --help

start a log backup task

Usage:
  br log start [flags]

Flags:
  -h, --help               展示帮助信息
      --start-ts string   指定开始备份日志的起始时间点。
如果未指定，则选取当前时间作为start-ts
      --task-name string  指定日志备份任务名。
该名称也用于查询备份状态、暂停、重启
和恢复备份任务等操作

Global Flags:
  -u, --pd strings        指定备份集群的PD访问地址。
  -s, --storage string   指定备份存储地址。
  ......

下面的步骤将启动一个日志备份任务。

（1）创建一个目录用于保存日志备份产生的文件

powershell 复制代码

mkdir -p /backup/log
chown -R tidb:tidb /backup/log

（2）启动日志备份任务

powershell 复制代码

tiup br log start \
  --task-name=pitr \
  --pd="192.168.79.10:2379" \
  --storage='local:///backup/log'

# 输出的信息如下：
Starting component br: 
  br log start --task-name=pitr \
               --pd=192.168.79.10:2379 \
	           --storage=local:///backup/log
Detail BR log in /tmp/br.log.2025-02-18T18.04.50+0800 
[2025/02/18 18:04:50.647 +08:00] [INFO] ["log start success summary"]

（3）查看目录/backup/log

powershell 复制代码

tree /backup/log

# 输出的信息如下：
/backup/log
├── backup.lock
└── backupmeta

（4）查看日志备份任务的状态信息。

powershell 复制代码

tiup br log status --task-name=pitr --pd="192.168.79.10:2379"

# 输出的信息如下：
● Total 1 Tasks.
> #1 <
              name: pitr
            status: ● NORMAL
             start: 2025-02-18 18:04:50.561 +0800
               end: 2090-11-18 22:07:45.624 +0800
           storage: local:///backup/log
       speed(est.): 0.00 ops/s
checkpoint[global]: 2025-02-18 18:07:18.411 +0800; gap=47s

命令输出中的字段含义如下：
● status：任务状态，包括NORMAL（正常）、ERROR（异常）和PAUSE（暂停）三种状态。
● start：日志备份任务开始的时间，该值为备份任务启动时候指定的start-ts。
● storage：备份存储。
● speed：日志备份任务的总QPS（每秒备份的日志个数）。
● checkpoint[global]：集群中早于该checkpoint的数据都已经保存到备份存储，它也是备份数据可恢复的最近时间点。

（5）再次查看目录/backup/log

powershell 复制代码

tree /backup/log

# 输出的信息如下：
/backup/log
├── backup.lock
├── backupmeta
└── v1
    ├── 20250218
    │   └── 10
    │       └── 1
    │           ├── 456097302173712388-2dd0ae7b-e8c7-4656-a497-e0e02d0e4fe4.log
    │           └── 456097333619195905-7bd1f194-ba97-4824-94e9-45f223382d82.log
    ├── backupmeta
    │   ├── 456097317141872643-0af28b08-6cc4-4123-af8a-f8798e967378.meta
    │   └── 456097332870512641-ce854c81-95ab-444e-91fd-e9e9fb8d2e58.meta
    └── global_checkpoint
        ├── 1.ts
        ├── 4.ts
        └── 5.ts

6 directories, 9 files

日志备份会产生如下类型文件：

{min_ts}-{uuid}.log文件：存储备份下来的kv数据变更记录。其中{min_ts}是该文件中所有kv数据变更记录数对应的最小ts；{uuid}是生成该文件的时候随机生成的。
{checkpoint_ts}-{uuid}.meta文件：每个TiKV节点每次上传日志备份数据时会生成一个该文件，保存本次上传的所有日志备份数据文件。其中{checkpoint_ts}是本节点的日志备份的checkpoint，所有TiKV节点的最小的checkpoint就是日志备份任务最新的checkpoint；{uuid}是生成该文件的时候随机生成的。
{store_id}.ts文件：每个TiKV节点每次上传日志备份数据时会使用global checkpoint ts更新该文件。其中{store_id}是TiKV的storeID。
v1_stream_truncate_safepoint.txt文件：保存最近一次通过br log truncate删除日志备份数据后，存储中最早的日志备份数据对应的ts。

三、数据的逻辑导出和导入

在备份与恢复场景中，如果需要全量备份少量数据且不要求备份速度，还可以使用Dumpling从TiDB数据库导出数据进行备份，再使用TiDB Lightning将数据导入至TiDB数据库实现恢复。

Dumpling和TiDB Lightning属于逻辑备份与逻辑恢复，因此适用于数据量较小的情况，例如小于50G的数据。

数据导出工具Dumpling可以把存储在TiDB或MySQL中的数据导出为SQL或CSV格式，用于逻辑全量备份。Dumpling也支持将数据导出到Amazon S3中。

TiDB Lightning是用于从静态文件导入TB级数据到TiDB集群的工具，常用于TiDB集群的初始化数据导入。TiDB Lightning 支持的文件类型有：Dumpling生成的文件、CSV文件和Parquet文件

四、 TiDB的闪回

TiDB修改数据时并不会将旧版本数据之间删除，而是在新旧数据上打上不同的版本号，从而实现了MVCC基准。当旧版本数据满足了GC垃圾回收的触发条件时，TiDB才会将旧版本数据彻底删除。换句话说，在GC垃圾回收旧版本数据之前，任然可以读取旧版本数据从而达到恢复的目的。这就是闪回的核心机制，它是一种轻量级的恢复技术，不需要备份即可完成。通过查询系统变量tidb_gc_life_time可以获取旧版本数据保留的时间，默认10分钟。

sql 复制代码

tidb> select @@tidb_gc_life_time ;
+---------------------+
| @@tidb_gc_life_time |
+---------------------+
| 10m0s               |
+---------------------+

下面的查询语句将查询当前的安全点（safePoint），即GC已经清理到的时间点。换句话说，该时间点以后的数据都可以恢复。

sql 复制代码

tidb> select * from mysql.tidb where variable_name = 'tikv_gc_safe_point' \G;
*************************** 1. row ***************************
 VARIABLE_NAME: tikv_gc_safe_point
VARIABLE_VALUE: 20250307-21:50:44.781 +0800
       COMMENT: All versions after safe point can be accessed. (DO NOT EDIT)
1 row in set (0.01 sec)

TiDB中支持闪回集群、闪回数据库和闪回表三种不同的闪回。

【赵渝强老师】TiDB的备份恢复策略

一、 全量（快照）备份与恢复

二、 日志备份与恢复

三、 数据的逻辑导出和导入

四、 TiDB的闪回

一、全量（快照）备份与恢复

二、日志备份与恢复

三、数据的逻辑导出和导入