同步日志或缓存目录时，rsync可能完成大部分文件后返回code 24，并提示file has vanished。这通常表示文件进入清单后、真正读取前已被删除或改名。
code 24代表部分传输，不能仅因目标目录看起来有数据就当作完整成功。
code 24具体表示什么
rsync官方把退出码24定义为Partial transfer due to vanished source files。它与code 23不同：24专指源文件在传输过程中消失，常见于日志轮转、临时文件清理、构建目录替换和应用原子重命名。
先确认消失的是可再生临时文件还是必须一致备份的业务数据。
怎样记录真正消失的文件
保留rsync标准错误和退出码，例如运行后立即读取$?。可增加--itemize-changes和明确的日志文件，按时间核对file has vanished条目；不要只看最后一行汇总。
同时检查源端日志轮转、清理定时器和部署任务。不要用过滤输出的方式隐藏警告，否则监控会把不完整同步误报为成功。
先稳定源目录再重试
需要一致副本时，应暂停写入、使用应用提供的快照机制，或从文件系统/LVM快照读取，再重新运行同一条rsync命令。仅对可再生缓存或明确允许变化的日志，才可以在记录清单后接受少量消失文件。
重试前不要直接在目标端执行危险的全量删除。源端仍在变化时，重复同步可能继续得到code 24。
脚本如何正确处理退出码
自动任务应保存rsync退出码，并对24单独告警或按业务规则处理。官方FAQ给出把24转换为0的包装思路，但这只适用于已经确认消失文件可忽略的场景；生产备份默认应保留非零状态。
不要把所有非零退出码统一忽略。code 23、11或12分别代表其他错误，风险边界不同。
重新同步后的验收方法
重试后确认退出码为0，再用--dry-run --itemize-changes检查仍有差异的项目，并抽查关键文件的大小、时间戳或校验值。可在萤光云或LightNode的测试VPS复现轮转目录。验收标准是关键文件无遗漏、日志可追溯、目标端未误删且任务退出码符合策略。
FAQ
问：使用–ignore-missing-args能解决code 24吗？答：它主要影响命令行或files-from中缺失的源参数，不能替代对传输期间文件消失的判断。
问：再次运行rsync一定能补齐吗？答：只有文件仍存在或已稳定生成时才能补齐；已被永久删除的临时文件不会重新出现。
温馨提示
温馨提示：备份数据库、上传目录或队列文件时，优先使用应用一致性快照。对持续变化目录建立可接受的退出码与告警规则，并定期做恢复演练。
