我之前帮不少朋友处理过TB级文件迁移到S3的需求，你的思路方向是对的，但原命令里有几个小问题，同时还有更高效、可靠的方案可以参考：

先修正你原命令的问题 #

你的命令逻辑是找文件→打包→拆分→压缩→上传，但有几个细节没处理好：

1. 用find -print0传递文件名时，tar需要对应--null参数读取null分隔的输入，不然会把带空格/特殊字符的文件名拆错，应该写成：

   find /home/<target> -type f -mtime +30 -print0 | tar --null -cvf - -T - | split --bytes=5120MB | gzip | ...
   

2. s3 mv命令不能直接读取标准输入，应该用aws s3 cp，而且拆分后的文件需要指定不同的输出名，不然会覆盖，比如可以用split --bytes=5120MB - s3_upload_生成s3_upload_aa、s3_upload_ab这类文件，再逐个上传。
3. 这种打包拆分的方式最大问题是：如果中间某一步失败，整个批次都要重传，而且后期要恢复文件需要下载所有拆分包再解压，灵活性很差，不适合TB级的大规模迁移。

更推荐的几种方案 #

方案1：用AWS CLI的sync命令（最简单的原生方案） #

AWS CLI的sync命令天生支持按文件属性过滤，还能自动断点续传、保留目录结构，非常适合批量迁移：

aws s3 sync /home/<target> s3://bucket/<target> \
  --exclude "*" \
  --include "*" \
  --filter "mtime:+30"

• --filter "mtime:+30"表示只同步修改时间超过30天的文件
• 如果迁移后要删除本地文件，可以加--delete参数，但一定要先加--dryrun测试确认不会误删！
• 优势：原生工具无需额外安装，支持增量同步，断点续传。

方案2：find + xargs + aws s3 cp（更灵活的批量上传） #

如果你需要更精细的文件筛选（比如排除某些目录/文件类型），可以用find配合xargs批量调用aws s3 cp，还能保留目录结构：

find /home/<target> -type f -mtime +30 -print0 | \
  xargs -0 -n 20 aws s3 cp --parents s3://bucket/<target>/

• -n 20表示每次批量处理20个文件，避免进程过多拖慢系统
• --parents会自动在S3上创建对应的目录结构
• AWS CLI v2可以加--parallel 10参数开启并行上传，提升大文件迁移速度

方案3：用rclone（最适合TB级大规模迁移） #

rclone是专门的云存储同步工具，对S3的支持非常完善，自带分块上传、断点续传、并行处理、文件校验等功能，简直是大文件迁移的神器：

rclone copy /home/<target> s3://bucket/<target> \
  --min-age 30d \
  --transfers 32 \
  --checkers 64 \
  --s3-chunk-size 100M

• --min-age 30d：只迁移超过30天的文件
• --transfers 32：同时上传32个文件，充分利用带宽
• --checkers 64：同时检查64个文件的状态，提升扫描效率
• --s3-chunk-size 100M：适配S3的multipart分块上传机制，避免大文件上传失败
• 如果迁移后要删除本地文件，把copy换成move即可（同样建议先加--dry-run测试）
• 优势：性能拉满，可靠性高，支持加密、校验，甚至可以跨云迁移，后期维护也方便。

关键注意事项 #

• 大文件分块：S3对单个文件上传的最大限制是5GB（不用multipart的话），所以不管用哪种工具，都要确保开启分块上传（AWS CLI和rclone默认都会处理）
• 文件校验：迁移后一定要验证文件完整性，rclone默认会自动校验，AWS CLI可以加--content-md5参数
• 权限与成本：确保AWS账号有s3:PutObject、s3:ListBucket等权限；同时注意S3的存储成本、出站流量成本，跨区域迁移的话成本会更高
• 测试先行：所有命令先用--dryrun（AWS CLI）或--dry-run（rclone）测试，确认筛选的文件正确，避免误操作

内容的提问来源于stack exchange，提问作者Scouse_Bob