#3538 Issue closed: rear recover on SLES15 SP5: BUILD_DIR/outputfs not empty or umounted¶
Labels: support / question, fixed / solved / done
guzguz68 opened issue at 2025-11-24 19:19:¶
ReaR version¶
2.7 / 2022-07-13
Describe the ReaR bug in detail¶
Platform¶
Linux x64
OS version¶
SLES 15 SP 5
Backup¶
No response
Storage layout¶
What steps will reproduce the bug?¶
rear recover
Workaround, if any¶
Additional information¶
jsmeix commented at 2025-11-25 09:09:¶
@guzguz68
we need full ReaR debug info to be able to see
what went wrong in your particular case.
So you need to run "rear recover" in debugscript mode
for full ReaR debug info i.e. "rear -D recover"
as the messages told you to do.
Then provide us your "rear -D recover" log file.
Caution with possible secrets in a ReaR log file.
In particular in debugscript mode via '-D'
ReaR logs executed commands via the bash command 'set -x'
that print commands and their arguments as they are executed.
So in particular when arguments contain secret values
(e.g. something like a password or whatever else)
such secret values may appear in the log file.
So before you attach your debug log file or other files here
(GitHub is a public accessible place), inspect your files
and verify that they do not accidentally cointain secrets.
FYI:
(1)
First my generic "boilerplate"
regarding third-party backup tools:
Usually we at ReaR upstream do not have or use
third-party backup tools so usually we cannot
reproduce issues with third-party backup tools
(in particular not if a third-party backup tool
is proprietary software).
In case of issues with third-party backup tools
we at ReaR upstream can usually do nothing
but totally depend on contributions and help
from those specific users who use and know
about each specific third-party backup tool.
(2)
In general regarding SUSE support for ReaR
see
https://en.opensuse.org/SDB:Disaster_Recovery#SUSE_support_for_Relax-and-Recover
Normally SUSE provides ReaR only via the
SUSE Linux Enterprise High Availability Extension (SLE-HA)
which is the only SUSE product/extension
where SUSE officially supports ReaR.
What matters in the end is what your particular
SUSE support contract states.
When you have a SUSE support contract
it cannot be wrong to open a ticket at SUSE.
In the worst case you get notified that ReaR is not
supported with your current support contract.
jsmeix commented at 2025-11-25 09:14:¶
@guzguz68
I think I misinterpreted "TSM" in your screenshots
that you use BACKUP=TSM because your
https://github.com/user-attachments/files/23730400/rear-TSM.log
shows
2025-11-24 19:28:11.039776827 Including restore/NETFS/default/400_restore_backup.sh
2025-11-24 19:28:11.047359492 Restoring from '/mnt/REAR/TSM/backup.tar.gz' ...
so actually you use the default BACKUP=NETFS with 'tar'
and then my above generic "boilerplate" regarding
third-party backup tools does not apply here.
guzguz68 commented at 2025-11-25 09:35:¶
Hello jsmeix,
At the end restored system boot whitout any issue.
Source system used for source cloning (test) operation is a TSM server
but as you noticed the backup tool used was tar :-) .
Test has been completed on a virtual environment (Virtula Box) to
evaluate the feasability on physical (production) TSM Server system.
I'll check the subscription state with SUSE (SLES 15).
Thank you for all provided info. Closing the issue.
jsmeix commented at 2025-11-25 10:29:¶
@guzguz68
we had some of those kind of issues in the past.
Yes, normally you can ignore the issue
and simply reboot your recreated system
because the actual recovery worked without error
when the message Finished 'recover' is shown.
What only failed is the cleanup work at the end
e.g. umount things in BUILD_DIR/outputfs and so on.
With "rear -D recover" the reason why that failed
should be visible in the ReaR debug log file.
Perhaps the specific reason why it fails in your case
is already fixed in our latest ReaR 2.9 release
or in our current ReaR upstream GitHub master code
so you may try out if a newer ReaR works better.
See the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery
how you can have several ReaR versions in parallel
each one in its own separated directory
without conflicts between each other
and without conflicts with a normally installed
ReaR version via RPM package.
[Export of Github issue for rear/rear.]