为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【TiDB 版本】
4.0.6
【问题描述】
使用BR（4.0.6）备份一张表时，每次都失败
集群是多实例混合部署
总共8台服务器，每台服务器上有三个tikv
请帮忙分析下失败原因
相关日志如下
链接:https://pan.baidu.com/s/1MBjkLan193GOT5dpXsXZzQ 提取码:609p
可否直接上传 backup log，下载速度较慢，如果 log 比较大，辛苦拆分下，包括最后一次备份的完整 log 即可。
- 看日志中报错：error="rpc error: code = Unavailable desc = transport is closing
- 请问备份到什么介质，如果不是本地挂载，请检查是否网络中是否有超时设置，备份时间过长被防火墙kill进程。
用的SSD＋NFS共享盘备份，网络检查了一下没发现问题
数据量在65亿左右
- 确认没有防火墙之类的问题？
- 麻烦反馈下 tikv 的日志，多谢。
抱歉，我试了下，解决失败，文件已损坏。 是不是文件太大了，不好上传。或者麻烦您看下，再BR报错的时间段，tikv 日志有什么报错吗？
- 从 TiKV 日志看有一些backup 的报错
[“backup scan entries failed”] [err_code=KV-Storage-KeyIsLocked] [err=“Mvcc(KeyIsLocked(primary_lock: 74800000000000FD245F698000000000000001013030383533313830FF3633363033363632FF0000000000000000F703800000006F755201 lock_version: 422407007154733057 key: 74800000000000FD245F698000000000000001013133363930313339FF3539350000000000FA03800000006F755B6C lock_ttl: 5426 txn_size: 6))”]
[2021/03/27 21:33:45.825 +08:00] [ERROR] [endp - 请使用 v4.0.12 版本的 BR 试试（tidb 集群不用升级，只需要用一个新的 BR）
针对上面的问题，辛苦再收集下，下面的信息：
1、再次确认下，只有备份某张特定的表如 65E 的大表时才会备份失败，其他表均能正常备份成功的哈？
2、BR 备份期间 TiKV-Details 的 Grafana 监控辛苦收集下，建议监控的时间点上面截图的最新备份的时间段前后 1 小时
3、store 5547623 的 Grafana Node-Exporter 监控，建议监控的时间点上面截图的最新备份的时间段前后 1 小时
Grafana 监控导出方法参考：[FAQ] Grafana Metrics 页面的导出和导入
收到，辛苦 ~
另外，是否方便将最新一次单独备份这张表的 BR 的 log 和 store 5547623 TiKV 的 log 也一并上传下 ~
上面 BR 命令是在 PD 所在的服务器发起的吗？BR 发起备份命令以及 TiKV 的服务器 iptables 是关闭的状态，并且 BR 的服务器和 TiKV 之间也不存在物理防火墙设备的吗？
Tikv日志太大了，有130M, 上传百度云可以吗，或者有其他方式吗
BR是在pd所在机器执行的，所有的服务器在安装操作系统时都是默认关闭防火墙的， BR 的服务器和 TiKV 之间也不存在物理防火墙设备
可以的，请只截取备份时间点前 1 小时 + 备份期间 + 备份报错后 1 小时 store 5547623 的日志，另外还有 BR 备份这个表的 log 哈 ~
另外，store 5547623 对应的是 95.50.12.5 上的哪个端口？20180 ~ 20182 中的哪一个？
题外话：看到咱们的 tikv 的 datadir 都比较大在 14T （官网上是建议 2T ）左右，想了解下这样使用是基于什么考虑的？
对应的是20180端口
我们的服务器目前还是使用的HDD硬盘，每个服务器12块盘做的3个raid5，每个raid5对应一个tikv，因为我们的数据量比较大，目前已经更换了SSD的服务器，所以在做数据迁移
BR&tikv.7z (1.7 MB)
收到，分析中 ~