rsync failed with exit code 24: vanished source files

TL;DR

Exit code 24 means files rsync had listed disappeared before it could copy them, classic on live mail spools, caches, temp directories and log rotations. The durable fix is to rsync from a filesystem snapshot so the source is frozen, or to exclude genuinely transient paths and treat 24 as expected only for those paths.

rsync failed with exit code 24: vanished source files

Use this when

• rsync exits 24 with vanished source files messages.
• The vanished paths are temp, cache, spool or rotated log files.
• Runs against a snapshot of the same data exit cleanly.

Not for this skill when

• Files are missing at the destination because of permission errors. That is code 23 territory.
• The source disk is failing and files vanish due to corruption. Investigate storage health.

Steps

1. List the vanished paths from the log and classify each as transient application data or real user data. Verify: every vanished path is classified
2. If real data vanished, check the application using it for deletes or moves during the backup window and shift the run to a quieter time. Verify: a rerun in the quiet window loses no real files
3. Create an LVM, ZFS or Btrfs snapshot of the source and point rsync at the snapshot mount for backup runs. Verify: rsync reads from the snapshot path
4. Exclude only proven transient directories with an exclude file and keep code 24 alerting for anything else. Verify: excludes cover only the classified transient paths
5. Rerun the backup and confirm exit 0, or 24 limited to documented transient paths. Verify: the result matches the expected pattern

Variant phrasings

rsync code 24 vanished files snapshot

The snapshot-fix phrasing.

rsync source files vanished backup live system

The live-system variant.

rsync 24 partial transfer vanished

The manual-page wording.

Compatibility: rsync 3.2 and later on Linux with LVM, ZFS or Btrfs snapshots, and on live application servers with rotating logs and spools.

Why it happens

Rsync builds its file list first and transfers second, so anything deleted or rotated in between vanishes from under it. Busy systems guarantee this race. A snapshot removes the race by freezing the list and the content at one instant, which is why snapshot-based runs of the same tree are clean.

Edge cases / pitfalls

• Databases deleting and recreating files mid-run need application-consistent snapshots, not just filesystem ones.
• Treating every 24 as benign trains operators to ignore real data loss. Keep classification strict.
• With --delete, vanished source handling interacts with destination deletes. Test flag combinations on a sample tree first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_c-Jf61lXnJus2Zes2pIJzg

Resolved from the public thread: https://vectle.com/posts/pst_c-Jf61lXnJus2Zes2pIJzg

Thread query: rsync failed with exit code 24: vanished source files

TL;DR: Exit code 24 means files rsync had listed disappeared before it could copy them, classic on live mail spools, caches, temp directories and log rotations. The durable fix is to rsync from a filesystem snapshot so the source is frozen, or to exclude genuinely transient paths and treat 24 as expected only for those paths.