#3543 Issue open: local.conf configuration for system with no local storage. Using iSCSI.¶
Labels: support / question
DrayInsane opened issue at 2025-12-04 14:56:¶
Requesting support or just a question¶
What parameters inside my local.conf do I use
to be able to back up / recover a system
that has no local hard drive and uses iSCSI.
Platform¶
Linux x64
Output¶
I have tried multiple different versions of local.conf
to get it to work.
I will add the latest local.conf file to this post.
I am using RHEL 9.6.
I have tried using rear 2.6 and 2.9.
I am trying to create a backup as an ISO
that can be burned to a disc or saved to USB
and will boot into the rescue environment,
connect to my iSCSI target,
and recover the image to that iSCSI target.
The system does not have any local storage at all.
The system has multiple network interfaces
but can only use one for the iSCSI connection.
It is named enp6s0.
I have been having issues with all the different
iterations I have tried such as the rescue environment
not attempting to connect to the iSCSI target first,
the initrd being too large, Not seeing a kernel
to load automatically.
I just need help figuring out what parameters to use
to get one ISO that can recover my system using iSCSI.
I tried what I saw here
https://relax-and-recover.org/rear-user-guide/issues/2020-06-17.2429.issue.closed.html
but it seemed to fail when there is no local storage at all.
I am sure I am just overlooking something
but don't know where to look.
Additional information¶
jsmeix commented at 2025-12-04 16:59:¶
@DrayInsane
first and foremost: I never used iSCSI.
In particular I have no iSCSI hardware
(as expected when one works in homeoffice)
so I cannot reproduce iSCSI things which means
I cannot actually help with iSCSI issues.
Nevertheless I will try to help in a generic way
as far as I can:
https://relax-and-recover.org/rear-user-guide/issues/2020-06-17.2429.issue.closed.html
is
https://github.com/rear/rear/issues/2429
It was closed without further activity
so specific iSCSI support is not implemented
which means iSCSI needs special manual setup
by using generic functionality in ReaR
which had worked sufficiently well at least
at that time for the case of that issue.
From reading through the whole
https://github.com/rear/rear/issues/2429
I think main items which are needed are
the following excerpts:
https://github.com/rear/rear/issues/2429#issuecomment-645626221
which contains a local.conf example where in particular
those parts are special manual setup related to iSCSI
PROGS+=( /usr/libexec/openssh/sftp-server )
COPY_AS_IS+=( /usr/libexec/openssh/sftp-server
/etc/iscsi
/var/lib/iscsi )
...
NETWORKING_PREPARATION_COMMANDS=( 'ip addr add 192.168.56.200/24 dev enp0s8'
'ip link set dev enp0s8 up'
'return' )
BOOT_OVER_SAN="yes"
AUTOEXCLUDE_MULTIPATH="no"
REQUIRED_PROGS+=( iscsid iscsiadm )
furthermore it reads
Only modification comparing to non-iSCSI setup is
to copy Iscsi daemon configuration (/etc/iscsi)
and LUN connection config files (/var/lib/iscsi) + add
iscsid and iscsiadm (open-iscsi administration utility)
into ReaR recovery system.
After boot into ReaR rescue system,
one need to start iscsid,
login to iSCSI target and run rear recover.
The part
After boot into ReaR rescue system,
one need to start iscsid,
login to iSCSI target
can be also automated via NETWORKING_PREPARATION_COMMANDS
for example like
NETWORKING_PREPARATION_COMMANDS=(
'ip addr add 192.168.56.200/24 dev enp0s8'
'ip link set dev enp0s8 up'
'sleep 1'
'iscsid -f'
'sleep 1'
'iscsiadm -m node --loginall=automatic'
'return'
)
as in
https://github.com/rear/rear/issues/2429#issuecomment-645858253
So the first step to get done is
to create a ReaR recovery system with "rear mkrescue"
which can be booted on replacement hardware
where one can make the iSCSI disks accessible
so that from within the ReaR recovery system
things look like
https://github.com/rear/rear/issues/2429#issuecomment-646216100
For that first step do not run "rear recover"
because that would completely overwrite
all what there is on your current iSCSI disks
by creating new partitions and filesystems
on your current iSCSI disks.
This first step is only to verify that
from within the ReaR recovery system
the iSCSI disks are accessible
but without actually doing something
with those iSCSI disks.
For further steps you need a well separated
test system on replacement hardware
with well separated iSCSI disks
where it does not matter when "rear recover" tests
totally fail, see also
https://en.opensuse.org/SDB:Disaster_Recovery
Only when the above first step works the next step is
to integrate making a backup of the system's files
and with that test how far "rear recover" works.
To be able to help you when things fail
in your particular case in your specific environment
we would need ReaR debug log information
as described in the section
"Debugging issues with Relax-and-Recover"
in
https://en.opensuse.org/SDB:Disaster_Recovery
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.
DrayInsane commented at 2025-12-08 17:11:¶
I will see what I can figure out and test and respond back when I have more information or a fix.
[Export of Github issue for rear/rear.]