我来帮你搞定这个头疼的问题——你遇到的核心原因其实和S3深度归档（Deep Archive）的特性有关，这也是--ignore-existing看似失效的关键所在。

为什么会出现这个问题？ #

S3深度归档存储类的对象是不可直接读取的（必须先发起恢复请求才能访问内容）。而rclone默认的文件对比逻辑，会尝试验证目标文件的内容完整性（比如哈希值）或者读取元数据细节，但面对深度归档的对象，这些操作会失败。这就导致rclone误判这些文件“不存在”或者“不匹配”，进而重复上传。

你之前尝试的--ignore-existing和--size-only没生效，大概率是因为rclone在检查目标文件时，因为无法访问内容，跳过了常规的存在性判定。

分步解决方案 #

1. 先排查重复复制的具体原因

先通过--dry-run和--verbose参数，让rclone告诉你它为什么要重复复制某个文件：

rclone copy --ignore-existing --progress --dry-run --verbose "/var/vmail" foo-backups:foo-backups/vmail

查看输出里的日志，你会看到类似这样的提示：

NOTICE: example.txt: Not copying as --ignore-existing is set
或者
NOTICE: example.txt: Need to copy - file not found at dest

如果是后者，说明rclone确实没识别到目标端的归档文件；如果是提示“大小不匹配”或“修改时间不同”，那我们可以针对性调整参数。

2. 针对性调整rclone参数

根据排查结果，选择对应的参数组合：

• 如果rclone能识别目标文件，但因为哈希/内容无法验证而重复复制：
  加上--ignore-checksum参数，告诉rclone不要验证文件内容的哈希值，只基于文件名、大小和修改时间判断是否存在：

  rclone copy --ignore-existing --progress --size-only --ignore-checksum "/var/vmail" foo-backups:foo-backups/vmail
  

• 如果rclone完全识别不到目标端的归档文件：
  这时候需要确保rclone能读取S3桶的文件列表（默认是允许的），同时使用--use-server-modtime参数，让rclone使用S3服务器端的修改时间来对比，而不是尝试读取本地文件的修改时间：

  rclone copy --ignore-existing --progress --size-only --use-server-modtime "/var/vmail" foo-backups:foo-backups/vmail
  

• 终极方案：改用sync命令配合--max-delete 0
  如果你觉得copy的逻辑太绕，可以用sync命令，加上--max-delete 0确保不会删除任何目标文件，同时sync的存在性判定逻辑更严谨，能更好地处理归档类存储：

  rclone sync --progress --max-delete 0 --size-only --ignore-checksum "/var/vmail" foo-backups:foo-backups/vmail
  

  这里--max-delete 0的作用是禁止rclone删除目标端比源端多的文件，完美替代copy --ignore-existing的需求。

额外提示 #

• 注意：S3深度归档的恢复成本很高，所以尽量避免重复上传，确保参数配置正确后再执行真实的复制操作。
• 如果你经常和S3归档存储打交道，可以把常用参数加到rclone的配置文件里（比如在[foo-backups]段加上size_only = true或ignore_checksum = true），避免每次命令都重复输入。

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