#1044 PR merged: BORGBACKUP_COMPRESSION now handles Borg compression defaults correctly

Labels: fixed / solved / done, minor bug

gozora opened issue at 2016-10-20 13:55:

Improvements in default compression handling discusses in #1041

jsmeix commented at 2016-10-21 08:42:

Now it behaves perfectly - as far as I can see.

jsmeix commented at 2016-10-21 09:01:

@gozora
a general comment regarding specific variables
for specific backup program option settings:

I think you could completely remove
BORGBACKUP_COMPRESSION
and support instead two generic
BORGBACKUP_CREATE_OPTIONS=()
BORGBACKUP_EXTRACT_OPTIONS=()
where the user can specify any options he wants
for "borg create" and "borg extract".

This way you would be automatically future-proof and
avoid an possibly endless sequence of user requests
to support this and that and those further specific Borg
backup program option settings.

gozora commented at 2016-10-21 11:05:

@jsmeix actually I was thinking about such setup, but decided to go different way. Thinking of it now, it really could be easier.
I'll check that, thanks!

jsmeix commented at 2016-10-21 12:06:

@gozora
FYI regarding how to use and implement multiple
program options settings via an array variable
you may have a look at
https://github.com/rear/rear/pull/912

I think I vaguely remember that quoting with " as in

COMMAND ... "${BACKUP_PROG_COMPRESS_OPTIONS[@]}" ...

could be crucial, cf.
http://stackoverflow.com/questions/3348443/a-confusion-about-array-versus-array-in-the-context-of-a-bash-comple

gozora commented at 2016-10-21 12:23:

@jsmeix thanks for hint!

gozora commented at 2016-10-23 13:47:

@jsmeix

I think you could completely remove
BORGBACKUP_COMPRESSION
and support instead two generic
BORGBACKUP_CREATE_OPTIONS=()
BORGBACKUP_EXTRACT_OPTIONS=()
where the user can specify any options he wants
for "borg create" and "borg extract".

Now I maybe know why I've abandoned this idea.

It would require to add 5 different variables for each type of Borg operations (init, create, prune, list, extract). The code I've wrote relies on some options in use (I did not tested what would happen if some options are omitted).
As an example let's have a look on borg create and borg prune.
I've used variable BORGBACKUP_ARCHIVE_PREFIX to define archives that have been created by ReaR. So every time you run rear mkbackup, archive with name BORGBACKUP_ARCHIVE_PREFIX_<incremented_archive_id> is created in Borg repository. User can add arbitrary new archives to this repository (and do restore from then with rear recover), but with such naming convention we will know which archives has been created using ReaR. This property is used e.g. during borg prune (which cleans repository according user defined settings) to avoid removing of user created archives. (ReaR will prune only archives with prefix BORGBACKUP_ARCHIVE_PREFIX_).
To cut the story short, from my point of view, current code is more straight forward to configure, easier to maintain and easier to look for a bugs ...
Let us just wait for first users to report some issues and flat down the code after we have some feedback from actual testing use.

[Export of Github issue for rear/rear.]