[arch-devops] Secondary backup ideas

[Florian Pritz]

On 11.01.2018 18:32, Archange wrote:
> I haven’t digged deep into borg doc, but I suppose there is no mode
> where only the client has the encryption/decryption key, but only the
> server can remove data? If e.g. backup date metadata is available to the
> server this could be done, but I don’t know how it works exactly so…

Borg stores pretty much everything, including metadata, in encrypted
form so to do any cleanup you need to have the key. Also AFAIK it only
supports a single key.

> I’m not sure how that works technically speaking, but I suppose that for
> AWS Glacier you intend to use borg append-only mode to avoid an attacker
> deleting the backups? How would the cleaning work in this case? We would
> just not care about it because Glacier?

If we were to use glacier, we would upload tarballs, not borg repos. We
would use `borg export-tar` to create the tarball from the repo though,
but that's really just a minor detail. It creates a normal tarball in
the end. That would then be encrypted with GPG or something and uploaded
to glacier.

Cleanup would either work via a dedicated access key to glacier or via
automated cleanup rules inside glacier. I'm not sure if cleanup rules
are generally supported or if they are only available in special cases,
but dedicated accounts should work.

It's mostly an idea and not yet tested. I actually dislike the part
where it uploads the whole tarball each time. At least for orion that
would be ~200GiB and even with 1Gbit/s that takes roughly 30 minutes,
but that would probably impede performance too much. Also it will get
worse if we ever add more data. In total I'm not too happy with this.

> In your ideas #1 and #2, it seems to me that an attacker gaining access
> to vostok is able to remove all backups from all servers, right?

Good point. vostok has a much smaller attack surface (just ssh and
zabbix-agent) than the other machines, but this is certainly not ideal.
With #1 and #2 vostok would have access to remove the files so we really
just moved the problem. Still better than what we have right now, but
not great.

Glacier with separated upload and removal accounts/access keys would be
better here.

I'll think some more about that. Thanks!

Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 858 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-devops/attachments/20180111/c4304835/attachment-0001.asc>