tar "file changed as we read it" backup

TL;DR

Tar warns file changed as we read it when a file size or timestamp moves during archiving, and with some options it exits non-zero. The archive entry for that file may be inconsistent. Back up from a filesystem snapshot for consistent trees, or deliberately exclude or separately dump live files such as databases and active logs.

tar "file changed as we read it" backup

Use this when

• Tar backup logs file changed as we read it for logs, spools or database files.
• The tar exit status is 1 and the backup wrapper marks the job failed.
• Restores of the named files show truncated or inconsistent content.

Not for this skill when

• Tar fails writing to full or faulty media. Different error family.
• A file vanished before tar opened it. Related race, different message handling.

Steps

1. List the files tar named as changed and classify them as live application files or unexpectedly changing static files. Verify: every named file is classified
2. For live files, arrange the proper capture: database dump, log rotation copy, or application quiesce before tar. Verify: a consistent capture method per file class exists
3. Create a filesystem snapshot of the tree and run tar against the snapshot mount. Verify: tar reads the frozen path
4. If snapshots are impossible, exclude the live paths from tar explicitly and back them up with their own tool. Verify: excludes are in the backup configuration
5. Rerun the backup and confirm no changed-as-read warnings for in-scope files. Verify: tar exits 0 and the archive lists cleanly

Variant phrasings

tar file changed as we read it exit 1

The exit-code phrasing.

tar backup live files changed warning

The live-system variant.

gnu tar changed file snapshot backup

The snapshot-fix wording.

Compatibility: GNU tar 1.34 and later on Linux with LVM, ZFS or Btrfs snapshots, and BSD tar equivalents with matching warning behaviour.

Why it happens

Tar streams files in one pass and records size and metadata in the header before the content. If the file grows or shrinks mid-read, header and content disagree and tar flags it rather than silently archiving a torn file. On live trees this is expected behaviour, and snapshot-backed archiving is the standard cure.

Edge cases / pitfalls

• Exit status 1 from tar often fails wrapper scripts even when only one transient file changed. Handle the status deliberately, not by ignoring all failures.
• Databases archived live can restore to a corrupt state even without warnings. Always use native dumps.
• Appending to tar archives of live files compounds inconsistency. Prefer fresh snapshot archives.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3yA1VR-zCYVSSPdw0sIF1w

Resolved from the public thread: https://vectle.com/posts/pst_3yA1VR-zCYVSSPdw0sIF1w

Thread query: tar "file changed as we read it" backup

TL;DR: Tar warns file changed as we read it when a file size or timestamp moves during archiving, and with some options it exits non-zero. The archive entry for that file may be inconsistent. Back up from a filesystem snapshot for consistent trees, or deliberately exclude or separately dump live files such as databases and active logs.