印刻数据库

外观

TiDB 备份恢复最佳实践 ​

TiDB 提供了多种备份恢复工具和方法，用于保护数据的安全性和完整性。制定合理的备份恢复策略，遵循最佳实践，可以确保在发生数据丢失或灾难时，能够快速、可靠地恢复数据。

备份策略设计 ​

1. 备份类型选择 ​

根据业务需求和恢复目标，选择合适的备份类型：

全量备份 ​

  • 定义：备份整个 TiDB 集群的数据
  • 工具：BR（Backup & Restore）
  • 适用场景：定期全量备份，作为增量备份的基础
  • 恢复速度：较慢，需要恢复所有数据
  • 存储占用：较大，需要存储整个集群的数据

增量备份 ​

  • 定义：备份自上次全量备份或增量备份以来的变更数据
  • 工具：BR、TiCDC
  • 适用场景：频繁增量备份，减少数据丢失风险
  • 恢复速度：较快，只需恢复增量数据
  • 存储占用：较小，只需存储变更数据

日志备份 ​

  • 定义：备份 TiDB 的 binlog 日志
  • 工具：TiDB Binlog、TiCDC
  • 适用场景：实时日志备份，支持 PITR（Point-in-Time Recovery）
  • 恢复速度：较快，可以恢复到任意时间点
  • 存储占用：较小，只需存储日志数据

2. 备份频率设计 ​

根据业务的 RTO（Recovery Time Objective）和 RPO（Recovery Point Objective）要求，设计合理的备份频率：

业务类型全量备份频率增量备份频率日志备份RPO 要求
核心业务每天 1 次每小时 1 次实时< 5 分钟
重要业务每周 1 次每天 1 次实时< 30 分钟
一般业务每月 1 次每周 1 次可选< 2 小时
测试业务按需按需否不严格

3. 备份存储设计 ​

选择合适的备份存储方案，确保备份数据的安全性和可用性：

存储介质 ​

  • 本地存储：速度快，但安全性低，易受硬件故障影响
  • 网络存储：如 NFS、CIFS，便于共享，但依赖网络性能
  • 对象存储：如 S3、OSS，安全性高，容量大，成本低
  • 磁带存储：适合长期归档，成本低，但恢复速度慢

存储策略 ​

  • 3-2-1 原则：至少保留 3 份备份，存储在 2 种不同的介质上，其中 1 份存储在异地
  • 异地备份：将备份数据复制到异地，防止本地灾难导致数据丢失
  • 加密存储：对备份数据进行加密，保护数据安全性
  • 压缩存储：对备份数据进行压缩，减少存储占用

4. 备份保留策略 ​

根据业务需求和合规要求，设计合理的备份保留策略：

  • 全量备份：保留 1-3 个月
  • 增量备份：保留 7-14 天
  • 日志备份：保留 1-3 个月
  • 归档备份：将超过保留期限的备份归档到低成本存储

备份操作最佳实践 ​

1. 使用 BR 进行全量备份 ​

BR 是 TiDB 官方推荐的备份恢复工具，支持全量备份和增量备份：

bash
# 全量备份到本地存储
tiup br backup full \  
  --pd="<pd-host>:2379" \  
  --storage="local:///data/backup/full" \  
  --ratelimit=128 \  
  --concurrency=64

# 全量备份到对象存储
tiup br backup full \  
  --pd="<pd-host>:2379" \  
  --storage="s3://<bucket-name>/backup/full" \  
  --s3.endpoint="<s3-endpoint>" \  
  --s3.access-key="<access-key>" \  
  --s3.secret-access-key="<secret-access-key>" \  
  --ratelimit=128 \  
  --concurrency=64

2. 使用 BR 进行增量备份 ​

bash
# 增量备份到对象存储
tiup br backup incremental \  
  --pd="<pd-host>:2379" \  
  --storage="s3://<bucket-name>/backup/incremental" \  
  --lastbackupts=<last-backup-timestamp> \  
  --s3.endpoint="<s3-endpoint>" \  
  --s3.access-key="<access-key>" \  
  --s3.secret-access-key="<secret-access-key>" \  
  --ratelimit=128 \  
  --concurrency=64

3. 使用 TiCDC 进行实时备份 ​

TiCDC 可以实时捕获 TiDB 的变更数据，并将其备份到外部存储：

bash
# 创建 TiCDC 变更数据同步任务
tiup ctl cdc changefeed create \  
  --pd="<pd-host>:2379" \  
  --sink-uri="s3://<bucket-name>/cdc-backup?endpoint=<s3-endpoint>&access-key=<access-key>&secret-access-key=<secret-access-key>" \  
  --changefeed-id="cdc-backup" \  
  --config="cdc-config.toml"

4. 备份操作最佳实践 ​

  • 选择业务低峰期：在业务低峰期进行备份，减少对业务的影响
  • 限制备份速度：使用 --ratelimit 参数限制备份速度，避免占用过多资源
  • 调整并发度：根据集群规模和资源情况，调整 --concurrency 参数
  • 监控备份进度：使用 tiup br status 命令监控备份进度
  • 验证备份完整性：备份完成后，验证备份文件的完整性
  • 记录备份信息：记录备份时间、备份类型、备份路径、备份大小等信息

恢复操作最佳实践 ​

1. 恢复前准备 ​

在进行恢复操作前，做好充分的准备工作：

  • 评估恢复需求：确定恢复目标（全量恢复、增量恢复、PITR）
  • 选择恢复时间点：根据 RPO 要求，选择合适的恢复时间点
  • 准备恢复环境：准备干净的 TiDB 集群环境，或清空现有集群
  • 验证备份数据：验证备份数据的完整性和可用性
  • 制定恢复计划：制定详细的恢复计划，包括步骤、时间、人员等
  • 通知相关人员：通知相关人员，协调恢复工作

2. 使用 BR 进行全量恢复 ​

bash
# 全量恢复从本地存储
tiup br restore full \  
  --pd="<pd-host>:2379" \  
  --storage="local:///data/backup/full" \  
  --ratelimit=128 \  
  --concurrency=64

# 全量恢复从对象存储
tiup br restore full \  
  --pd="<pd-host>:2379" \  
  --storage="s3://<bucket-name>/backup/full" \  
  --s3.endpoint="<s3-endpoint>" \  
  --s3.access-key="<access-key>" \  
  --s3.secret-access-key="<secret-access-key>" \  
  --ratelimit=128 \  
  --concurrency=64

3. 使用 BR 进行增量恢复 ​

bash
# 增量恢复从对象存储
tiup br restore incremental \  
  --pd="<pd-host>:2379" \  
  --storage="s3://<bucket-name>/backup/incremental" \  
  --s3.endpoint="<s3-endpoint>" \  
  --s3.access-key="<access-key>" \  
  --s3.secret-access-key="<secret-access-key>" \  
  --ratelimit=128 \  
  --concurrency=64

4. 使用 PITR 进行时间点恢复 ​

bash
# 使用 PITR 恢复到指定时间点
tiup br restore point \  
  --pd="<pd-host>:2379" \  
  --storage="s3://<bucket-name>/pitr-backup" \  
  --s3.endpoint="<s3-endpoint>" \  
  --s3.access-key="<access-key>" \  
  --s3.secret-access-key="<secret-access-key>" \  
  --restored-ts="2023-01-01T12:00:00+08:00" \  
  --ratelimit=128 \  
  --concurrency=64

5. 恢复操作最佳实践 ​

  • 选择业务低峰期：在业务低峰期进行恢复，减少对业务的影响
  • 限制恢复速度：使用 --ratelimit 参数限制恢复速度，避免占用过多资源
  • 调整并发度：根据集群规模和资源情况，调整 --concurrency 参数
  • 监控恢复进度：使用 tiup br status 命令监控恢复进度
  • 验证恢复结果：恢复完成后，验证数据的完整性和一致性
  • 测试业务功能：测试业务功能是否正常，确保恢复成功
  • 记录恢复信息：记录恢复时间、恢复类型、恢复时间点、恢复结果等信息

备份验证最佳实践 ​

1. 备份完整性验证 ​

定期验证备份文件的完整性，确保备份数据可用：

  • 使用 BR 验证备份：

    bash
    tiup br validate \  
  --storage="s3://<bucket-name>/backup/full" \  
  --s3.endpoint="<s3-endpoint>" \  
  --s3.access-key="<access-key>" \  
  --s3.secret-access-key="<secret-access-key>"

  • 校验文件哈希值：计算备份文件的哈希值，并与备份时记录的哈希值进行比较

  • 检查文件大小：检查备份文件的大小是否在合理范围内

  • 检查文件数量：检查备份文件的数量是否完整

2. 备份恢复测试 ​

定期进行备份恢复测试，验证恢复流程的可行性和可靠性：

  • 测试频率：每月至少进行一次全量恢复测试，每季度进行一次 PITR 测试
  • 测试环境：在独立的测试环境中进行恢复测试，避免影响生产环境
  • 测试步骤：
    1. 准备测试环境
    2. 执行恢复操作
    3. 验证数据完整性
    4. 测试业务功能
    5. 记录测试结果
  • 测试报告：生成详细的测试报告，包括测试时间、测试步骤、测试结果、问题和改进建议

3. 恢复时间测试 ​

测试恢复操作所需的时间，确保满足 RTO 要求：

  • 记录恢复时间：记录从开始恢复到恢复完成的总时间
  • 分析恢复瓶颈：分析恢复过程中的瓶颈，如网络带宽、磁盘 I/O、CPU 等
  • 优化恢复流程：根据测试结果，优化恢复流程和配置

备份监控最佳实践 ​

1. 监控备份任务 ​

使用以下方法监控备份任务的状态和进度：

  • 使用 BR 命令：

    bash
    tiup br status \  
  --storage="s3://<bucket-name>/backup/full" \  
  --s3.endpoint="<s3-endpoint>" \  
  --s3.access-key="<access-key>" \  
  --s3.secret-access-key="<secret-access-key>"

  • 查看 BR 日志：查看 BR 备份过程中的日志，了解备份进度和可能的问题

  • 使用 Prometheus 监控：配置 Prometheus 监控 BR 备份任务的指标

  • 设置备份告警：设置备份失败、备份超时、备份大小异常等告警

2. 监控备份存储 ​

监控备份存储的使用情况，确保有足够的存储空间：

  • 监控存储容量：监控备份存储的使用量和剩余容量
  • 设置存储告警：当存储容量达到阈值时，触发告警
  • 监控存储性能：监控存储的读写性能，确保备份操作不受影响

3. 监控备份频率 ​

监控备份任务的执行频率，确保按照备份策略执行：

  • 记录备份时间：记录每次备份的开始时间和结束时间
  • 检查备份间隔：检查备份间隔是否符合备份策略要求
  • 设置频率告警：当备份任务未按计划执行时，触发告警

备份恢复自动化 ​

1. 使用 TiUP 自动化备份 ​

使用 TiUP 的 cron 功能，实现自动化备份：

bash
# 创建自动化备份配置文件 (backup-cron.toml)
[br]
pd = "<pd-host>:2379"
storage = "s3://<bucket-name>/backup/{date}"
s3.endpoint = "<s3-endpoint>"
s3.access-key = "<access-key>"
s3.secret-access-key = "<secret-access-key>"
ratelimit = 128
concurrency = 64

# 全量备份，每天凌晨 2 点执行
tiup cluster cron add <cluster-name> full-backup \  
  --command="br backup full" \  
  --config="backup-cron.toml" \  
  --schedule="0 2 * * *"

# 增量备份，每小时执行一次
tiup cluster cron add <cluster-name> incremental-backup \  
  --command="br backup incremental --lastbackupts=latest" \  
  --config="backup-cron.toml" \  
  --schedule="0 * * * *"

2. 使用脚本自动化备份 ​

编写脚本实现自动化备份和恢复：

  • 备份脚本：包括备份执行、备份验证、备份清理等功能
  • 恢复脚本：包括恢复执行、恢复验证、业务测试等功能
  • 监控脚本：监控备份任务状态、存储使用情况等
  • 告警脚本：当备份失败或异常时，发送告警通知

3. 自动化最佳实践 ​

  • 版本控制：对自动化脚本进行版本控制，便于管理和回滚
  • 测试脚本：在生产环境使用前，充分测试脚本的正确性和可靠性
  • 日志记录：详细记录脚本的执行过程和结果
  • 权限控制：严格控制脚本的执行权限，避免误操作
  • 定期更新：定期更新脚本，适应 TiDB 版本的变化

备份恢复常见问题 ​

1. 备份失败 ​

可能原因 ​

  • 网络连接问题
  • 存储权限不足
  • 存储空间不足
  • 集群状态异常
  • 备份参数错误

解决方案 ​

  • 检查网络连接：确保备份工具能够正常连接到 PD 和存储
  • 检查存储权限：确保备份工具对存储有读写权限
  • 检查存储空间：确保存储有足够的空间容纳备份数据
  • 检查集群状态：确保 TiDB 集群状态正常，没有异常节点
  • 检查备份参数：检查备份命令的参数是否正确

2. 恢复失败 ​

可能原因 ​

  • 备份数据损坏
  • 恢复环境不兼容
  • 恢复参数错误
  • 集群状态异常
  • 资源不足

解决方案 ​

  • 验证备份数据：验证备份数据的完整性和可用性
  • 检查恢复环境：确保恢复环境与备份时的环境兼容
  • 检查恢复参数：检查恢复命令的参数是否正确
  • 检查集群状态：确保恢复环境的 TiDB 集群状态正常
  • 增加资源：增加恢复环境的资源，如 CPU、内存、磁盘等

3. 恢复数据不一致 ​

可能原因 ​

  • 备份数据不完整
  • 恢复过程中断
  • 并发写入导致的数据不一致
  • 时钟同步问题

解决方案 ​

  • 验证备份数据：确保备份数据完整一致
  • 确保恢复过程不中断：在恢复过程中，避免中断恢复操作
  • 停止写入操作：在恢复过程中，停止对恢复环境的写入操作
  • 同步时钟：确保集群中所有节点的时钟同步

备份恢复合规要求 ​

1. 数据保护法规 ​

根据不同国家和地区的数据保护法规，如 GDPR、CCPA 等，确保备份恢复策略符合合规要求：

  • 数据保留期限：根据法规要求，保留足够期限的备份数据
  • 数据加密：对备份数据进行加密，保护数据隐私
  • 访问控制：严格控制备份数据的访问权限
  • 审计日志：记录备份恢复操作的审计日志

2. 行业标准 ​

根据行业标准，如 PCI DSS、HIPAA 等，确保备份恢复策略符合行业要求：

  • 备份频率：根据行业标准，设置合适的备份频率
  • 恢复测试：定期进行备份恢复测试，确保符合行业要求
  • 灾难恢复计划：制定详细的灾难恢复计划，包括备份恢复流程
  • 合规审计：定期进行合规审计，确保备份恢复策略符合行业标准

常见问题（FAQ） ​

Q1: BR 和 TiDB Binlog 有什么区别？ ​

A1: BR 和 TiDB Binlog 是 TiDB 提供的两种不同的备份恢复工具：

  • BR：主要用于全量备份和增量备份，支持快速恢复，适合大规模数据备份恢复
  • TiDB Binlog：主要用于实时日志备份和数据同步，支持 PITR，适合需要恢复到任意时间点的场景

Q2: 如何选择合适的备份工具？ ​

A2: 根据业务需求和恢复目标选择合适的备份工具：

  • 如果需要快速全量恢复，选择 BR
  • 如果需要恢复到任意时间点，选择 TiCDC 或 TiDB Binlog
  • 如果需要同时支持全量备份和 PITR，结合使用 BR 和 TiCDC

Q3: 备份操作会影响 TiDB 集群的性能吗？ ​

A3: 备份操作会占用一定的集群资源，可能会对集群性能产生影响。可以通过以下方法减少影响：

  • 在业务低峰期进行备份
  • 使用 --ratelimit 参数限制备份速度
  • 调整 --concurrency 参数，控制并发度
  • 对备份流量进行网络隔离

Q4: 如何确保备份数据的安全性？ ​

A4: 可以通过以下方法确保备份数据的安全性：

  • 对备份数据进行加密
  • 严格控制备份数据的访问权限
  • 遵循 3-2-1 备份原则
  • 将备份数据复制到异地
  • 定期验证备份数据的完整性

Q5: 如何减少恢复时间？ ​

A5: 可以通过以下方法减少恢复时间：

  • 使用高性能的存储介质
  • 增加恢复时的并发度
  • 优化恢复环境的配置
  • 采用增量恢复或 PITR，减少需要恢复的数据量
  • 提前准备好恢复环境

Q6: 如何测试备份恢复流程？ ​

A6: 可以按照以下步骤测试备份恢复流程：

  1. 准备独立的测试环境
  2. 执行备份操作
  3. 在测试环境中执行恢复操作
  4. 验证数据的完整性和一致性
  5. 测试业务功能是否正常
  6. 记录测试结果和恢复时间
  7. 分析测试结果，优化备份恢复策略

Q7: 如何监控备份任务的状态？ ​

A7: 可以使用以下方法监控备份任务的状态：

  • 使用 tiup br status 命令查看备份进度
  • 查看 BR 日志，了解备份过程中的详细信息
  • 使用 Prometheus 和 Grafana 监控备份指标
  • 编写脚本监控备份任务状态，当备份失败时发送告警

Q8: 如何制定合理的备份策略？ ​

A8: 制定合理的备份策略需要考虑以下因素：

  • 业务的 RTO 和 RPO 要求
  • 数据的重要性和敏感性
  • 集群的规模和负载情况
  • 存储成本和可用性
  • 合规要求和行业标准
  • 团队的运维能力和经验