Added PRE-POST backup scripts

[didacog]

Hello,

Those changes add the capacity in rear to stop/start some services or run some required tasks previous to run backup (just like those exist for recovery), this can be useful in some scenarios if, for example, a small database that can be stopped and it's data will be consistent after OS recovery without human intervention.

I've tested and forced error between pre and post to check correct behaviour of Exit Tasks in case of any error during backup if, for example, some service stopped in PRE can be started by Exit Tasks array.

Following changed:

new file: usr/share/rear/backup/default/01_pre_backup_script.sh

if test "$PRE_BACKUP_SCRIPT" ; then
    Log "Running PRE_BACKUP_SCRIPT '${PRE_BACKUP_SCRIPT[@]}'"
    AddExitTask "${POST_BACKUP_SCRIPT[@]}"
    eval "${PRE_BACKUP_SCRIPT[@]}"
fi

new file: usr/share/rear/backup/default/99_post_backup_script.sh

if test "$POST_BACKUP_SCRIPT" ; then
    Log "Running POST_BACKUP_SCRIPT '${POST_BACKUP_SCRIPT[@]}'"
    RemoveExitTask "${POST_BACKUP_SCRIPT[@]}"
    eval "${POST_BACKUP_SCRIPT[@]}"
fi

modified: usr/share/rear/conf/default.conf

# Call this after Relax-and-Recover finished to do anything in the mkbackup/mkbackuponly workflow.
POST_BACKUP_SCRIPT=

# Call this before Relax-and-Recover starts to do anything in the mkbackup/mkbackuponly workflow.
PRE_BACKUP_SCRIPT=

required configuration on /etc/rear/local.conf:

PRE_BACKUP_SCRIPT="/path_to_scripts/pre_scr.sh"
POST_BACKUP_SCRIPT="/path_to_scripts/post_scr.sh"

Kind regards,

Didac

[jsmeix]

@didacog
I do not understand why you have the AddExitTask()
and RemoveExitTask() calls, cf.
"Code should be easy to understand"
in https://github.com/rear/rear/wiki/Coding-Style

Such calls are not used in the implementation for
PRE_RECOVERY_SCRIPT and POST_RECOVERY_SCRIPT
in setup/default/01_pre_recovery_script.sh
and wrapup/default/50_post_recovery_script.sh

In particular

if test "$PRE_BACKUP_SCRIPT" ; then
    ...
    AddExitTask "${POST_BACKUP_SCRIPT[@]}"

looks like a typo.

But I guess it is intentionally that POST_BACKUP_SCRIPT
is added as exit task when PRE_BACKUP_SCRIPT is non-empty
but I do not understand why - i.e. I do not understand how it is
meant to work - i.e. why is not PRE_BACKUP_SCRIPT
and POST_BACKUP_SCRIPT only called as in the
implementation for PRE_RECOVERY_SCRIPT
and POST_RECOVERY_SCRIPT?

[jsmeix]

@didacog
I assume when you add your usecase description here in your
#977 (comment)
in a bit more explanatory way to default.conf then I
(and all other rear users) would understand how
PRE_BACKUP_SCRIPT and POST_BACKUP_SCRIPT
are meant to be used.

[didacog]

@jsmeix

Is not a typo, for example:
In case you are stopping a small mySQL database in order to maintain its data consistency with rear backup, you want to re-start it again after backup.
It will be done in 99_post_backup_script.sh if all tasks between 01 and 99 of backup stage are ok, but if some error occur in the meantime, ExitTasks will do it.

In case of no POST tasks, nothing will happen anyway.

I don't know if I explained well.

Regards,

[didacog]

@jsmeix

I've updated default.conf with explanation about PRE POST backup.

Hope this will be ok. ;)

regards,

[jsmeix]

Hooray!
Now even I understand it
and - with pleasure - I can "just merge" it :-)

@didacog
many thanks for your vaulable contribution!

[didacog]

Cool!! thanks!!! ;)

[jsmeix]

@didacog
I like all those various little helper functionality in Relax-and-Recover
very much. Usually it is not needed but when it is needed it is
a priceless advantage to have them available, cf.
NETWORKING_PREPARATION_COMMANDS
RECOVERY_UPDATE_URL
BACKUP_RESTORE_MOVE_AWAY
they all do not make anything "just work out of the box"
but in case of special issues they can (hopefully) help.

[jsmeix]

@gdha
This one got merged into rear:dev.
Now I wonder about the procedure
how to decide if it also gets merged into rear:master and
if yes, how to actually get it merged into rear:master?

[gdha]

@didacog @jsmeix @schlomo Pull requests who made it in the dev branch should first go through a QA test before we allow it in the master branch. That is the idea behind it. I do not want to cripple a release with untested commits.Otherwise, we will never come to a stable release IMHO. If it doesn't make it for this release it will be for another. However, do not yet panic.
I'm trying to setup an automatic testing bed for rear (but it will take time)

[didacog]

@gdha sounds good for me. We are working in that way in DRLM also.

We use git-flow to manage: release tagging, hotfixes and features on branches from dev until merged to master.

If we can help in some way we'll be pleased to do It.

Regards,