#1048 PR merged: Improvements in handling of encrypted Borg repositories¶
Labels: enhancement, fixed / solved / done
gozora opened issue at 2016-10-24 08:43:¶
- introduced BORGBACKUP_PASSPHRASE, to send pass-phrase to Borg using environment variable
- logic of Borg backup work-flow was reordered, now we are able to COPY_AS_IS_BORG keyfile to Relax-and-Recover rescue/recovery system
- Introduced BORGBACKUP_REMOTE_PATH, which sets location of Borg binary on remote server. Borg can be now installed to arbitrary location
- default encryption is now "none" (see comment)
gozora commented at 2016-10-24 08:45:¶
Update of documentation will follow soon ...
jsmeix commented at 2016-10-24 09:36:¶
@gozora
now you introduce some all-caps variables like
OPT_COMPRESSION, OPT_PRUNE, OPT_REMOTE_PATH,
and ARCHIVE_CACHE that I find nowhere else in current ReaR.
I assume these variables are currently only used for BORG
but they look as if they are intended for a more general
usage also for other backup methods because they
have no "BORG_" prefix.
I would like to know how those variables are meant to be used.
gozora commented at 2016-10-24 10:21:¶
I assume these variables are currently only used for BORG
Yes that is correct, scope for these variables is intended only for
Borg. The reason why they are all caps is that I've try to follow ReaR
conding
style.
"All variables that are used in more than a single script must be
all-caps:"
I've decided not to prefix them with BORGBACKUP_ as they are not
intended to be configured by default.conf.
I can of course change them, so their use become more obvious.
Do you have any preference?
Thanks
V.
jsmeix commented at 2016-10-24 11:18:¶
@gozora
all-caps is fine for me - but because that indicates some kind
of "global" usage (strictly speaking in more than one script)
I would prefer a prefix when it is "not so much global"
to indicate that it is only meant "global" for BORG.
For example we have already
BACKUP_PROG_COMPRESS_OPTIONS
and now the OPT_COMPRESSION may cause
some confusion what each one is about.
In contrast when you use BORG_OPT_COMPRESSION
or BORGBACKUP_OPT_COMPRESSION (as you like)
the distinction is clear.
Only some offhanded thoughts for the future:
Alternatively one could perhaps use the existing
BACKUP_PROG_COMPRESS_OPTIONS array
also for other backup methods like Borg Backup?
But currently default.conf states that
BACKUP_PROG_COMPRESS_OPTIONS
belongs only to "internal BACKUP stuff".
Perhaps this could become a good example how one
could use existing variables also for other backup methods?
If one likes to use BACKUP_PROG_COMPRESS_OPTIONS
also for other backup methods one would first of all need to
change ReaR so that the current default '--gzip' is no longer
set in default.conf so that it is empty there.
Then for each backup method its particular default
could be set in a script of each backup method if
BACKUP_PROG_COMPRESS_OPTIONS is empty.
For each backup method a comment in default.conf
would tell about the default.
As far as I know currently the various backup methods
are implemented mostly separated from each other.
"Mostly" because e.g. 'tar' and 'rsync' both use
e.g. BACKUP_PROG_COMPRESS_OPTIONS, cf.
usr/share/rear/backup/NETFS/default/50_make_backup.sh
Perhaps it is better to keep different backup methods separated?
(I.e. avoid RFC 1925 item 5 and keep separated things separated.)
Perhaps it is better to do common things via same variables?
(E.g. see also
https://github.com/rear/rear/issues/823)
Currently I don't know...
gozora commented at 2016-10-24 11:33:¶
Perhaps it is better to keep different backup methods separated?
(I.e. avoid RFC 1925 item 5 and keep separated things separated.)Perhaps it is better to do common things via same variables?
(E.g. see also #823)
In my opinion they should remain separated, it is maybe nicer to have one variable for multiple backups but, this can cause some trouble connected with introducing more and more complicated code when new features will be build into ReaR.
For new variable names (OPT_COMPRESSION and co.) I'll prefix them with BORGBACKUP_*, to avoid confusion.
jsmeix commented at 2016-10-24 11:43:¶
I also think it is better to keep separated things separated.
In particular keeping different backup methods separated
is even more future proof, cf. "Multiple Backup Methods" in
https://github.com/rear/rear/issues/769
"Multiple Backup Methods" require separated config
variables for each backup method.
jsmeix commented at 2016-10-25 07:52:¶
@gozora
please tell me when this pull request
is complete to be merged.
gozora commented at 2016-10-25 07:59:¶
@jsmeix sorry for my trashy development management!
You can merge this one.
(In next days I'll create one more, but that will be just introduction
of couple of Borg variables)
[Export of Github issue for rear/rear.]