Bug 1631183 - Backup using tar always succeeds, even in case of tar error
Summary: Backup using tar always succeeds, even in case of tar error
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rear
Version: 7.5
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Pavel Cahyna
QA Contact: David Jež
Depends On:
Blocks: 1594286 1630904 1630910 1630919 1657734 1660473
TreeView+ depends on / blocked
Reported: 2018-09-20 07:39 UTC by Renaud Métrich
Modified: 2019-08-06 13:12 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1657734 (view as bug list)
Last Closed: 2019-08-06 13:12:05 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github rear rear issues 1913 0 None closed NETFS+tar backup tests wrong exit code (may succeed even if there was a real error) 2020-03-16 02:39:45 UTC
Github rear rear pull 1914 0 None closed Issue #1913 - NETFS+tar backup exit code testing insufficient (may fail to catch real backup errors) 2020-03-16 02:39:46 UTC
Red Hat Knowledge Base (Solution) 3618561 0 None None None 2018-09-20 08:47:23 UTC
Red Hat Product Errata RHBA-2019:2273 0 None None None 2019-08-06 13:12:31 UTC

Description Renaud Métrich 2018-09-20 07:39:57 UTC
Description of problem:

It appears that the ReaR backup code using "tar" is broken and indicates always a success even in case "tar" returned an error.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Configure rear to backup to a location which is too small to contain the backup (e.g. leave 300M free on a LV)

# cat /etc/rear/site.conf 
ONLY_INCLUDE_VG=( 'rhel' )

# mount /dev/data/lv /backup
# dd if=/dev/zero of=/backup/bigfile bs=1M count=700

2. Run the backup

# rear -v mkbackuponly

Actual results:

WARNING: tar ended with return code 1 and below output:

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 762 MiB in 88 seconds [avg 8874 KiB/sec]

Expected results:

The real error (there is no issue with "tar", but "dd" returned 1 because ENOSPACE)

Additional info:

Issue happens with Upstream ReaR also.

Comment 19 errata-xmlrpc 2019-08-06 13:12:05 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.