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
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rear
Version: 7.5
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Pavel Cahyna
QA Contact: David Jež
URL:
Whiteboard:
Depends On:
Blocks: 1594286 1660473 1630904 1630910 1630919 1657734
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)
Environment:
Last Closed: 2019-08-06 13:12:05 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:2273 None None None 2019-08-06 13:12:31 UTC
Github rear rear issues 1913 None None None 2018-09-20 09:09:29 UTC
Github rear rear pull 1914 None None None 2018-09-20 09:47:05 UTC
Red Hat Knowledge Base (Solution) 3618561 None None None 2018-09-20 08:47:23 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):

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


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