Bug 1885552

Summary:	Incremental backup can not handle device minor number changes made by lvm after reboot
Product:	Red Hat Satellite	Reporter:	dgupte
Component:	Satellite Maintain	Assignee:	satellite6-bugs <satellite6-bugs>
Status:	CLOSED ERRATA	QA Contact:	Lukas Pramuk <lpramuk>
Severity:	high	Docs Contact:
Priority:	high
Version:	6.8.0	CC:	apatel, ehelms, jpathan, kgaikwad, patalber, riehecky, sokeeffe
Target Milestone:	6.14.0	Keywords:	Triaged
Target Release:	Unused
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-11-08 14:17:32 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:
Embargoed:

Description dgupte 2020-10-06 11:43:43 UTC

What is the nature and description of the request?
>>> 
Customer perform full backup on Sundays and incremental every other day. This works but when satellite server reboot, the minor device number gets changed for /var/lib/pulp.
This triggers "tar" that is used in "foreman-maintain backup" that everything has changed because it has a different minor device number.

Command "tar" has a "--no-check-device" but "tar" is run by "foreman-maintain" and it does not have option to pass it. 

# lsblk -p
/dev/mapper/vg01-pulp                 253:5   0  500G  0 lvm  /var/lib/pulp

- After satellite server reboot:-

# lsblk -p
/dev/mapper/vg01-pulp                 253:6   0  500G  0 lvm  /var/lib/pulp

Why does the customer need this? (List the business requirements here)  
>>>
  When satellite server has multiple disk controllers and disks, the device minor numbers can change by lvm during server reboot.
As of now "foreman-maintain backup --incremental".. can not handle this and "tar" thinks that content have changed when it has not.
This becomes a problem when pulp-data is rather big and it tries to take multiple backups of it all. 
You need to have a lot of extra space ready for backups.

How would the customer like to achieve this? (List the functional requirements here)
>>> 
  Be able to run foreman-maintain backup --incremental with tar "--no-check-device"

Comment 7 Brad Buckingham 2022-11-03 21:48:51 UTC

Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

Comment 8 Pat Riehecky 2022-11-04 13:54:26 UTC

https://github.com/theforeman/foreman_maintain/pull/658

Comment 9 Eric Helms 2022-11-04 14:51:19 UTC

Created redmine issue https://projects.theforeman.org/issues/35720 from this bug

Comment 11 Bryan Kearney 2023-03-31 16:02:16 UTC

Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/35720 has been resolved.

Comment 12 Bryan Kearney 2023-03-31 16:02:24 UTC

Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/35720 has been resolved.

Comment 14 Lukas Pramuk 2023-08-29 17:45:17 UTC

VERIFIED.

@Satellite 6.14.0 Snap 10
rubygem-foreman_maintain-1.3.3-1.el8sat.noarch

by this simple reproducer:

1) Replace tar with debug fake tar 
# mv /usr/bin/tar{,-orig} 
# echo sleep INF > /usr/bin/tar
# chmod +x /usr/bin/tar

2) Run backup
# satellite-maintain backup offline -y /tmp

3) Check tar process for cmdline options
# ps -efH | grep -A1 satellite[-]maintain
root       45860   43513  0 13:32 pts/0    00:00:00           /usr/bin/ruby /usr/bin/satellite-maintain backup offline -y /tmp
root       46432   45860  0 13:32 pts/0    00:00:00             sh -c tar --selinux --no-check-device --create --file=/tmp/satellite-backup-2023-08-29-13-32-15/config_files.tar.gz --gzip

>>> tar is now executed with --no-check-device option

Comment 17 errata-xmlrpc 2023-11-08 14:17:32 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 (Important: Satellite 6.14 security and bug fix update), 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/RHSA-2023:6818