记录一下那天晚上的排查过程。备份脚本用 ossutil 把 40G 的数据库全量包传到 OSS，跑到一半报 Part number is too large 或碎片数量超限，目标桶里留下几百个未合并的碎片。
刚开始盯着「脚本没加 -f 参数，断点续传的信息不完整」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。默认分片大小偏小，大文件切出来的分片数超过了上限。也可能是上传中断后碎片没有清理，累计数量触顶。
少数情况下是同一路径并发上传两份，Object 名冲突。
动手时先清理历史碎片
ossutil rm -b bak-prod -r oss://bak-prod/tmp/ -f调大分片大小后重新上传
ossutil cp -f db_20261111.tar.gz oss://bak-prod/db/ --part-size 100随后确认对象大小和完整性
ossutil stat oss://bak-prod/db/db_20261111.tar.gz剩下的就是把分片参数固化进备份脚本
grep -n 'part-size' /opt/scripts/oss_backup.sh改完先别撤，确认这几项。ossutil stat 显示对象大小与本地文件一致，桶里没有残留碎片，恢复演练时下载解包校验通过。
这里还有个坑。碎片是按存储量计费的，中断后要及时清；大文件建议先本地压缩再传，分片大小按文件大小调整，别一直用默认值。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。