使用br恢复数据缺失

🪐 TiDB 技术问题 备份&数据迁移
1

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

  • 【TiDB 版本】：v4.0.4
  • 【问题描述】：是这样的，我最近想验证一下br对某一个数据库的增量恢复功能，发现恢复的效果不是我想要的，有部分数据是缺失了，不知道是不是我操作有什么问题，麻烦大佬帮忙看看。

我的操作：先使用br对tidb数据进行全量备份—》然后update数据库A一条数据 —》对tidb进行第1次增量备份—》drop数据库A—》使用全量备份数据恢复数据库A—》使用第1次增量备份数据恢复数据库A—》数据库A成功恢复—》再次update数据库A一条数据—》对tidb进行第2次增量备份—》drop数据库A—》使用全量备份数据恢复数据库A—》使用第2次增量备份数据恢复数据库A—》数据库A只恢复了被修改的那一条数据，其他的表以及里面的数据都不见了，恢复过程也没有显示报错

ps：br使用的也是v4.0.4版本的工具包里的

会不会是因为我在第1次增量备份和第2次增量备份之间做了drop数据库A的操作导致的呢？:shushing_face:
还是说我增量恢复的姿势不对呢？？？

2

请问你的这个场景里面有没有异常报错呢 ？另外可以通过 BR 的 meta.log 确认一下备份的情况是否有 A 表的信息。

3

我看了下第2次增量备份恢复的日志，只有一个疑似报错的信息

image
image1280×207 139 KB

你说的meta.log是指备份文件里的 backupmeta 吗？我看了下，里面是有A库和被改动的表的信息的

抱歉，事情有点多，回复慢了。还有这不是我自己的tidb，实在不方便给你们提供更多信息了

4

已回复

6

因为步骤好像比较多，所以我按照我的理解重新整理一下，麻烦确认一下是否是这个步骤

  1. 使用 BR 对 TiDB 数据进行全量备份，all_backup1
  2. 更新数据库 A 的一条记录 update1
  3. 使用 all_backup1 的 LAST_BACKUP_TS_1 进行增量备份，inc_backup1
  4. drop database A
  5. 使用 all_backup1 恢复到原数据库
  6. 使用 inc_backup1 恢复
  7. 数据库 A 成功恢复，A 表中的数据是更新一条记录后的数据 update1
  8. 再次更新库 A 的一条记录 update2
  9. 使用 all_backup1 的 LAST_BACKUP_TS_1 进行增量备份，inc_backup2
  10. drop database A
  11. 使用 all_backup1 恢复到原数据库
  12. 使用 inc_backup2 恢复
  13. 查看恢复结果只有 update2 的更新结果，其他数据都丢失

另外需要确认一下几个点：

  1. 恢复的时候是直接在原集群恢复的么，目前 BR 恢复数据的话，建议是在新的空集群上进行恢复数据
  2. 第二次的增量备份如果是以 all_backup1 的 LAST_BACKUP_TS_1 进行增量备份的话，这一部分会有些问题，因为在进行第二次增量备份之前，是通过第一次全量以及第一次增量恢复的集群，恢复过程中虽然数据是恢复的，但是位置点之类的可能被覆盖掉了，所以第二次增量备份可能存在问题。正常的话，建议在第一次全量以及第一次增量恢复集群后，重新进行一次全量备份。
7

您好，感谢回复
列出的13个步骤都是准确的，我就是这样操作的
然后
1、恢复的时候是直接在原集群恢复的。一般来说，是tidb上某个库的数据丢失才会有恢复的需要（其他库不需要作改动），此时重新搭一个新的tidb集群不大现实，而且迁移到新集群也是需要巨大成本的
2、关于位置点之类的可能被覆盖掉这个问题，后面会不会安排修复呢？

8

这个位点覆盖掉，应该是因为 drop database A 导致这个位点发生了变化，目前 BR 恢复还是在空集群上面进行恢复比较成熟，我们会反馈这个问题，看看能不能支持在线的 BR 恢复。另外建议这类在线恢复场景，建议使用 Dumpling 和 Lightning 的逻辑备份方式，这个方式目前更适合在线恢复场景，同时对其他业务影响较低。

9

好的，感谢

10

:+1:

11

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。