#2008 PR `merged`: Add possibility to fine tune some of Borg output¶

Labels: enhancement, fixed / solved / done

gozora opened issue at 2018-12-19 17:51:¶

Pull Request Details:¶

Type: Enhancement
Impact: Low
Reference to related issue (URL): https://github.com/rear/rear/issues/2007
How was this pull request tested?
Checked output of rear mkbackuponly on Fedora 26
Brief description of the changes in this pull request:
Add possibility for user to specify whether or not show Borg stats at the end of backup session.
Add possibility for user to specify whether or not show Borg backup session progress.
Corrected URL to Borg backup environment variables documentation.

gozora commented at 2018-12-19 18:01:¶

@jsmeix please just a quick look of your bug capturing sight! ;-)

jsmeix commented at 2018-12-20 11:22:¶

@gozora
I wonder if separated BORGBACKUP_SHOW_PROGRESS
and BORGBACKUP_SHOW_STATS are really needed?

Wouldn't a single config vatiable BORGBACKUP_CREATE_OPTIONS
be more generic any more versatile where the user could specify
any addiotional options for the borg create call as he likes it?

I.e. in backup/BORG/default/500_make_backup.sh
remove all code related to borg_additional_options
and have only

borg create $verbose --one-file-system $BORGBACKUP_CREATE_OPTIONS ...

plus documentation in default.conf about BORGBACKUP_CREATE_OPTIONS
that is by default empty.

This way the user could specify in his etc/rear/local.conf

BORGBACKUP_CREATE_OPTIONS="--progress --stats"

or whatever he needs and likes in his particular case
even up to more sophisticated stuff like

test "$VERBOSE" && BORGBACKUP_CREATE_OPTIONS="--stats"
test "$DEBUG" && BORGBACKUP_CREATE_OPTIONS="--progress --stats"

To stay backward compatible with the current behaviour
the default setting in default.conf would have to be

test "$VERBOSE" && BORGBACKUP_CREATE_OPTIONS="--progress --stats"

but I won't mind if the current behaviour is changed by this pull request.

gozora commented at 2018-12-20 12:15:¶

Hello @jsmeix,
Thanks for your checks!

I wonder if separated BORGBACKUP_SHOW_PROGRESS
and BORGBACKUP_SHOW_STATS are really needed?

I guess it is matter of taste. I think BORGBACKUP_CREATE_OPTIONS can be misleading.
It can create illusion to specify some additional options for Borg that are not intended or might not work correctly with ReaR. E.g. one might use Borgs --exclude-from instead of ReaRs native include/exclude system ...
It might surprise you, but I'm not Borg user as well, I just liked the deduplication idea in ReaR.
On top of this, by having explicit Borg options (BORGBACKUP_*) in ReaR I'm forced once in a while (when ReaR issue is open) to revisit Borg project and check for news in current version ;-).

V.

jsmeix commented at 2018-12-20 13:39:¶

@gozora like many time before your guess is right!

Of course it is a matter of taste and you implement it as you prefer.
I approved it, so feel free to merge it in its current form.

I only liked to tell you about my thoughts.

I think when the user specifies ReaR config variables, he is responsible
for what he specifies because current ReaR is not at all fool-proof
because current ReaR is meant for experienced users.

Only out of curiosity:
What would go wrong if the user wants to specify Borg's --exclude-from
directly instead of using ReaR's native include/exclude system?
E.g. would it conflict with --exclude-from $TMP_DIR/backup-exclude.txt
and let borg create fail with non-zero exit code which lets "rear mkbackup"
error out which would be perfectly o.k. because the user would see that
he cannot use Borg's --exclude-from directly.
Or may it silently result a bad/broken/corrupted Borg backup?

gozora commented at 2018-12-20 16:27:¶

I think when the user specifies ReaR config variables, he is responsible
for what he specifies because current ReaR is not at all fool-proof
because current ReaR is meant for experienced users.

And it is good so, because it copies famous quote about Unix: "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things."

Only out of curiosity:
What would go wrong if the user wants to specify Borg's --exclude-from
directly instead of using ReaR's native include/exclude system?
E.g. would it conflict with --exclude-from $TMP_DIR/backup-exclude.txt
and let borg create fail with non-zero exit code which lets "rear mkbackup"
error out which would be perfectly o.k. because the user would see that
he cannot use Borg's --exclude-from directly.
Or may it silently result a bad/broken/corrupted Borg backup?

As far as I know (but I might be wrong of course, because it is some time already since I wrote this code) something like passing custom options to Borg is currently not possible. So unfortunately users might control Borg behavior only by ReaR predefined BORGBACKUP_* settings or by Borg native environment variables BORG_*.

V.

[Export of Github issue for rear/rear.]

#2008 PR merged: Add possibility to fine tune some of Borg output¶