Bug 1631183

Summary: Backup using tar always succeeds, even in case of tar error
Product: Red Hat Enterprise Linux 7 Reporter: Renaud Métrich <rmetrich>
Component: rearAssignee: Pavel Cahyna <pcahyna>
Status: CLOSED ERRATA QA Contact: David Jež <djez>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.5CC: djez, fkrska, myamazak, ovasik, pcahyna
Target Milestone: rcKeywords: Upstream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1657734 (view as bug list) Environment:
Last Closed: 2019-08-06 13:12:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1594286, 1630904, 1630910, 1630919, 1657734, 1660473    

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):

rear-2.00-7.el7_5.x86_64


How reproducible:

Always


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 
OUTPUT=ISO
OUTPUT_URL=file:///backup
BACKUP=NETFS
BACKUP_URL=file:///backup
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:
  ---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 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.

https://access.redhat.com/errata/RHBA-2019:2273