[Borgbackup] borgbackup 1.2.0a5 alpha release

[Thorsten von Eicken]

Let me try to understand... Are the following statements correct WRT a 
pull model?

- you want a central schedule on the server, specifically, have the 
server decide when each client should start its backup

- you want the server to hold the credentials to log into the clients, 
not the other way around

- you're OK with installing some form of backup software on each client

If the above is all true, then this should be pretty easy to implement 
(famous last words). Borg already supports a client/server model with 
`borg serve`, the catch is that currently it's one-way: the client 
connects to the server using ssh. But what if you did the following:

- on the server, ssh to each client in turn and run `borg create` on the 
client that way, while you start a `borg serve` on the local end of the 
ssh connection/tunnel for the client to use

- instead of using a remote repository in `borg create`, tell it to talk 
to `borg serve` on the already-open ssh connection, or alternatively, on 
an ssh tunnel connection opened at the same time

- for prototyping purposes, use the `--rsh` option to `borg create` to 
tell it to use the tunnel, there must be some combo of 
cat/nc/netcat/socat that should be able to do the trick.

By using the appropriate `--restrict` option to `borg serve` you can 
limit which repositories each client has access to. What borg doesn't 
support is fine-grained control over a shared repository (perhaps adding 
an option to `borg serve` to force an archive name prefix could help), 
but there is the `--append-only` flag.

Thoughts?

Thorsten

On 3/26/19 10:34 AM, Ken Bass wrote:
> 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.
>
> _______________________________________________
> Borgbackup mailing list
> Borgbackup at python.org
> https://mail.python.org/mailman/listinfo/borgbackup
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/borgbackup/attachments/20190326/cf03b92f/attachment.html>