目标端能重建吗
或者使用逻辑备份恢复呢
已经用dumpling 和lightning 搞完了，就是gc还是每天只有一次
一天是因为强制gc的参数时间是一天，除了长事务想不到别的原因阻塞了
new_collation…
这个现在可以直接改系统表实现？
之前是只能创建集群时配置。
- **SST 下载失败：**大概率是磁盘空间不足导致下载被截断，加上强制修改 collation 配置可能引发元数据不一致。
- **GC 停止：**BR 备份会锁定 GC safepoint 防止数据被清理，如果备份异常结束但 safepoint 未释放，GC 就会一直暂停。 3. **磁盘爆满：**GC 不执行 → MVCC 旧数据无法回收 → 磁盘无法释放，加上 import 目录残留临时文件。
建议：下次恢复前确保两个集群的 new_collations_enabled_on_first_bootstrap 一致，先清理 safepoint 释放 GC，确认目标磁盘有足够余量再操作。
这个应该不行
但是他换成逻辑导出导入还是要到强制的时间gc才会回收呢
使用 BR 恢复时，因 new_collation_enabled 不一致，你尝试强制修改备库系统表，随后报错 download sst failed （下载 SST 文件失败，大小不匹配）
恢复失败后，发现 TiKV 存储不均衡，部分节点磁盘爆满，且 GC 时间停留在凌晨,BR 恢复过程中虽然你删除了库，但 TiKV 底层可能残留了大量的 SST 文件或未清理的 Region 数据（特别是 Import 模式下的临时文件）
库都删除了，为什么会残留大量的SST文件？