#3616 Issue closed: With tar exit code 2 we do not save the backup.log file

Labels: enhancement, fixed / solved / done

gdha opened issue at 2026-07-13 14:58:

Platform

Linux x64

2026-07-13 10:07:29.480516657 Encrypting backup archive is disabled
2026-07-13 10:07:29.485829852 Creating tar archive '/tmp/rear.tCzbLTGpwQ7rQN2/outputfs/image/backup.tar.gz'
2026-07-13 10:42:20.094543594 ERROR: tar failed with return code 2 and below output:
  ---snip---
  tar: /var/spool/postfix/public/showq: socket ignored
  tar: /var/spool/postfix/public/flush: socket ignored
  tar: Exiting with failure status due to previous errors
  ----------
This means that the archiving process ended prematurely, or did
not even start. As a result it is unlikely you can recover this
system properly. Relax-and-Recover is therefore aborting execution.

==== Stack trace ====

However, we only save the log file when the exit code is 0. It would be better to save always the backup.log file to have at least some output from tar.

Why is this the case? Because we use the Error function. Perhaps, we could before doing the error do a:

cp $v "${TMP_DIR}/${BACKUP_PROG_ARCHIVE}.log" "${opath}/${BACKUP_PROG_ARCHIVE}.log" >&2

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

No response

jsmeix commented at 2026-07-14 08:58:

I don't know why is this the case.

git log -p --follow usr/share/rear/backup/NETFS/default/500_make_backup.sh
shows that the current part

### Copy progress log to backup media
cp $v "${TMP_DIR}/${BACKUP_PROG_ARCHIVE}.log" "${opath}/${BACKUP_PROG_ARCHIVE}.log" >&2

at the end of backup/NETFS/default/500_make_backup.sh
originated in
https://github.com/rear/rear/commit/5bbefeaa25c63fa089c3906932f42626e9233c6b
there as Move progress log to backup media.
It was changed several times but its position
was kept at the end of backup/NETFS/default/500_make_backup.sh

I think that part should be moved upwards in the code
so the backup log file gets always saved
e.g. directly after the backup process had finished:

wait $BackupPID
backup_prog_rc=$?

# Save the backup log file:
cp $v "${TMP_DIR}/${BACKUP_PROG_ARCHIVE}.log" "${opath}/${BACKUP_PROG_ARCHIVE}.log" >&2

FYI
(related to this issue but does not belong to it):

At first glance it seems it is inconsistent
what we do with a backup log file
for the various backup methods.

E.g. in backup/RSYNC/default/500_make_rsync_backup.sh
it seems we do not save the backup log
while in backup/TSM/default/500_make_TSM_backup.sh
we do save the backup log
but I did not check the details.

jsmeix commented at 2026-07-14 11:41:

https://github.com/rear/rear/pull/3617
is a proposal to fix it

gdha commented at 2026-07-14 13:07:

With the backup.log file being present now we could see what the issue was:

#-> grep '^tar:' backup.log | grep -v ignored
tar: Removing leading `/' from member names
tar: /var/log/audit/audit.log: file changed as we read it
tar: /var/log/td-agent-bit: file changed as we read it
tar: Removing leading `/' from hard link targets
tar: mnt: Warning: Cannot flistxattr: Operation not supported
tar: /usr: file changed as we read it
tar: value 172655812800 out of time_t range 0..8589934591
tar: value 172655812800 out of time_t range 0..8589934591
tar: value 172655812800 out of time_t range 0..8589934591
tar: value 172655812800 out of time_t range 0..8589934591
tar: Exiting with failure status due to previous errors

The reason why we get an error 2 from tar is KB: https://access.redhat.com/solutions/4524101

jsmeix commented at 2026-07-15 07:49:

the public accessible initial part of
https://access.redhat.com/solutions/4524101
shows only the problem but neither solution nor cause
because it is "Subscriber exclusive content"
so I asked Google AI about

Rear backup failing with tar message: value -1 out of time_t range

and it replied:

the error is caused by corrupted file metadata on your system,
specifically an invalid timestamp (value -1) on at least one file.
Because tar cannot handle negative Unix timestamps
(dates before January 1, 1970) under certain configurations,
the rear mkbackup process fails with return code 2.
Here is how you can find the broken files, repair them,
and successfully complete your backup.

Step 1: Find the Corrupted Files
Use the find command to scan your system for files
with a modification time (mtime) that precedes the Unix epoch:

# find / -mtime +$(( `date -u +%s` / 86400 - 1 )) 2>/dev/null
[Use code with caution.]

Alternative:
If the issue is caused by a broken script
or a mounted filesystem that accidentally
set a date far in the future
(causing a 32-bit time_t overflow),
use this command instead:

# find / -newermt "1 day" 2>/dev/null
[Use code with caution.]

Step 2: Repair the Timestamps
Once you identify the affected files,
you can update their timestamps to the current system time
using the touch command.
You can combine the search and fix into a single automated command:

  For files in the "past" (before 1970):

  # find / -mtime +$(( `date -u +%s` / 86400 - 1 )) -exec touch {} + 2>/dev/null
  [Use code with caution.]

  For files in the "future" (overflow/beyond year 2038):

  # find / -newermt "1 day" -exec touch {} + 2>/dev/null
  [Use code with caution.]

Step 3: Run the Backup Again
After updating the invalid timestamps,
restart your ReaR backup process:

# rear -v mkbackup
[Use code with caution.]

Why does this happen?

The Root Cause:
This error typically happens due to incomplete file transfers,
misconfigured NFS mounts, database dumps, or virtual filesystems.
These processes sometimes write a -1 (often an internal error code)
directly into the filesystem metadata as a timestamp.

The ReaR Behavior:
While a standalone tar command might only log a warning
and continue, Relax-and-Recover (ReaR)
treats tar exit statuses strictly.
To guarantee a reliable bare-metal restore
in a disaster recovery scenario, ReaR intentionally
aborts the backup whenever tar encounters a metadata error.

[AI responses may include mistakes.]

jsmeix commented at 2026-07-16 12:44:

With https://github.com/rear/rear/pull/3617 merged
I assume this issue is sufficiently solved.

gdha commented at 2026-07-16 14:36:

@jsmeix Thank you very much for the quick fix.

[Export of Github issue for rear/rear.]