Bug 1930662
| Summary: | The use of rsync with a user different than root will not restore links during the recovery | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Welterlen Benoit <bwelterl> |
| Component: | rear | Assignee: | Pavel Cahyna <pcahyna> |
| Status: | CLOSED ERRATA | QA Contact: | David Jež <djez> |
| Severity: | unspecified | Docs Contact: | Prerana Sharma <presharm> |
| Priority: | unspecified | ||
| Version: | 8.3 | CC: | djez, ovasik, pcahyna, presharm |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | rear-2.4-19.el8 | Doc Type: | Bug Fix |
| Doc Text: |
.rsync with an unprivileged remote user can now be used in ReaR
Previously, when rsync was used to back up and restore the system data `(BACKUP=RSYNC)`, the parameters to rsync were incorrectly quoted, and the `--fake-super` parameter was not passed to the remote rsync process. Consequently, the file metadata was not correctly saved and restored.
With this update following bugs have been fixed:
* ReaR uses the correct parameters for rsync.
* Improved rsync code for error detection during backup and restore:
** If there is a rsync error detected during the backup, ReaR aborts with an error message.
** If there is a rsync error detected during the restore, ReaR displays a warning message.
In the `/etc/rear/local.conf` file set `BACKUP_INTEGRITY_CHECK=1` to turn the warning into an error message.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-11-09 18:53:41 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1947064, 1973448 | ||
|
Description
Welterlen Benoit
2021-02-19 11:53:33 UTC
Is there anything that can be done in ReaR to improve the situation, except perhaps documenting the problem? I see that it is actually a problem in ReaR and not in rsync, per PR #2577 and bz1930654. Thanks for the investigation! Hello,
The easiest solution is to use "-M--fake-super", thus no need of "" around rsync --fake-super
And it's also a workaround to add this in local.conf:
BACKUP_RSYNC_OPTIONS=( "${BACKUP_RSYNC_OPTIONS[@]}" -M--fake-super )
Thanks
Benoit
I updated the KCS, the workaround does not work as the restore will also execute fake-super locally, thus permissions will not be restored... I submitted a related PR upstream that improves error checking during rsync backup (warning gets promoted to error) and restore (warning gets properly reported and optionally promoted to error). Steps to reproduce: 1. create an unprivileged user (here called 'user') 2. set up passwordless ssh from root to user 3. install and configure rear - /etc/rear/local.conf should contain BACKUP=RSYNC BACKUP_PROG_EXCLUDE=( '/tmp/*' '/dev/shm/*' "$VAR_DIR/output/*" "/home/user/rsyncbackup" ) BACKUP_URL=rsync://user@localhost/home/user/rsyncbackup/ 4. mkdir -p /home/user/rsyncbackup/ 5. create rear backup 6. verify that the backup files under /home/user/rsyncbackup/ have the appropriate extended attributes # getfattr -d -m- /home/user/rsyncbackup/$HOSTNAME/backup/bin ... user.rsync.%stat="120777 0,0 0:0" and it should be a regular file, not a symlink - the symlink information is stored in the extended attribute 7. optionally, to test the new error reporting, add a nonsensical option BACKUP_RSYNC_OPTIONS+=( -M--nonsense ) to local.conf and check that rear mkbackup aborts with an error instead of displaying a warning message and continuing. 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 (rear bug fix and enhancement 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/RHEA-2021:4344 |