BR的备份是保证事务性的吗？分成几个小问题：
memtable 里面的数据也会被备份走吗？强制flush到SST了？
刚刚写到wal文件，还没存到memtable的数据怎么被处理呢？
snapshot：被备份的数据事务tso号是备份的开始时间点吗？因为gc时间好像只有几分钟，而数据量大的话，整个备份需要几十分钟。事务结束的时候 备份起始点的数据版本会不会被gc掉了？
如果上面的问题OK，那么是否可以用br备份的事务tso作为起始位置点，配合binlog的增量备份，来做完善的备份恢复方案？
比如br半小时执行一次，每次花半小时，binlog随时备份增量。恢复的时候找到br备份的起始点，根据起始位置找到binlog的起始恢复点？
BR 备份其实没有想象的这么多工作
及BR 备份是备份的备份开始的时间节点的数据。其在备份开始时 会去 PD 请求 TSO 并，启用自适应 GC ，之后再进行备份。所以以上问题1 -2-3 问题不用考虑
备份结束后 BR 会在 PD 中将 自适应 GC 时间改回原来的 GC 设置
问题 4 ：
其实 PITR 是我们一直在推进的一个重要功能，后续的物理备份通过 BR 增量 日志的备份是通过 TiCDC ，目前 master 分支上已有 将 tikv change log 写入到本地存储和 S3 中的功能。
在 5.0 后续的版本中，将会支持 完整的 PITR 功能，简化此部分的操作复杂度。
@北京大爷
非常感谢您的回复 .
想进一步问一下
https://docs.pingcap.com/zh/tidb/stable/backup-and-restore-use-cases#备份前的准备工作
自 v4.0.8 起，BR 已支持自适应 GC。将
backupTS注册到 PD 的safePoint，保证safePoint在备份期间不会向前移动，由此可避免手动设置 GC。
我的理解是 问题3 没问题了.
那么问题1和问题2, 还没有被写到 SST 的内容是如何被备份走的呢?
难道 safePoint 背后有这样的 flush to sst 的机制吗?
这里涉及 2 个 概念
一个是 tikv 的 mvcc 实现。
还有一个是 br 备份的 time point
tidb 的 mvcc 是通过 KV 的 持久化实现的 MVCC
br 备份的是时间点是 备份动作的 开始时间点
所以 当使用 br 发起备份的时候 只用控制 TiDB的 GC 动作 不要把 过去的 MVCC 数据清理掉就可以了。br 向 pd 询问原信息，通知 tikv 导出指定数据到 sst 文件即可
其实我是想请教一下实现细节：
您说的mvcc是tikv的上层实现，那么底层其实还是rocks db。而在rocksdb的实现细节里，据说是一部分数据在memtable内，到一定的时机才会变成不可变的一块数据进而转存到SST文件内。也就是底层SST并不是所有的数据的集合。
那么问题来了，br只利用上层接口，实际要备份的内容却是底层SST文件，那他如果不命令rocks将memtable吐到SST，岂不是漏掉了需要备份的数据？怎么解决的呢？
备份的结果转成了 SST 文件，但是备份的直接对象并不是 SST 文件吧？
明白了，多谢指教。
原来是我误解了br。以为SST的备份是物理备份。实际上br的备份是逻辑备份。
https://github.com/pingcap/br/blob/master/docs/cn/2019-08-05-new-design-of-backup-restore.md
捞到这篇文档，总算明白了。
这里的物理备份/逻辑备份 怎么叫法, 其实有些微妙.
tidb 5.0 的视频教程里面把 BR 的备份称作 物理备份 , 但是也说到 每个 region leader 负责突出自己的SST数据.
从这个角度 「物理备份是直接用于 tidb 各个 region 的数据恢复文件」来看, 算作物理备份也似乎没问题.
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。