move backups in the reference section

Those instructions are better in "Reference" because it's about the
current design, "how things work", not "how to use them".

We would still need a backup/restore howto section, that said.

tsa/howto/gitlab.mdwn

@@ -57,18 +57,6 @@ lists: <tor-dev@lists.torproject.org> would be best.
 <!-- rebuild from scratch? not necessarily those procedures (e.g. see -->
 <!-- "Installation" below but some pointers. -->
 
-## Backups
-
-There is a cronjob configured via the gitlab puppet monitor that runs every night
-at 2.00 AM UTC
-
-This will basically run `$ gitlab-backup ` and will create a tarball under:
-`/srv/gitlab-backup/`
-
-There is also a config backup job that makes sure to backup the content of
-`/var/opt/gitlab/gitlab-rails/etc/`
-
-
 # Reference
 
 ## Installation
@@ -272,6 +260,23 @@ There is no issue tracker specifically for this project, [File][] or
 <!-- describe how this service is monitored and how it can be tested -->
 <!-- after major changes like IP address changes or upgrades -->
 
+## Backups
+
+There is a cronjob configured via the gitlab puppet monitor that runs
+every night at 2:00AM UTC. This will basically run `$ gitlab-backup `
+and will create a tarball under `/srv/gitlab-backup/`.
+
+There is also a config backup job (in
+`/etc/cron.d/gitlab-config-backup`) that makes sure to backup the
+content of `/var/opt/gitlab/gitlab-rails/etc/` is backed up, because
+that is not covered by the `gitlab-backup` command.
+
+Another cron job purges backups older than two days, in
+`/etc/cron.d/gitlab-rotate-backup`, so that we don't keep too many
+copies on the server. It is assumed that the existing [[backups]]
+system will pick up those copies and store them for our normal
+rotation periods.
+
 # Discussion
 
 ## Overview