#2942 Issue `closed`: '-c' and '-C' options are ignored with 'automatic/auto_recover' and 'unattended' modes¶

Labels: enhancement, fixed / solved / done

jsmeix opened issue at 2023-02-21 13:19:¶

I found an issue with our current '-c' and '-C' options:

The 'automatic/auto_recover' and 'unattended' modes
currently call only

rear $rear_debug_options recover

see
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/skel/default/etc/scripts/system-setup#L155
and
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/skel/default/etc/scripts/system-setup#L192

So '-c' and '-C' are ignored / not possible
with our current 'automatic/auto_recover' and 'unattended' modes
which is an issue that needs to be fixed.

Cf.
https://github.com/rear/rear/issues/2936#issuecomment-1438462224

jsmeix commented at 2023-02-21 13:28:¶

My current offhanded idea how to fix that generically
is to store the whole 'rear [options] workflow' command line
of each last called workflow in the ReaR recovery system.

Because only "rear mkrescue" and "rear mkbackup" create
a ReaR recovery system only those workflows can store
their command line in the ReaR recovery system.

So some "rear special_option mkbackuponly" cannot
store its command line in the ReaR recovery system.

Cf.
https://github.com/rear/rear/issues/2936#issuecomment-1438475287

schlomo commented at 2023-02-21 19:59:¶

FYI, we copy the directory specified by -c (and stored as CONFIG_DIR) into the rescue system as /etc/rear so that there would be no point to remember and use -c for rear recover:
https://github.com/rear/rear/blob/ea900c4ec9589c7acb3d90c01f75ad7781fbdd8c/usr/share/rear/build/GNU/Linux/100_copy_as_is.sh#L165

It seems like primarily -C remains a problem and I totally agree with the goal that automated recovery should also work for -C users. My suggestion would be to use CONFIG_APPEND_FILES_PATHS in order to set CONFIG_APPEND_FILES in rescue.conf to again load the same files that had been loaded successfully and do that during the rescue stage. That way this will only happen for ReaR runs that actually generate a rescue image and not for others.

I can code that up quickly if we agree on the concept.

jsmeix commented at 2023-02-22 09:08:¶

@schlomo
please be patient.
There is zero time pressure here.
Basically nobody uses '-c' or '-C' plus
'automatic/auto_recover' or 'unattended'
because the current state is since it was introduced
and I cannot remember any user report about it.
Since a very long time I didn't use any of '-c' or '-C'
or 'automatic/auto_recover' or 'unattended'.

I need time to understand how '-c' and '-C' behave
when used with different values for different workflows, cf.
https://github.com/rear/rear/issues/2936#issuecomment-1434304552
which is in particular how '-C' is primarily meant to be used, see
https://github.com/rear/rear/blob/master/doc/user-guide/11-multiple-backups.adoc

Then I can make educated statements in this area
and agree or disagree on your proposal.

It is not about quick coding.
We have already way too much quickly implemented code in ReaR
for limited purpose that poorly integrates with the rest of ReaR
(e.g. the whole OUTPUT=USB functionality is an endless annoyance).

jsmeix commented at 2023-02-23 12:41:¶

The primary use case for '-C' as described in
https://github.com/rear/rear/blob/master/doc/user-guide/11-multiple-backups.adoc
is to specify things in

/etc/rear/local.conf
/etc/rear/basic_system.conf
/etc/rear/home_backup.conf
/etc/rear/opt_backup.conf

then run on the original system

# rear mkrescue
# rear -C basic_system mkbackuponly
# rear -C home_backup mkbackuponly
# rear -C opt_backup mkbackuponly

and to recreate that on replacement hardware
run there in the ReaR recovery system

# rear -C basic_system recover
# rear -C home_backup restoreonly
# rear -C opt_backup restoreonly

Currently I have no idea how to automatically
run those commands in the ReaR recovery system
i.e. how to automatically find out
while on the original system plain

# rear mkrescue

is run (which is the only comand that creates
or that can modify the ReaR recovery system)
that later for disaster recovery
in the ReaR recovery system something like

# rear -C basic_system recover && rear -C home_backup restoreonly && rear -C opt_backup restoreonly

should be run.

jsmeix commented at 2023-02-23 12:49:¶

@schlomo
I think why your proposal
https://github.com/rear/rear/issues/2942#issuecomment-1439021298
cannot work in general is that according to your

again load the same files that had been loaded successfully

it seems you implicitly assume there is always
a single recovery command (usually 'rear recover')
to recreate a system so it would be sufficient to
source (actually there is no such thing as 'load' a config file)
a single sequence of config files during recovery.

jsmeix commented at 2023-02-23 12:55:¶

I have an idea how to make a sequence of recovery commands
possible with 'automatic/auto_recover' and 'unattended' modes
but that won't happen automatically but must be setup manually
by the user.

My reasoning is:
The (experienced) user who set up the "mkbackup" procedure
knows what sequence of recovery commands (with right options)
are needed to recreate things properly so he can manually
specify the right sequence of recovery commands.
Then even an unexperienced user can do the recovery.

jsmeix commented at 2023-03-01 13:28:¶

Mainly for my own information:

How to wait for several simultaneously running background jobs
and show some info what happened to them:

# ( sleep 1 ; echo 1 started ; sleep 9 ; echo 1 succeeded ) & \
  ( sleep 2 ; echo 2 started ; sleep 6 ; echo 2 failed ; exit 2 ) & \
  ( sleep 3 ; echo 3 started ; sleep 3 ; echo 3 failed ; exit 3 ) & \
  while jobs % &>/dev/null ; \
  do echo waiting for a job to finish ; \
     wait -n && echo a job succeeded || echo a job failed with $? ; \
  done ; \
  echo all finished

[1] 27123
[2] 27124
[3] 27125
waiting for a job to finish
1 started
2 started
3 started
3 failed
[3]+  Exit 3                  ( sleep 3; echo 3 started; sleep 3; echo 3 failed; exit 3 )
a job failed with 3
waiting for a job to finish
2 failed
[2]+  Exit 2                  ( sleep 2; echo 2 started; sleep 6; echo 2 failed; exit 2 )
a job failed with 2
waiting for a job to finish
1 succeeded
[1]+  Done                    ( sleep 1; echo 1 started; sleep 9; echo 1 succeeded )
a job succeeded
all finished

So the above shown recovery command

# rear -C basic_system recover && \
  rear -C home_backup restoreonly && \
  rear -C opt_backup restoreonly

could be run with the two 'restoreonly' workflows in parallel like

# if rear -C basic_system recover ; \
  then rear -C home_backup restoreonly & \
       rear -C opt_backup restoreonly & \
       wait ; \
  fi

where the plain wait for the background jobs
could be generically enhanced to show some info
what happened to the background jobs like

# if rear -C basic_system recover ; \
  then rear -C home_backup restoreonly & \
       rear -C opt_backup restoreonly & \
       while jobs % &>/dev/null ; \
       do echo Waiting for a restoreonly workflow to finish ; \
          wait -n || echo ERROR: A restoreonly workflow failed with $? ; \
       done ; \
  fi

github-actions commented at 2023-05-01 02:21:¶

Stale issue message

github-actions commented at 2023-07-02 02:52:¶

Stale issue message

github-actions commented at 2023-09-02 01:59:¶

Stale issue message

github-actions commented at 2023-11-04 02:03:¶

Stale issue message

jsmeix commented at 2023-11-20 12:46:¶

To avoid that it gets forgotten where it currently is
here a copy from
https://github.com/rear/rear/pull/3070#discussion_r1397363473

... I am thinking about a new
RECOVERY_COMMANDS array to specify the command(s)
that should be run to recover the system
in automated or unattended modes
which is by default "rear recover".
This way the user can specify the right commands
for his particular usage of '-C'.

Automation of this might happen at a later time
(if it is possible at all) by someone who likes
to contribute it.

jsmeix commented at 2023-12-06 13:51:¶

I will document how to use RECOVERY_COMMANDS
when '-C' is used for
"Using Multiple Backups for Relax-and-Recover"
https://github.com/rear/rear/blob/master/doc/user-guide/11-multiple-backups.adoc

Regarding '-c' see my current (mis?)understanding
https://github.com/rear/rear/pull/3070#discussion_r1402057092

github-actions commented at 2024-02-05 02:07:¶

Stale issue message

github-actions commented at 2024-04-07 02:06:¶

Stale issue message

github-actions commented at 2024-06-08 02:11:¶

Stale issue message

gdha commented at 2024-09-05 07:21:¶

@jsmeix milestone is still 'ReaR v2.8' - please adjust as you think it best fits (v3.0 or v3.1). Thanks.

jsmeix commented at 2024-09-05 07:53:¶

Postponed to ReaR v3.1 milestone
because there is now RECOVERY_COMMANDS
so the user can specify the right commands
for his particular usage of '-C', cf.
https://github.com/rear/rear/issues/2942#issuecomment-1819001753

What is missing is documenation, cf.
https://github.com/rear/rear/issues/2942#issuecomment-1842929410
so this could be done for ReaR v3.1 as time permits.

github-actions commented at 2025-02-19 02:35:¶

Stale issue message

github-actions commented at 2025-04-23 02:51:¶

Stale issue message

github-actions commented at 2025-06-24 03:07:¶

Stale issue message

jsmeix commented at 2025-07-28 08:41:¶

https://github.com/rear/rear/pull/3499
intends to implement
https://github.com/rear/rear/issues/2942#issuecomment-1842929410

jsmeix commented at 2025-07-29 12:54:¶

With https://github.com/rear/rear/pull/3499 merged
it is now described in doc/user-guide/11-multiple-backups.adoc

How to recover with multiple backups in 'auto_recover'/'automatic' or 'unattended' mode

by specifying the RECOVERY_COMMANDS array, see
https://github.com/rear/rear/blob/master/doc/user-guide/11-multiple-backups.adoc#how-to-recover-with-multiple-backups-in-auto_recoverautomatic-or-unattended-mode

jsmeix commented at 2025-07-29 12:57:¶

Regarding '-c' see my current understanding in
https://github.com/rear/rear/pull/3070#discussion_r2238864312
excerpts

When a ReaR recovery system was made e.g. by

# rear -c /etc/rear_this mkbackup

then the ReaR recovery system is usually specific
for the configuration in /etc/rear_this
...

So "rear recover" only works when it is called as

# rear -c /etc/rear_this recover

but then it does not make sense to have
/etc/rear_this and /etc/rear_that
in the ReaR recovery system.

So the contents of /etc/rear_this get stored
in the ReaR recovery system in /etc/rear
and "rear recover" does not work with '-c'.

Currently it is not sufficiently documented
how '-c' is meant to work.
Additionally "rear -c DIRECTORY WORKFLOW"
should abort with a meaningful error message
for all workflows when it is run inside
the ReaR recovery system.

jsmeix commented at 2025-07-29 13:03:¶

I think I can implement for ReaR 3.0 the missing pieces

document how '-c' is meant to work
abort when '-c' is used inside the ReaR recovery system

so I moved the milestone from ReaR 3.1 to ReaR 3.0

jsmeix commented at 2025-07-30 14:56:¶

https://github.com/rear/rear/pull/3500
implements the above item

abort when '-c' is used inside the ReaR recovery system

jsmeix commented at 2025-08-01 10:41:¶

With https://github.com/rear/rear/pull/3500 merged
the above item

abort when '-c' is used inside the ReaR recovery system

is implemented.
See
https://github.com/rear/rear/pull/3500#issuecomment-3143974480
why '-c' is not supported within the ReaR recovery system.

jsmeix commented at 2025-08-01 10:55:¶

Regarding the remaining item

document how '-c' is meant to work

While working on this issue here I did some "archaeology"
to find out how '-c' is meant to work but I found nothing except
https://github.com/rear/rear/issues/512#issuecomment-68051604

Support for '-c' was introduced via
https://github.com/rear/rear/commit/28bac7ad4e6ab67e4e955fec27fc3556082c896e
but I found nothing there which tells how '-c' is meant to work
(no comment, no linked issue, no release notes entry).

Currently I am somewhat frustrated with '-c'
so I give up here for now and close this issue
because I think the current state in master code
is (hopefully) sufficiently OK.

Perhaps over time I may get some experience how '-c' is used
in practice out there by our users so that then I could
learn from that how '-c' is meant to work.

jsmeix commented at 2025-08-01 11:12:¶

Regarding
https://github.com/rear/rear/issues/512#issuecomment-68051604
the subsequent
https://github.com/rear/rear/issues/512#issuecomment-75543135
"added to the release notes"
happened here in the GitHub 'rear/rear' repository via
https://github.com/rear/rear/commit/86009877e7ae15d768d9eb3b6d0e660118dfdf42
where this part was added to ReaR 1.17.0 doc/rear-release-notes.txt

Using rear -v -c /etc/rear/mydir mkbackup works fine in production,
but when you try (once booted from rescue image)
rear -v -c /etc/rear/mydir recover it will fail.

  • Workaround:

The configuration files are copied to /etc/rear/ into the rescue image,
so you simply need to type: rear -v recover
See issue #512

[Export of Github issue for rear/rear.]

#2942 Issue closed: '-c' and '-C' options are ignored with 'automatic/auto_recover' and 'unattended' modes¶

jsmeix opened issue at 2023-02-21 13:19:¶

jsmeix commented at 2023-02-21 13:28:¶

schlomo commented at 2023-02-21 19:59:¶

jsmeix commented at 2023-02-22 09:08:¶

jsmeix commented at 2023-02-23 12:41:¶

jsmeix commented at 2023-02-23 12:49:¶

jsmeix commented at 2023-02-23 12:55:¶

jsmeix commented at 2023-03-01 13:28:¶

github-actions commented at 2023-05-01 02:21:¶

github-actions commented at 2023-07-02 02:52:¶

github-actions commented at 2023-09-02 01:59:¶

github-actions commented at 2023-11-04 02:03:¶

jsmeix commented at 2023-11-20 12:46:¶

jsmeix commented at 2023-12-06 13:51:¶

github-actions commented at 2024-02-05 02:07:¶

github-actions commented at 2024-04-07 02:06:¶

github-actions commented at 2024-06-08 02:11:¶

gdha commented at 2024-09-05 07:21:¶

jsmeix commented at 2024-09-05 07:53:¶

github-actions commented at 2025-02-19 02:35:¶

github-actions commented at 2025-04-23 02:51:¶

github-actions commented at 2025-06-24 03:07:¶

jsmeix commented at 2025-07-28 08:41:¶

jsmeix commented at 2025-07-29 12:54:¶

jsmeix commented at 2025-07-29 12:57:¶

jsmeix commented at 2025-07-29 13:03:¶

jsmeix commented at 2025-07-30 14:56:¶

jsmeix commented at 2025-08-01 10:41:¶

jsmeix commented at 2025-08-01 10:55:¶

jsmeix commented at 2025-08-01 11:12:¶

#2942 Issue `closed`: '-c' and '-C' options are ignored with 'automatic/auto_recover' and 'unattended' modes¶