Move backup-related variable defaults from the database roles into the
borg_client role. Also check group membership to guard installation of
database backup helper scripts.

Using GitLab's official backup tool takes too much time and, more
importantly, space; /srv/gitlab is a bit over 430G but backing it
up nearly exhausts its 1TB volume.

As we're creating btrfs snapshots and backing those up with borg, it
seems unnecessary to also create tarballs of the same data. GitLab's
documentation mentions snapshots as a viable backup strategy, and to
the restored system it should seem like recovering from a power loss.

[1] https://docs.gitlab.com/ee/raketasks/backup_restore#alternative-backup-strategies

These are already known (so no need to hide them) and are fairly static
(so variables are more of a hindrance) so it's better to use the actual
usernames in the documentation. Also, simplify the first example given.

New username; separate and longer account manager + storage passwords.

Also, have to use --remote-path=borg1 when interacting with rsync.net.

Jelle van der Waa authored 4 years ago and Sven-Hendrik Haase committed 3 years ago

Document how we backup our databases/gitlab instances.

This offers improved separation between the server backups and should
avoid bumping against the storage box 10 concurrent connection limit.

Fixes: archlinux/infrastructure#362