#3543 Issue closed: local.conf configuration for system with no local storage. Using iSCSI.¶
Labels: support / question, fixed / solved / done
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.
DrayInsane commented at 2026-02-09 15:00:¶
I tried many different iterations of the local.conf.
I found one that would allow me to manually attach
the iSCSI LUN before starting "rear recovery".
There was an issue though that I ran into
that maybe others should be aware of if also using RHEL 9.
During the manual attach process I initially
could not start any iscsid services because
rear did not copy over the "/run/lock/iscsi" file.
The only thing I had to do was create it using
mkdir -p /run/lock/iscsi
then start the iscsid service.
Which then allowed me to use iscsiadm
to attach the LUN via the target IQN.
jsmeix commented at 2026-02-10 09:38:¶
So to automate things via NETWORKING_PREPARATION_COMMANDS
it could be something like
NETWORKING_PREPARATION_COMMANDS=(
'ip addr add 192.168.111.222/24 dev enp6s0'
'ip link set dev enp6s0 up'
'sleep 1'
'mkdir -p /run/lock/iscsi'
'iscsid'
'sleep 1'
'iscsiadm -m node --loginall=automatic'
'return'
)
i.e. what I had in my above comment
but now with mkdir -p /run/lock/iscsi added,
also cf.
https://github.com/rear/rear/issues/2429#issuecomment-646216100
gdha commented at 2026-03-16 15:36:¶
@DrayInsane were you able to restore with the above mentioned steps (of @jsmeix)?
DrayInsane commented at 2026-03-24 20:27:¶
Yes I was able to get it working with the help of @jsmeix 's steps. I did have to modify it a little bit as I only wanted one of the iSCSI targets to be logged in and used as a potential recovery location. I ended up writing a pre-recovery script instead of putting everything in local.conf. That allows me to ask the user to choose between a few options such as what IP/netmask should the machine have as well as what the IP of the iSCSI target is and which LUN/target to use.
Given that I am using RHEL 9.7 in a closed (no external network) environment I was initially using ReaR version 2.6 which is the default when downloading via "dnf install rear" on RHEL 9.7. It made certain things a bit harder such as during the pre-recovery script portion I could not backspace to erase characters and had to manually change the _input_output_functions.sh and default.conf to have the USER_INPUT_MAX_CHARS value = 0 in both places. I saw that, that was fixed in newer versions by @jsmeix with #2658. I don't know why RHEL hasn't added a newer version to their default repos but it is worth noting for any one else that comes after me. Could save the next person quite a bit of time by making the changes or finding a way to pull down the latest build version.
[Export of Github issue for rear/rear.]