[Borgbackup] questions about append-only mode repository

[Marian Beermann]

Hi Christian,

On 9/29/18 9:37 AM, C L wrote:
> Hi Folks!
> 
> I've been trialing borgbackup 1.1.x for a short time now and found it to
> be ticking all the boxes so far.
> 
> However I'm trying to wrap my head around use-cases for append-only mode
> when it applies to multiple client machines accessing a central remote
> repository and whether this functionality is currently feature complete
> or should even be used in such scenarios.

append-only mode is a misfeature that was implemented because everyone
assumed the "proper solution" was only a few months away (a common theme).

It exposes a low-level implementation detail and requires a lot of
low-level knowledge about borg to use "correctly".

> Based on what I've read in the documentation, a repository can be made
> “append-only”, which means that Borg will never overwrite or delete
> committed data.  However, the documentation continues with an example of
> a compromised client machine that has remotely deleted backups from the
> repository.
> 
> On the surface of it, I would expect an append-only repository to deny
> any remote "borg delete" or "borg prune" commands to occur from any borg
> client.
> 
> Instead from the documentation a "soft-delete" is permitted on the
> repository and the transaction logged.  Such "soft-deleted" transactions
> are (silently?) processed only when the repository is accessed in a
> non-append-only mode with an appropriate "borg {delete,prune,create}"
> command, typically executed from a more trusted machine than the client
> machines.
> 
> For an non-compromised client machine running a scheduled backup job
> which applies it's own "borg prune" rules onto archives prefixed by it's
> hostname seems like overkill considering the administrator would have to
> run "borg prune" from a more trusted machine and apply it across all the
> archives in the repository, irrespective of prefix.
> 
> A potential race condition exists between a compromised, but undetected,
> client machine that has "soft-deleted" archives from the repository and
> the trusted machine that next "borg prunes" the repository.

Correct.

> There is obviously a sliding scale with:
> 
>   * the level of trust/risk that any client machine has to the
>     repository; and
>   * on the amount of work an administrator must perform to maintain
>     backup sets and yet provide some flexibility with global/per-client
>     machine retention policy; and
>   * to detect and react to compromised client machines which have access
>     to the repository.
> 
> To the borg assimilated community, I have the current questions:
> 
>  1. As currently implemented, are append-only mode repositories just
>     more work to maintain with little reward, or is that just my
>     initial, inexperienced impression with borg?
Yes.

>  2. What real-world use-cases is an append-only mode repository with
>     prunes (no plums involved haha) actually being used, if at all?

Without additional, external tooling (locking out untrusted clients for
maintenance, running checks on archives, comparing to what should be
there etc.) it is not a useful feature if things ought to be deleted at
some point.

>  3. Is the documentation missing a really obvious point with append-mode
>     repositories that is clear to everyone having expert borg knowledge
>     but hasn't occurred to those with novice borg knowledge?

Understanding append only mode requires knowledge of at least all the
internal docs. So, yeah.

>  4. Was the implementation of an append-only mode feature a knee-jerk
>     reaction to "fix" something without addressing the real core
>     problem/risk underlying the feature requested (i.e.: mitigating the
>     risk destructive operations has to a repository from borg clients on
>     untrusted/semi-trusted client machines)?

Correct.

> 
> Sincerely, and with great respect.
> 
> Christian
> 

Cheers, Marian