#1045 PR `closed`: Borg as back end, now accepts options for repository encryption.¶

Labels: enhancement, fixed / solved / done

gozora opened issue at 2016-10-20 19:39:¶

borg as back end, now accepts options for repository encryption.
prune now only affects archives with BORGBACKUP_ARCHIVE_PREFIX

gozora commented at 2016-10-20 20:04:¶

Hello all,
This patch adds possibility for remote Borg repository encryption.
I have however some mixed feelings about it.
The thing on my mind is that we agreed in #1037 that we will mirror Borg defaults. (e.g. "none" compression will be used by default). Borg however uses encrypted repositories by default, which adds some additional complexity (manual repository initialization and entering pass-phrase for every repository operation like purging, listing, backing up). I've found couple of ways how to avoid all this (they are described here), but like I said, mixed feelings...

In my opinion bare metal restore is quite complex task, where lot of things can go wrong, and I really don't like adding more burden to quite stressed admin as they already have on their shoulders when dealing with restores (maybe because I'm one of them ;-) ). One such things could possibly be encrypted backups.

For this reason I'd like to ask for you opinion, if we could set none encryption as a default for ReaR and let users to enable encryption only if they really need to and possibly know what they are doing.
.
Thanks!

V.

jsmeix commented at 2016-10-21 08:52:¶

I think we can set none encryption as a default for ReaR
because also for 'tar' there is no encryption and I assume
also for most other backup methods there is no encryption
so that I assume ReaR users would expect no encryption
by default.

Furthermore I think a basic idea behind ReaR is that the
actual recovery is as simple as possible, cf.
"A note on the meaning of 'Relax' in 'Relax-and-Recover'" in
https://en.opensuse.org/SDB:Disaster_Recovery
(excerpts):

... after an experienced admin had set it up ...
...
When now a real disaster happens, even a
relatively unexperienced person can do the
recovery on the replacement hardware
(boot the rear recovery system, log in  as root,
 run "rear recover", and finally reboot).

@gozora
currently this branch has conflicts that must be resolved:
Conflicting files: usr/share/rear/conf/default.conf

If you resolve the conflict, I would "just merge" it.

gozora commented at 2016-10-21 10:49:¶

Jey, my first conflict, let me see :-)

gozora commented at 2016-10-21 10:52:¶

Ok, looks like I've payed attention during my Git classes :-), conflict resolved.
I'll update defaults for encryption later today.

Thanks for now!

jsmeix commented at 2016-10-21 11:46:¶

@gozora
strange, when I click in this issue in the GitHub
web-fontend on "Files changed" I still see in
usr/share/rear/backup/BORG/default/50_make_backup.sh
and in
usr/share/rear/conf/default.conf
your changes from https://github.com/rear/rear/pull/1044
that are already merged into rear master
so that I wonder if it has now really no conflicts?

gozora commented at 2016-10-21 12:04:¶

Well, this conflict was rather strange. The conflict looked something like this:

<<<<<<< HEAD
=======
+BORGBACKUP_COMPRESSION=""
 +# Borg encryption type
 +# Types: none, keyfile, repokey
 +# none: encryption is disabled (least trouble with setup, least security)
 +# keyfile: passphrase and having-the-key (stored on client in /$HOME/.config/borg/keys/)
 +# repokey: passphrase-only (stored on server BORGBACKUP_REPO/config)
 +# Default: repokey
 +BORGBACKUP_ENC_TYPE=""
>>>>>>> <hash>

So to my understanding no conflict at all. I just removed <<<<<<< HEAD, ======= and >>>>>>> <hash>
git add .
git commit

and that is it ...

Maybe you've saw behavior like this already?

gozora commented at 2016-10-21 12:08:¶

@jsmeix let's try to close this pull request and open new one,
What do you say?

gozora commented at 2016-10-21 12:17:¶

@jsmeix FYI, by just clicking "new pull request", usr/share/rear/backup/BORG/default/50_make_backup.sh is not between changed files any more.
So new, pull request might solve this ...

jsmeix commented at 2016-10-21 12:46:¶

@gozora
feel free to do it as it is best for you.
I think you can close this request yourself if you like
(I assume the one who creates it can also close it
but I cannot know how GitHub behaves for you).

gozora commented at 2016-10-21 13:00:¶

#1046 was opened instead.

[Export of Github issue for rear/rear.]

#1045 PR closed: Borg as back end, now accepts options for repository encryption.¶