请问使用备份工具 br 备份到自建 S3 存储，发现了如下报错
TiDB 版本是 5.4.2
[BR:KV:ErrKVStorage]tikv storage occur I/O error\nerror happen in store 7181537 at xxx:20160: Io(Custom { kind: Other, error: \"failed to put object rusoto error Request ID: None Body: <Error><Code>InvalidPart</Code><Message>One or more of the specified parts could not be found. The part might not have been uploaded, or the specified entity tag might not have matched the part's entity tag.</Message>
和这个问题有点相似，你可以看看~
并不是一直用不了，偶尔出现的问题。
问过公司内部 s3 的同事，他们怀疑是 br 在 uploadPart请求失败后，后续在完成分片的时候传入了错误的分片信息导致completeMultipartUpload失败，所以希望问下社区有没有用户遇到类似的错误，或者麻烦开发老师大致说下br工具的分片上传逻辑那就最好了
其他节点有 pending offline 的情况吗？
这里有几个类似的问题，报错一样，你可以参考下~
备份该集群 tikv 节点并没有异常，之前也反馈过这种 I/O error 的问题，但是看起来更像是 br 和 s3 的某一方出现的问题
BR工具支持的是标准的S3协议，而其他厂商或者自建的类S3集群可能有些许不兼容。你们用的S3是哪种情况啊
场景：br 备份数据至s3
问题：因br工具调用，分片上传提交分片时，少传了部分part，导致提交出现40x错误，导致整体备份任务退出
期望社区：请社区帮忙定位，该部分逻辑是否存在问题，错记录了部分part？整体备份任务退出逻辑是否合理，可否加个开关跳过？
请问这个截图上的时间是什么耗时？另外，提供一下你们是用的哪种技术自建的S3吧，是Minio？
找了 S3 的同学看了下，感觉大概率是 br 工具的问题，请问有update 吗？
BR报错时候已经运行多长时间了啊？感觉大概率是S3的问题，可以找你们开发类S3的同学确认一下，有没有限制分片的最长保留时间。
或者你本地用minio搭建一个S3存储，来测试一下备份到minio上有没有报错。
这个任务到备份报错退出持续了2个小时左右，分配最长保留时间2天。
额，那就不清楚，我这里备份到阿里云OSS和腾讯云COS都是兼容的，不过S3协议本质还是Amazon自己定的协议，一直都还在发展中，各种工具也只能是尽可能兼容，不能保证100%兼容。。。