TiDB 备份与恢复整理

前言

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

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

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

TiDB 备份恢复功能包含了多种不同类型的集群数据对象的备份与恢复实现。这些功能都以 Backup & Restore (BR) 和 TiDB Operator 为使用入口，创建相应的任务从 TiKV 节点上备份数据，或者恢复数据到 TiKV 节点。

备份方案

如何备份数据？

TiDB 支持两种类型的备份，应该使用哪种备份？ 全量备份包含集群某个时间点的全量数据，日志备份包含业务写入在 TiDB 产生的数据变更记录。推荐这两种备份方式一起使用：

• 开启日志备份：运行 br log start 命令来启动日志备份任务，任务会在每个 TiKV 节点上持续运行，以小批量的形式定期将 TiDB 变更数据备份到指定存储中。
• 定期执行快照（全量）备份：运行 br backup full 命令来备份集群快照到备份存储，例如在每天零点进行集群快照备份。

如何管理备份数据？

BR 只提供备份和恢复的基础功能，尚不支持备份管理的功能，因此你需要自行规划备份数据的管理事项，可能包含以下的问题：

• 选择哪种备份存储系统？
• 数据备份的时候，备份数据应该放在什么目录下？
• 全量备份和日志备份的数据目录如何组织？
• 如何处理存储系统中历史备份数据？

如何选择备份存储？

Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 是推荐的存储系统选择，使用这些系统，你无需担心备份容量、备份带宽规划等。

如果 TiDB 集群部署在自建机房中，则推荐以下方式：

• 搭建 MinIO 作为备份存储系统，使用 S3 协议将数据备份到 MinIO 中。
• 挂载 NFS（如 NAS）盘到 br 工具和所有的 TiKV 实例，使用 POSIX file system 接口将备份数据写入对应的 NFS 目录中。

组织备份数据目录：

• 全量备份和日志备份保存在相同的目录下，方便统一管理，例如 backup-${cluster-id}。
• 每个全量备份保存到命名带有备份日期的目录下，例如 backup-${cluster-id}/fullbackup-202209081330。
• 日志备份数据保存在一个固定目录下，例如 backup-${cluster-id}/logbackup。日志备份程序会在 logbackup 目录中每天切分出来一个新的子目录来区分每天的日志备份数据。

处理历史备份数据：假设你设置了备份保留期，即保存固定时间的备份数据，比如 7 天。请注意备份保留期的概念。

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

如何恢复数据？

如果你只有全量备份数据，或者想恢复某个确定的全量备份，那么可以使用 br restore 恢复指定的全量备份。如果你按照以上推荐的的方式进行备份，那么你可以使用 br restore point 恢复到备份保留期内任意时间点。

TiDB 快照备份

快照备份是集群全量备份的一种实现。它基于 TiDB 的多版本并发控制 (MVCC) 实现，将指定快照包含的所有数据备份到目标存储中。备份下来的数据大小约等于集群（压缩后的）单副本数据大小。备份完成之后，你可以在一个空集群或不存在数据冲突（相同 schema 或 table）的集群执行快照备份恢复，将集群恢复到快照备份时的数据状态，同时恢复功能会依据集群副本设置恢复出多副本。

快照数据备份和恢复的架构如下：

备份流程

集群快照数据备份的流程如下：

完整的备份交互流程描述如下：

1. BR 接收备份命令 br backup full。

   • 获得备份快照点 (backup ts) 和备份存储地址。

2. BR 调度备份数据。

   • Pause GC：配置 TiDB GC，防止要备份的数据被 TiDB GC 机制回收。
   • Fetch TiKV and Region info：访问 PD，获取所有 TiKV 节点访问地址以及数据的 Region 分布信息。
   • Request TiKV to back up data：创建备份请求，发送给 TiKV 节点，备份请求包含 backup ts、需要备份的 region、备份存储地址。

3. TiKV 接受备份请求，初始化 backup worker。

4. TiKV 备份数据。

   • Scan KVs：backup worker 从 Region (only leader) 读取 backup ts 对应的数据。
   • Generate SST：backup worker 将读取到的数据保存到 SST 文件，存储在内存中。
   • Upload SST：backup worker 上传 SST 文件到备份存储中。

5. BR 从各个 TiKV 获取备份结果。

   • 如果局部数据因为 Region 变动而备份失败，比如 TiKV 节点故障，BR 将重试这些数据的备份。
   • 如果任意数据被判断为不可重试的备份失败，则备份任务失败。
   • 部数据备份成功后，则在最后完成元信息备份。

6. BR 备份元信息。

   • Back up schemas：备份 table schema，同时计算 table data checksum。
   • Upload metadata：生成 backup metadata，并上传到备份存储。backup metadata 包含 backup ts、表和对应的备份文件、data checksum 和 file checksum 等信息。

恢复流程

恢复集群快照备份数据的流程如下：

完整的恢复交互流程描述如下：

1. BR 接收恢复命令 br restore。

   • 获得快照备份数据存储地址、要恢复的 database 或 table。
   • 检查要恢复的 table 是否存在及是否符合要求。

2. BR 调度恢复数据。

   • Pause Region schedule：请求 PD 在恢复期间关闭自动 Region schedule。
   • 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 规则。

3. TiKV 接受恢复请求，初始化 restore worker。

   • restore worker 计算恢复数据需要读取的备份数据。

4. TiKV 恢复数据。

   • Download SST：restore worker 从备份存储中下载相应的备份数据到本地。
   • Rewrite KVs：restore worker 根据新建表 table ID，对备份数据 kv 进行重写，即将原有的 kv 编码中的 table ID 替换为新创建的 table ID。对 index ID，restore worker 也进行相同处理。
   • Ingest SST：restore worker 将处理好的 SST 文件 ingest 到 RocksDB 中。
   • Report restore result：restore worker 返回恢复结果给 BR。

5. BR 从各个 TiKV 获取恢复结果。

   • 如果局部数据恢复因为 RegionNotFound 或 EpochNotMatch 等原因失败，比如 TiKV 节点故障，BR 重试恢复这些数据。
   • 如果存在备份数据不可重试的恢复失败，则恢复任务失败。
   • 全部备份都恢复成功后，则整个恢复任务成功。

备份文件

文件类型

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

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

备份文件目录结构

将数据备份到 Google Cloud Storage 或 Azure Blob Storage 上时，SST 文件、backupmeta 文件和 backup.lock 文件在同一目录下。目录结构如下：

.
└── 20220621├── backupmeta|—— backup.lock├── {storeID}-{regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst├── {storeID}-{regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst└── {storeID}-{regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst

将数据备份到 Amazon S3 或网络盘上时，SST 文件会根据 storeID 划分子目录。目录结构如下：

.
└── 20220621├── backupmeta|—— backup.lock├── store1│   └── {regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst├── store100│   └── {regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst├── store2│   └── {regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst├── store3├── store4└── store5

日志备份

日志备份和 PITR 的架构如下：

日志备份的流程如下：

系统组件和关键概念：

• 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。
• TiKV log observer 组件：运行在 TiDB 集群的每个 TiKV 节点，负责从 TiKV 读取和备份日志数据。TiKV 节点故障的话，该节点负责备份数据范围，在 Region 重新选举后，会被其他 TiKV 节点负责，这些节点会从 global checkpoint ts 重新备份故障范围的数据。

完整的备份交互流程描述如下：

1. BR 接收备份命令 br log start。

   • 解析获取日志备份任务的 checkpoint ts（日志备份起始位置）、备份存储地址。
   • Register log backup task：在 PD 注册日志备份任务 (log backup task)。

2. TiKV 监控日志备份任务的创建与更新。

   • Fetch log backup task：每个 TiKV 节点的 log backup observer 监听 PD 中日志备份任务的创建与更新，然后备份该节点上在备份范围内的数据。

3. TiKV log backup observer 持续地备份 KV 变更日志。

   • Read kv change data：读取 kv 数据变更，然后保存到自定义格式的备份文件中。
   • Fetch global checkpoint ts：定期从 PD 查询 global checkpoint ts。
   • Generate local metadata：定期生成 local metadata（包含 local checkpoint ts、global checkpoint ts、备份文件信息）。
   • Upload log data & metadata：定期将日志备份数据和 local metadata 上传到备份存储中。
   • Configure GC：请求 PD 阻止未备份的数据（大于 local checkpoint ts）被 TiDB GC 机制回收掉。

4. TiDB Coordinator 监控日志备份进度。

   • Watch backup progress：轮询所有 TiKV 节点，获取各个 Region 的备份进度 (Region checkpoint ts)。
   • Report global checkpoint ts：根据各个 Region checkpoint ts，计算整个日志备份任务的进度 (global checkpoint ts)，然后上报给 PD。

5. PD 持久化日志备份任务状态。可以通过 br log status 查询。

PITR

PITR 的流程如下：

完整的 PITR 交互流程描述如下：

1. BR 接收恢复命令 br restore point。

   • 解析获取全量备份数据地址、日志备份数据地址、恢复到的时间点。
   • 查询备份数据中恢复数据对象（database 或 table），并检查要恢复的表是否存在并符合要求。

2. BR 恢复全量备份。

   • 进行快照备份数据恢复，恢复流程参考恢复快照备份数据。

3. BR 恢复日志备份。

   • Read backup data：读取日志备份数据，计算需要恢复的日志备份数据。
   • Fetch Region info：访问 PD，获取所有 Region 和 KV range 的对应关系。
   • Request TiKV to restore data：创建日志恢复请求，发送到对应的 TiKV，日志恢复请求包含要恢复的日志备份数据信息。

4. TiKV 接受 BR 的恢复请求，初始化 log restore worker。

   • log restore worker 获取需要恢复的日志备份数据。

5. TiKV 恢复日志备份数据。

   • Download KVs：log restore worker 根据日志恢复请求中要恢复的备份数据，从备份存储中下载相应的备份数据到本地。
   • Rewrite KVs：log restore worker 根据恢复集群表的 table ID 对备份数据的 kv 进行重写 —— 将原有的 kv 编码中的 table ID 替换为新创建的 table ID。对 index ID，log restore worker 也进行相同的处理。
   • Apply KVs：log restore worker 将处理好的 kv 通过 raft 接口写入 store (RocksDB) 中。
   • Report restore result：log restore worker 返回恢复结果给 BR。

6. BR 从各个 TiKV 获取恢复结果。

   • 如果局部数据恢复因为 RegionNotFound 或 EpochNotMatch 等原因失败，比如 TiKV 节点故障，BR 重试恢复这些数据。
   • 如果存在备份数据不可重试的恢复失败，则恢复任务失败。
   • 全部备份数据都恢复成功后，则恢复任务成功。

日志备份文件

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

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

备份文件目录结构：

.
├── v1
│   ├── backupmeta
│   │   ├── ...
│   │   └── {resolved_ts}-{uuid}.meta
│   ├── global_checkpoint
│   │   └── {store_id}.ts
│   └── {date}
│       └── {hour}
│           └── {store_id}
│               ├── ...
│               └── {min_ts}-{uuid}.log
└── v1_stream_truncate_safepoint.txt

备份文件目录结构的说明如下：

• backupmeta：备份的元数据。文件名中的 resolved_ts 指备份的进度，表示该 TSO 之前的数据已被完整备份。但是需注意，该 TSO 仅反映部分分片的进度。
• global_checkpoint：备份的全局进度。它记录了可以被 br restore point 恢复到的最晚时间点。
• {date}/{hour}：对应日期和小时的备份数据。注意在清理存储的时候，需使用 br log truncate，不能手动删除数据。这是因为 metadata 会指向这里的数据，手动删除它们会导致恢复失败或恢复后数据不一致等问题。

具体示例如下：

├── v1
│   ├── backupmeta
│   │   ├── ...
│   │   ├── 435213818858112001-e2569bda-a75a-4411-88de-f469b49d6256.meta
│   │   ├── 435214043785779202-1780f291-3b8a-455e-a31d-8a1302c43ead.meta
│   │   └── 435214443785779202-224f1408-fff5-445f-8e41-ca4fcfbd2a67.meta
│   ├── global_checkpoint
│   │   ├── 1.ts
│   │   ├── 2.ts
│   │   └── 3.ts
│   └── 20220811
│       └── 03
│           ├── 1
│           │   ├── ...
│           │   ├── 435213866703257604-60fcbdb6-8f55-4098-b3e7-2ce604dafe54.log
│           │   └── 435214023989657606-72ce65ff-1fa8-4705-9fd9-cb4a1e803a56.log
│           ├── 2
│           │   ├── ...
│           │   ├── 435214102632857605-11deba64-beff-4414-bc9c-7a161b6fb22c.log
│           │   └── 435214417205657604-e6980303-cbaa-4629-a863-1e745d7b8aed.log
│           └── 3
│               ├── ...
│               ├── 435214495848857605-7bf65e92-8c43-427e-b81e-f0050bd40be0.log
│               └── 435214574492057604-80d3b15e-3d9f-4b0c-b133-87ed3f6b2697.log
└── v1_stream_truncate_safepoint.txt

部署和使用 BR

使用备份恢复功能的部署要求如下：

• BR、TiKV 节点和备份存储系统需要提供大于备份速度的的网络带宽。当集群特别大的时候，备份和恢复速度上限受限于备份网络的带宽。
• 备份存储系统还需要提供足够的写入/读取性能 (IOPS)，否则它有可能成为备份恢复时的性能瓶颈。
• TiKV 节点需要为备份准备至少额外的两个 CPU core 和高性能的磁盘，否则备份将对集群上运行的业务产生影响。
• 推荐 br 工具运行在 8 核+/16 GB+ 的节点上。

目前支持以下几种方式来使用 BR。

通过命令行工具（推荐）

TiDB 支持使用 br 工具进行备份恢复。

• 安装方法可以使用 TiUP 在线安装：tiup install br。

了解如何使用 br 命令行工具进行备份与恢复，请参阅：

• TiDB 快照备份与恢复功能使用
• TiDB 日志备份与 PITR 功能使用
• TiDB 集群备份与恢复实践示例

通过 SQL 语句

TiDB 支持使用 SQL 语句进行全量快照备份和恢复：

• BACKUP 进行全量快照数据备份。
• RESTORE 进行快照备份恢复。
• SHOW BACKUPS|RESTORES 查看备份恢复的进度。

在 Kubernetes 环境下通过 TiDB Operator

在 Kubernetes 环境下，支持通过 TiDB Operator 支持以 S3、GCS、Azure blob storage 作为备份存储，并从这些存储系统中恢复备份数据。使用文档请参阅使用 TiDB Operator 进行备份恢复。

快照备份使用

对集群进行快照备份

使用 br backup full 可以进行一次快照备份：

## 该命令的详细使用帮助可以通过执行 `br backup full --help` 查看
## 采用 Amazon S3 Access key 和 Secret key 授权方式来进行模拟
tiup br backup full --pd "${PD_IP}:2379" \--backupts '2022-09-08 13:30:00 +08:00' \--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" \--ratelimit 128 \

以上命令中：

• --backupts：快照对应的物理时间点，格式可以是 TSO 或者时间戳，例如 400036290571534337 或者 2018-05-11 01:42:23 +08:00。如果该快照的数据被垃圾回收 (GC) 了，那么 tiup br backup 命令会报错并退出。使用日期方式备份时，建议同时指定时区，否则 br 默认使用本地时间构造时间戳，可能导致备份时间点错误。如果你没有指定该参数，那么 br 会选取备份开始的时间点所对应的快照。
• --storage：数据备份到的存储地址。快照备份支持以 Amazon S3、Google Cloud Storage、Azure Blob Storage 为备份存储，以上命令以 Amazon S3 为示例。详细存储地址格式请参考外部存储服务的 URI 格式。
• --ratelimit：每个 TiKV 备份数据的速度上限，单位为 MiB/s。

在快照备份过程中，终端会显示备份进度条。在备份完成后，会输出备份耗时、速度、备份数据大小等信息：

Full Backup <-------------------------------------------------------------------------------> 100.00%
Checksum <----------------------------------------------------------------------------------> 100.00%
*** ["Full Backup success summary"] *** [backup-checksum=3.597416ms] [backup-fast-checksum=2.36975ms] *** [total-take=4.715509333s] [BackupTS=435844546560000000] [total-kv=1131] [total-kv-size=250kB] [average-speed=53.02kB/s] [backup-data-size(after-compressed)=71.33kB] [Size=71330]

出于管理备份数的需要，如果你需要查看某个快照备份对应的快照物理时间点，可以执行下面的命令：

tiup br validate decode --field="end-version" \
--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" | tail -n1## 结果输出如下，对应物理时间 2022-09-08 13:30:00 +0800 CST
435844546560000000

恢复快照备份数据

如果你需要恢复备份的快照数据，则可以使用 br restore full。

将上文备份的快照数据恢复到目标集群：

## 该命令的详细使用帮助可以通过执行 br restore full --help 查看
tiup br restore full --pd "${PD_IP}:2379" \
--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"

在恢复快照备份数据过程中，终端会显示恢复进度条。在完成恢复后，会输出恢复耗时、速度、恢复数据大小等信息：

Full Restore <------------------------------------------------------------------------------> 100.00%
*** ["Full Restore success summary"] *** [total-take=4.344617542s] [total-kv=5] [total-kv-size=327B] [average-speed=75.27B/s] [restore-data-size(after-compressed)=4.813kB] [Size=4813] [BackupTS=435844901803917314]

恢复备份数据中指定库表的数据

br 命令行工具支持只恢复备份数据中指定库、表的部分数据，该功能用于在恢复过程中过滤不需要的数据。

恢复单个数据库的数据

要将备份数据中的某个数据库恢复到集群中，可以使用 br restore db 命令。以下示例只恢复 test 库的数据：

tiup br restore db --pd "${PD_IP}:2379" \
--db "test" \
--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"

以上命令中 --db 选项指定了需要恢复的数据库名。

恢复单张表的数据

要将备份数据中的某张数据表恢复到集群中，可以使用 br restore table 命令。以下示例只恢复 test.usertable 表的数据：

tiup br restore table --pd "${PD_IP}:2379" \
--db "test" \
--table "usertable" \
--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"

以上命令中 --db 选项指定了需要恢复的数据库名，--table 选项指定了需要恢复的表名。

使用表库过滤功能恢复部分数据

要通过复杂的过滤条件恢复多个表，可以使用 br restore full 命令，并用 --filter 或 -f 指定表库过滤的条件。以下示例恢复符合 db*.tbl* 条件的表的数据：

tiup br restore full --pd "${PD_IP}:2379" \
--filter 'db*.tbl*' \
--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"

恢复 mysql 数据库下的表

自 br v5.1.0 开始，快照备份会备份 mysql schema 下的系统表数据，而不会默认恢复这些数据。自 br v6.2.0 开始，在设置 --with-sys-table 下，恢复数据时将同时恢复部分系统表相关数据。

可恢复的部分系统表：

+----------------------------------+
| mysql.columns_priv               |
| mysql.db                         |
| mysql.default_roles              |
| mysql.global_grants              |
| mysql.global_priv                |
| mysql.role_edges                 |
| mysql.tables_priv                |
| mysql.user                       |
| mysql.bind_info                  |
+----------------------------------+

不能恢复以下系统表：

• 统计信息表 (mysql.stat_*) (但可以恢复统计信息，详细参考备份统计信息)
• 系统变量表 (mysql.tidb、mysql.global_variables)
• 其他系统表

+-----------------------------------------------------+
| capture_plan_baselines_blacklist                    |
| column_stats_usage                                  |
| gc_delete_range                                     |
| gc_delete_range_done                                |
| global_variables                                    |
| schema_index_usage                                  |
| stats_buckets                                       |
| stats_extended                                      |
| stats_feedback                                      |
| stats_fm_sketch                                     |
| stats_histograms                                    |
| stats_history                                       |
| stats_meta                                          |
| stats_meta_history                                  |
| stats_table_locked                                  |
| stats_top_n                                         |
| tidb                                                |
+-----------------------------------------------------+

当恢复系统权限相关数据的时候，请注意：在恢复数据前 BR 会检查目标集群的系统表是否跟备份数据中的系统表兼容。这里的兼容是指满足以下所有条件：

• 目标集群需要存在备份中的系统权限表。
• 目标集群系统权限表列数需要与备份数据中一致，列的顺序可以有差异。
• 目标集群系统权限表的列需要与备份数据兼容。如果为带长度类型（包括整型、字符串等类型），前者长度需大于或等于后者，如果为 ENUM 类型，则应该为后者超集。

性能与影响

快照备份的性能与影响

TiDB 备份功能对集群性能（事务延迟和 QPS）有一定的影响，但是可以通过调整备份的线程数 backup.num-threads，以及增加集群配置，来降低备份对集群性能的影响。

为了更加具体说明备份对集群的影响，下面列举了多次快照备份测试结论来说明影响的范围：

• （使用 5.3 及之前版本）在默认配置下，单 TiKV 存储节点上备份线程数量是节点 CPU 总数量的 75% 时，QPS 会下降到备份之前的 35% 左右。
• （使用 5.4 及以后版本）单 TiKV 存储节点上备份的线程数量不大于 8、集群总 CPU 利用率不超过 80% 时，备份任务对集群（无论读写负载）影响最大在 20% 左右。
• （使用 5.4 及以后版本）单 TiKV 存储节点上备份的线程数量不大于 8、集群总 CPU 利用率不超过 75% 时，备份任务对集群（无论读写负载）影响最大在 10% 左右。
• （使用 5.4 及以后版本）单 TiKV 存储节点上备份的线程数量不大于 8、集群总 CPU 利用率不超过 60% 时，备份任务对集群（无论读写负载）几乎没有影响。

你可以通过如下方案手动控制备份对集群性能带来的影响。但是，这两种方案在减少备份对集群的影响的同时，也会降低备份任务的速度。

• 使用 --ratelimit 参数对备份任务进行限速。请注意，这个参数限制的是把备份文件存储到外部存储的速度。计算备份文件的大小时，请以备份日志中的 backup data size(after compressed) 为准。设置 --ratelimit 后，为了避免任务数过多导致限速失效，br 的 concurrency 参数会自动调整为 1。
• 调节 TiKV 配置项 backup.num-threads，限制备份任务使用的工作线程数量。内部测试数据表明，当备份的线程数量不大于 8、集群总 CPU 利用率不超过 60% 时，备份任务对集群（无论读写负载）几乎没有影响。

通过限制备份的线程数量可以降低备份对集群性能的影响，但是这会影响到备份的性能，以上的多次备份测试结果显示，单 TiKV 存储节点上备份速度和备份线程数量呈正比。在线程数量较少的时候，备份速度约为 20 MiB/线程数。例如，单 TiKV 节点 5 个备份线程可达到 100 MiB/s 的备份速度。

快照恢复的性能与影响

TiDB 恢复的时候会尽可能打满 TiKV CPU、磁盘 IO、网络带宽等资源，所以推荐在空的集群上执行备份数据的恢复，避免对正在运行的业务产生影响。

备份数据的恢复速度与集群配置、部署、运行的业务都有比较大的关系。在内部多场景仿真测试中，单 TiKV 存储节点上备份数据恢复速度能够达到 100 MiB/s。在不同用户场景下，快照恢复的性能和影响应以实际测试结论为准。

日志备份使用

开启日志备份

执行 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}'

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

tiup br log status --task-name=pitr --pd "${PD_IP}:2379"

日志备份任务状态输出如下：

● Total 1 Tasks.
> #1 <name: pitrstatus: ● NORMALstart: 2022-05-13 11:09:40.7 +0800end: 2035-01-01 00:00:00 +0800storage: s3://backup-101/log-backupspeed(est.): 0.00 ops/s
checkpoint[global]: 2022-05-13 11:31:47.2 +0800; gap=4m53s

定期执行全量备份

快照备份功能可作为全量备份的方法，运行 br backup full 命令可以按照固定的周期（比如 2 天）进行全量备份。

tiup br backup full --pd "${PD_IP}:2379" \
--storage 's3://backup-101/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}'

进行 PITR

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

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'

恢复期间，可通过终端中的进度条查看进度，如下。恢复分为两个阶段：全量恢复 (Full Restore) 和日志恢复（Restore Meta Files 和 Restore KV Files）。每个阶段完成恢复后，br 命令行工具都会输出恢复耗时和恢复数据大小等信息。

Full Restore <--------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%
*** ["Full Restore success summary"] ****** [total-take=xxx.xxxs] [restore-data-size(after-compressed)=xxx.xxx] [Size=xxxx] [BackupTS={TS}] [total-kv=xxx] [total-kv-size=xxx] [average-speed=xxx]
Restore Meta Files <--------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%
Restore KV Files <----------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%
*** ["restore log success summary"] [total-take=xxx.xx] [restore-from={TS}] [restore-to={TS}] [total-kv-count=xxx] [total-size=xxx]

清理过期的日志备份数据

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

你可以按照以下步骤清理超过备份保留期的备份数据：

1. 查找备份保留期之外的最近一次全量备份。
2. 使用 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`
   

3. 清理该快照备份 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}'
   

4. 清理该快照备份 FULL_BACKUP_TS 之前的快照备份数据。

   rm -rf s3://backup-101/snapshot-${date}
   

---

br 备份命令手册：

• TiDB 快照备份与恢复命令行手册
• TiDB 日志备份与 PITR 命令行手册