[Borgbackup] borgbackup 1.2.0a5 alpha release

[Ken Bass]

On 3/26/2019 11:36 AM, Melkor Lord wrote:
> On 26/03/2019 08:58, Oon-Ee Ng wrote:
>
>> The assumption that the client is the risk and not the server is not 
>> shared
>> by all. In particular when the server is off-site or on a third-party
>> server, it makes sense that it be treated as untrusted (this is what 
>> borg
>> assumes based on the implementation and documentation).
>
> If the client is the risk, then having the server contacting the 
> client is secure by design. There's nothing the client can do to the 
> server to compromise it, especially if there's no entry point to the 
> server (ssh or other with appropriate firewall rules)
>
> If the server is treated as untrusted, I wouldn't put my backup data 
> there in the first place :-)

The thinking I have heard mentioned is that since you can (optionally) 
encrypt the repo, you do not need to trust the server.

>
>>   Besides, a 'sort-of' pull mode (with a capable server) can already 
>> be done
>> by remote mounting client directories on the backup server and then 
>> running
>> borgbackup from that.
>
> This is cumbersome and fragile at best! It works for the most basic 
> setups but you can forget it for more serious scenarios. For example 
> when using FS ACLs, there's no remote mounting solution supporting 
> that properly.

Personally, I think mounting client directories is not only slow, 
options open new attack vectors, but isn't a good solution either. It 
can work, but it is a kludge.

> Is there anyone here using Borg in a datacenter infrastructure? With a 
> good deal of servers pushing their data to a "central" backup server? 
> I wonder how you manage it efficiently.

This is a usability problem for me too. I have been using 'safekeep' 
which is a pull model wrapper around rdiff-backup and then use borg to 
backup that backup. Not at all a great solution but it was the only way 
I felt I could coordinate that only a single backup was running at a 
time / limit bandwidth, etc.