一次数据库全量备份直接管道进对象存储命令大概长这样pg_dump-Fcmydb|zstd-T0|rclone rcat remote:backup/full-20260804.dump.zst跑了两个多小时传到 48 GiB 出头的位置直接退出报的是分片编号超出允许范围。网络没断磁盘没满桶也没配额限制。重跑一次还是同一个位置。问题不在链路上在一道乘法上分片上传最多 10,000 片rclone 默认分片 5 MiB5 MiB × 10000 ≈ 48.8 GiB。流式上传事先不知道总大小客户端没法替你把分片调大于是天花板就卡死在这儿。一、先把这道乘法算清楚S3 的分片上传Multipart Upload有三条硬约束绝大多数 S3 兼容实现都照着做单个分片5 MiB 到 5 GiB最后一片允许小于 5 MiB一次上传最多10,000 片单对象上限 5 TiB不走分片的单次 PUT 上限 5 GiB。推论只有一句话能传多大的对象 分片大小 × 10000。这张表最该记的是第三列。同样传一个 200 GiB 的归档5 MiB / 8 MiB / 16 MiB 三档全部会撞上 10,000 片的墙只有把分片提到 32 MiB 以上才有富余。而 8 MiB 恰好是 AWS CLI 和 boto3 的出厂默认值。二、知道文件大小时SDK 会偷偷替你改参数这里有个容易被误会的点用aws s3 cp传一个 200 GiB 的本地文件并不会报错。因为 boto3 底层的s3transfer里有一个分片调整器发现按当前分片会超过 10,000 片就自己往上调只在 debug 日志里留一行提示。froms3transfer.utilsimportChunksizeAdjuster adjChunksizeAdjuster()size200*1024**3# 200 GiBprint(adj.adjust_chunksize(8*1024**2,size))# 8 MiB - 自动放大rclone 也有类似行为本地文件已知大小时会自动抬高分片并打一行 warning。真正会失败的是大小未知的那一类上传——rclone rcat、管道流、Transfer-Encoding: chunked的上传、以及自己手写CreateMultipartUploadUploadPart循环的代码。这些路径上没人替你算乘法。已知大小的场景把参数写进配置一劳永逸aws configuresetdefault.s3.multipart_threshold 64MB aws configuresetdefault.s3.multipart_chunksize 64MB aws configuresetdefault.s3.max_concurrent_requests20未知大小的流式场景只能自己声明分片# 流式上传时显式抬高分片把上限从 48.8 GiB 提到 625 GiBpg_dump-Fcmydb|zstd-T0|\rclone rcat --s3-chunk-size 64M remote:backup/full-20260804.dump.zst或者干脆先落盘再传。多占一份临时磁盘换回可断点续传、可校验、可重试单片的能力多数备份场景里这笔账是划算的。三、并发不是越大越好先算内存分片调大之后第二个坑马上跟上来内存。分片上传的每一片在发出去之前通常要在内存里攒齐所以峰值内存大致是峰值内存 ≈ 分片大小 × 单文件并发数 × 同时传输的文件数按 rclone 的默认值--transfers 4、--s3-upload-concurrency 4如果把分片提到 64 MiB就是64 MiB × 4 × 4 ≈ 1 GiB。在一台 2 GiB 内存的备份机上跑OOM 只是时间问题。boto3 这边同样要显式约束importboto3fromboto3.s3.transferimportTransferConfig cfgTransferConfig(multipart_threshold64*1024**2,multipart_chunksize64*1024**2,max_concurrency8,# 并发线程数use_threadsTrue,)boto3.client(s3).upload_file(big.tar.zst,backup,big.tar.zst,Configcfg)调参的取舍很直白分片调大请求数少、元数据开销小、更容易跑满带宽代价是单片失败重传的成本变高内存占用线性上涨。并发调高能压满网卡代价是内存翻倍且容易把同一前缀打到限流阈值上AWS S3 的公开指标是每前缀约 3,500 次写、5,500 次读每秒自建集群的阈值取决于磁盘和 CPU。经验起点千兆网、内存充裕分片 32–64 MiB、并发 8–16内存紧张就先砍并发别砍分片。四、传失败之后那些还在计费的残片上传中断最贵的后果不是重传是残片。已经上传成功的分片会一直躺在服务端直到你显式 Complete 或者 Abort。在没 Complete 之前它们不出现在ListObjects里s3 ls看不见但空间照占、账单照算。先查有多少# 列出桶里所有未完成的分片上传aws s3api list-multipart-uploads--bucketbackup\--queryUploads[].{Key:Key,Id:UploadId,Init:Initiated}--outputtable# 手动中止某一次aws s3api abort-multipart-upload--bucketbackup\--keyfull-20260804.dump.zst --upload-idUploadId用 mc 的话是mc ls --incomplete myminio/backup和mc rm --incomplete --recursive。手动清一次治标规则挂上去才治本。给桶加一条生命周期规则让服务端自动回收超过 7 天的残片{Rules:[{ID:abort-stale-multipart,Status:Enabled,Filter:{Prefix:},AbortIncompleteMultipartUpload:{DaysAfterInitiation:7}}]}aws s3api put-bucket-lifecycle-configuration\--bucketbackup --lifecycle-configuration file://abort-mpu.json天数别设太小。7 天是个安全值既不会让残片过夜太久也不会误杀一个正在慢慢传的超大对象。如果确实有跨天的上传任务把规则改成按前缀生效别一刀切到全桶。五、校验分片对象的 ETag 不是 MD5传完之后想比对完整性很多脚本习惯拿ETag去和本地md5sum对aws s3api head-object--bucketbackup--keyfull.dump.zst--queryETag# 9c7a3f...e12-3200后面那个-3200就是提示这是分片对象ETag 是每片 MD5 拼起来再算一次 MD5还带上分片数量后缀。它跟整个文件的 MD5 天然对不上而且分片大小一变ETag 就变所以它也不能当作跨集群比对的依据。要可靠校验改用显式 checksumaws s3api put-object--bucketbackup--keysmall.bin\--bodysmall.bin --checksum-algorithm CRC32C分片上传时给每一片带上 checksumComplete 时服务端会做整体校验。这条路的代价是客户端要多算一遍哈希CPU 占用会上去一点换来的是传完就知道对不对不用事后再下载一遍比对。六、下次遇到大文件上传失败按这个顺序查先看报错里有没有 part number / part size 字样。有的话直接算乘法分片大小 × 10000 是不是够。确认这是不是流式上传。管道、rcat、chunked 编码客户端不会替你调分片必须手动指定。算峰值内存分片 × 单文件并发 × 文件并发。跟机器可用内存对一下OOM 和网络抖动长得很像。查残片list-multipart-uploads跑一遍看看历史上失败的上传攒了多少空间。挂生命周期规则AbortIncompleteMultipartUpload设 7 天这条规则应该是新桶的默认动作之一。别用 ETag 做完整性校验改 checksum。这些约束是 S3 协议层面的换成哪家实现都得遵守。自建这一侧的差别主要在两处分片的落盘与合并路径快不快以及有没有把残片回收做进生命周期管理里。RustFS 这类 S3 兼容实现走的是同一套 API 语义上面这些命令可以原样跑不用改客户端代码 —— 迁移时真正要重测的反而是分片大小和并发这组参数在新集群上的最优值因为它跟磁盘数量、纠删码配置直接相关。先跑第 4 步。大概率你会在某个桶里翻出几十 GiB 谁也不记得的残片。