#1913 Issue `closed`: NETFS+tar backup tests wrong exit code (may succeed even if there was a real error)¶

Labels: enhancement, bug, fixed / solved / done

rmetrich opened issue at 2018-09-20 09:08:¶

ReaR version ("/usr/sbin/rear -V"): 2.4 (latest upstream)
OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"): Red Hat 7

ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

# cat etc/rear/site.conf 
OUTPUT=ISO
OUTPUT_URL=file:///backup
BACKUP=NETFS
BACKUP_URL=file:///backup
ONLY_INCLUDE_VG=( 'rhel' )

Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR): N/A
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device): N/A
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot): N/A
Storage (lokal disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe): N/A
Description of the issue:

A NETFS+tar backup will be seen as a success even if there was an error. This typically happens when there is no space left on the target device.

[root@vm-rhel7 rear]# ./usr/sbin/rear -v mkbackuponly
Relax-and-Recover 2.4 / Git
Running rear mkbackuponly (PID 2188)
Using log file: /home/rmetrich/GIT/rear/var/log/rear/rear-vm-rhel7.2188.log
Using backup archive '/backup/vm-rhel7/backup.tar.gz'
Creating disk layout
Excluding Volume Group data
Excluding component fs:/backup
Using guessed bootloader 'GRUB' (found in first bytes on /dev/sda with GPT BIOS boot partition)
Creating tar archive '/backup/vm-rhel7/backup.tar.gz'
Archived 751 MiB [avg 9863 KiB/sec] OK
WARNING: tar ended with return code 1 and below output:
  ---snip---

  ----------
This means that files have been modified during the archiving
process. As a result the backup may not be completely consistent
or may not be a perfect copy of the system. Relax-and-Recover
will continue, however it is highly advisable to verify the
backup in order to be sure to safely recover this system.

Archived 751 MiB in 79 seconds [avg 9738 KiB/sec]

Work-around, if any: No workaround.

jsmeix commented at 2018-09-20 09:35:¶

I know about that behaviour and I assume it is intentionally.

In the past I experienced tar exit with non-zero exit code
but the actual issue was unimportant for me so that
I decided the result was acceptable.

I think if the running rear would abort when the backup program
returns with non-zero exit code it would be too hard.

I think the intended behaviour is to only warn when the backup program
returns with non-zero exit code so that the user is informed
and can decide if the result is acceptable or not in his case.

FYI regarding WARNING messages cf.
https://blog.schlomo.schapiro.org/2015/04/warning-is-waste-of-my-time.html

rmetrich commented at 2018-09-20 09:47:¶

@jsmeix We can do better, see #1914 ;-)

jsmeix commented at 2018-09-20 09:54:¶

@rmetrich
thanks you for your explanation in
https://github.com/rear/rear/pull/1914#issue-216908023
which means the issue is a real bug (wrong exit code is used).

rmetrich commented at 2018-09-20 09:55:¶

indeed :-)

jsmeix commented at 2018-09-20 10:09:¶

@rmetrich
while you are at it ;-)
you may also have a look how restore with tar behaves.

In contrast to rear mkbackup that can abort in case of normal errors
in general rear recover should not abort unless there are fatal errors
during backup restore.

Reason:
The user cannot do much during rear recover
when there are normal errors during backup restore
so that it is better to only warn about such errors
but let the user nevertheless continue recovery.
Ideally via a user dialog so that the user can decide.
Perhaps the errors during backup restore are acceptable for now
and can be relatively easily fixed later in the rebooted recreated system.

jsmeix commented at 2018-09-21 12:19:¶

With https://github.com/rear/rear/pull/1914 merged
this issue should be fixed.

[Export of Github issue for rear/rear.]

#1913 Issue closed: NETFS+tar backup tests wrong exit code (may succeed even if there was a real error)¶