为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
- 【TiDB 版本】：v4.0.0
- 【问题描述】： 现计划对一个tidb集群做日常备份，以防各种原因导致的数据丢失，考虑最好是物理热备的方式。麻烦问下目前br工具只支持恢复到新集群吗，后期有恢复到现有集群上的支持计划吗，或者是否还有别的效率较高的方案可以替代。
首先 tidb 是多副本的分布式数据库，在丢失少量副本的情况下是不会丢数据的。
br 目前支持在全新集群上进行恢复， BR 也可以对 TiDB 的数据进行增量备份和增量恢复，如果有需求可以到 5.0 需求中进行回复。
好的，多谢。再麻烦问下哈，我们这边比较担心人员误操作删除数据后，没有备份文件恢复的情况，针对误删数据这种情况咱们有比较好的恢复方案吗，目前咱们支持恢复到现有集群上的备份方式都是逻辑备份吗。
你好，
flashback table 看下是否满足需求，此功能比较依赖 gc ，请看下，目前仅支持表级别的恢复。
https://docs.pingcap.com/zh/tidb/v4.0/sql-statement-flashback-table/#flashback-table
这个问题可以通过删除更新前进行备份来解决，或者增加审计插件，如果是测试环境貌似也不需要关注这个问题。tidb 这边貌似没有好的办法。
目前 dm 可以过滤一些 ddl 和 dml 操作，但是会出现数据不一致的情况，如果再次操作被删除的数据，同步也会出现问题。
您好，好的，了解，多谢。再麻烦请教个问题哈，咱们备份文件的集群节点有10个，可以通过br恢复到有6个节点的集群上吗
br 恢复需要在所有 tikv 节点上进行，所以选择性的恢复是不可以的，这样也不能保证 tikv region 的 balance
我理解你应该是想问：A 集群有 10 个 TiKV 节点，新的 B 集群只有 6 个 TiKV 节点，能不能把通过 BR 备份的 A 集群数据恢复至 B 集群？
如果是这个问题的话，这种方式是可以的。一个明确的前提是，B 集群上的节点需要能访问全量的 A 集群的备份（简单理解就把 A 集群上备份出来的 SST 等文件放到一起）
好的，了解到了，多谢。thx~
您好，收到，多谢。咱们SST文件的备份的数据是只有一份吗，没有冗余数据备份是吗，恢复到新的集群时在重新划分region和做多副本吗
sst 文件不做操作，调度仅在 pd 产生。物理文件不需要迁移
您好，在请问一下目前咱们br的备份文件路径支持hdfs吗，如果没有的话，后期有支持计划吗
好的，十分感谢！我们这边评估一下这个需求哈。还有几个问题麻烦在跟您请教和确认一下哈，我测试了下br的fullback操作：
1.发现每个tikv节点上的每个region会产生多个sst文件，如图所示，regionid和版本号是一致的，startkey是不一致的，每个文件的大小也不一致，看着不像是写满了sst文件的固定大小然后继续写下一个，这个是依据什么来划分的；
2. 每个tikv备份出来的sst文件数量相当，所以从每个tikv上备份的region数量大致是一致的吗，不会出现有大量region只备份在同一个tikv实例上情况吧，在备份单表和单库的时候发现会有某个节点上有大量的sst文件，同时也有好几个节点sst文件为空的情况；
3. 所有tikv实例备份出来的region是全部region之和，不会存在重复的情况是吗，就是说每个replica中只会备份一个副本的数据；
4. 在进行恢复的时候，假设有这么一个场景，集群A有10个tikv节点，我们在备份完成之后把所有的SST文件放在一起，然后恢复到一个有6个节点的集群B上，在恢复的过程中这6个tikv节点会再次平均分配所有的region吗，在分配完成之后在做多副本吗？我们这边比较担心如果集群A上tikv节点的备份文件数量不均衡，某一个tikv节点备份出来的sst文件数量巨大，在恢复时会遇到一些不均衡或者资源的问题。没有找到恢复原理的相关的文档说明，所以跟您请教下。麻烦您了，感谢感谢！
sst 文件在 br 备份时不会在 tikv 节点下新增或删除，节点下的 sst 文件仅为 rocksdb 操作，
br 备份是从 region leader 进行备份的，所以这取决于 region leader 是否分布均匀，所以也就可以理解，当备份单表或者单库时，可能出现这些表的数据仅存在于部分 tikv 的 region 中。
br 当前仅仅备份出 1 副本的数据，并且使用 sst 文件，具有压缩特性，备份出来的 sst 约等于 1 副本的数据量。
是平均分配的，br 会根据当前的 max-replicas 的副本数和 label 的设置将 region 分布到 tikv 节点中。
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。