Common causes
- An interrupted download, scp or rsync transfer
- The backup job ran out of disk space or hit a quota while writing the archive
- The archive was copied or downloaded while it was still being created
- A web server or proxy timed out and closed a large download early
- A size limit on the upload (PHP upload_max_filesize, panel file manager) cut the file
- Storage errors or a full /tmp during creation
How to fix it
- Confirm the file is truncated. Compare ls -l backup.tar.gz with the source size and run sha256sum on both. For compressed archives gzip -t backup.tar.gz (or xz -t) reports 'unexpected end of file' when data is missing.
- Copy it again. Re-download with curl -fL -C - -o backup.tar.gz URL to resume, or rsync --partial --progress for server-to-server copies. Verify the checksum before extracting.
- Check disk space on the source. If the archive was created by a backup script, run df -h where it was written. Fix the space problem and recreate the archive, otherwise every copy will be truncated.
- Salvage what is readable. Extracting still writes every file before the break: tar -xzvf backup.tar.gz runs until the error. Note the last file name printed, since that one is likely incomplete.
- Decompress first for stubborn cases. Run gzip -dc backup.tar.gz > backup.tar (it writes what it can before failing), then tar -xvf backup.tar --ignore-zeros to extract the readable members.
Terminal
gzip -t backup.tar.gz && echo OK
sha256sum backup.tar.gz
curl -fL -C - -o backup.tar.gz https://example.com/backup.tar.gz
# salvage readable files from a truncated archive
gzip -dc backup.tar.gz > partial.tar
tar -xvf partial.tar --ignore-zerosHow to stop it happening again
- Write a checksum file next to every backup and verify it after each transfer
- Check free disk space before a backup job starts
- Create archives under a temporary name and rename them only when finished
- Run gzip -t or tar -tzf on new backups as part of the job