#2811 PR merged: Add PRE_RECOVERY_COMMANDS and POST_RECOVERY_COMMANDS

Labels: enhancement, fixed / solved / done

jsmeix opened issue at 2022-05-23 13:13:

  • Type: Enhancement

  • Impact: Normal

  • Reference to related issue (URL):
    https://github.com/rear/rear/pull/2735

  • How was this pull request tested?
    Not yet tested.

  • Brief description of the changes in this pull request:

This is basically same as
https://github.com/rear/rear/pull/2735
but without PRE_BACKUP_COMMANDS and POST_BACKUP_COMMANDS

For the reasoning see
https://github.com/rear/rear/pull/2735#issuecomment-1134686196

pcahyna commented at 2022-05-24 10:17:

@rmetrich what do you think? The advantage of this approach is that it avoids the problematic part of #2735 and still allows to make progress with the arguably more important part: recovery commands. (The disadvantage is that it introduces an asymmetry between PRE/POST_RECOVERY and PRE/POST_BACKUP.)

@jsmeix I don't entirely agree with your assessment that

Because all users with third-party backup methods
cannot use PRE_BACKUP/POST_BACKUP
but must use something outside of ReaR
(...)
I assume users won't have problems with calling
(outside of ReaR) the right perparation commands
before they call "rear mkbackup[only]"
and the right cleanup commands
after "rear mkbackup[only]" finished
so PRE_BACKUP/POST_BACKUP is no needed functionality in ReaR

This may be true for mkbackuponly but not for mkbackup: one may have a need to execute a command after the rescue image is created, but before the backup is taken, and there is no way to do that with mkbackup other than using PRE_BACKUP. (One might circumvent it by splitting the task into mkrescue && mkbackuponly, but we saw recently that separating backup from layout creation has its own problems.)

jsmeix commented at 2022-05-25 12:06:

Regarding

The disadvantage is that it introduces an asymmetry
between PRE/POST_RECOVERY and PRE/POST_BACKUP

The asymmetry is an unfortunate consequence because
PRE/POST_RECOVERY behave different than PRE/POST_BACKUP
because the latter "mess around" with exit tasks
and that different behaviour results that
PRE/POST_BACKUP_COMMANDS cannot be cleanly implemented
(at least not with reasonable effort).

jsmeix commented at 2022-05-25 12:13:

Regarding

one may have a need to execute a command
after the rescue image is created,
but before the backup is taken,
and there is no way to do that
with 'mkbackup' other than using PRE_BACKUP

Yes, you are right.
The only way would be

rear mkrescue && COMMAND && rear mkbackuponly

Regarding

separating backup from layout creation has its own problems

yes, but only if the basic system was changed
between backup and layout creation, so

rear mkrescue && COMMAND && rear mkbackuponly

should be reasonably safe
(provided COMMAND does not change the basic system).

By the way:
What is also not such a good idea is
to change the basic system
while "rear mkbackup" is running :-)

jsmeix commented at 2022-06-01 08:32:

I included the changes from https://github.com/rear/rear/pull/2789
so this pull request would obsolete the other one
if this pull request could be merged.

@pcahyna @rmetrich
if you do not object against it I would like to merge
this pull request tomorrow afternoon
because it is at least a step forward and
it solves the initially reported issue in
https://github.com/rear/rear/pull/2735#issue-1089733641

[Export of Github issue for rear/rear.]