[arch-devops] Secondary backup ideas

Thore Bödecker me at foxxx0.de
Thu Jan 11 19:17:13 UTC 2018


Hey,

On 11.01.18 - 17:54, Florian Pritz via arch-devops wrote:
> Does anyone have other ideas what we could do here to ensure that we
> have backups of the backups? The most important requirements are that no
> matter which server an attacker manages to get access to, they cannot
> read any user data from other servers and that they cannot remove all
> backups from that server alone.

Do we have the same contraints/requirements for the secondary (backup)
backups, that we have for the current primary ones?
That is, do we need to have the same intervals for the secondary as
for the primary?

(I'm going to explore all ideas even if already determined "not optimal")

What I first had in mind sadly does not work properly in the long run
after thinking it through:

Rent a second server (let's call it "B"), that is being push-rsync'ed from
vostok.
Here we could use rrsync to deny deletion of files on "B", so that
even if vostok is compromised, the attacker could not do something
like:
rsync --delete -a /empty B:/the/precious/backups/

The problem with is: we lose the ability of borg prune cleanups and
the backups on "B" would continue to grow and grow and grow....
(It is not possible to use find -mtime +90 or similar due to the
nature of borg)


Second idea:

Use rsnapshot or similar pull-based backups on "B" to pull the data
from vostok.
The access permissions of "B" would need to be limitied to "read only"
on vostok, so that an attacker on "B" is not able to delete antyhing
on vostok.
It *would* be possible to do something like rsync --delete-after now,
so that the local copy on "B" would also be cleaned up, but this has
another caveat:
If vostok gets compromised and the attacker deletes all backups there,
a subsequent rsync from "B" would propagate the deletion to "B" and
all backups would be lost.
So we are back at the problem of missing cleanup abilities again.


Third idea:

Use a different backup interval on the individual servers and use borg
to push the backups to "B".
Doing all backups twice with the same interval would create a
considerable (at least double) amount of backup-data.
Ideally we would deny prune/delete through borg on "B", so that even
if a server gets compromised, the attacker would not be able do delete
the backups of that server on "B".
This in turn would again result in continuesly growing backup/archive
space.


Another thing I would like to mention:

It would be best to use a completely different backup-software AND
filesystem for the secondary backups.
So that even if there happens to be a real bad in borg or the the
filesystem where our current borg backups reside on (I suppose ext4?),
it would ensure that our secondary backups remain unaffected by that.


Unfortunately I have no complete solution for the concers raised by
Bartłomiej and Florian (yet).

I hope that someone might be able to pick up where I left off with my
ideas and can put them into proper concepts.


Cheers,
Thore


-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-devops/attachments/20180111/c25ac696/attachment.asc>


More information about the arch-devops mailing list