[Dev] [RFC] backups

IngeGNUe ingegnue at riseup.net
Fri Jul 8 22:21:25 GMT 2016


I'm IT so I can add my 2c:

On 07/08/16 15:25, Luke Shumaker wrote:
> Hi guys,
> 
> We really need to talk about our backup infrastructure.
> 
> Some of our stuff is easy-ish to back up:
> 
>  - most git repositories can just be mirrored :
>    lukeshu.com/git, github, gitlab, ...  (I'd set this up on
>    lukeshu.com a long time ago, but I think it stopped running.
>    Setting this up with github and gitlab has been in my TODO.txt for
>    way too long).
> 
>  - /srv/repo/main is already backup up by our mirrors.  However, if
>    there were ever a problem, we wouldn't be able to roll back to a
>    backup if it already propegated to the mirrors.
> 
> But some other stuff is under-served:
> 
>  - /etc/.git: contains crypto keys, system password hashes
>  - /srv/sql: besides database passwords, the repositories contain
>    usernames and password hashes for wiki, redmine, and parabolaweb
>    users.
>  - /home
>  - /srv various files contains database passwords and the like
> 
> Who do we give this data to? 

Depends on security requirements: the only reason we (we as in,
universal) don't give everyone we meet a backup of everything, even
though the best backup strategy is propogation, is because we don't WANT
everyone to have the backups.

> If it's encrypted, who holds the
> decryption keys?  

Decryption keys are an interesting security problem. One person could
know the password and 10 could store the keys somewhere, BUT then you
have 11 times (or whatever) the chance that some cracker will find it
and brute force the keys. Since they're decryption keys, I don't recall
any way you could set a lockout for incorrect attempts.

The safest storage for keys is offline.

Parabola's non-hierarchical organization conflicts with the assumptions
of hierarchical managament most of this infrastructural software
assumes. This is a fault of the software design, not Parabola hackers.

I'm not sure how to solve this problem, but I thought I'd take a stab.

> How long do we retain backups for?  How often do we
> make them?
> 

When we figure out who to give backups to and where they're going, this
will be easy to answer.



More information about the Dev mailing list