gitlab: document changes to the backup system (team#40517)

howto/gitlab.md

@@ -796,21 +796,31 @@ hardcoding exporters). We could also use the following tools:
 
 ## Backups
 
-There is a backup job (in the `git` user crontab) that makes sure to
-backup the content of `/var/opt/gitlab/gitlab-rails/etc/` are backed
-up. We use this instead of the backup system provided by the GitLab
-Puppet module, because that is not covered by the `gitlab-backup`
-command. This is implemented with the `tpo-gitlab-backup`, a simple
-wrapper script which calls `gitlab-backup` and performs the
-configuration backup and rotation.
+There is a backup job ( `tpo-gitlab-backup`, in the `root` user
+crontab) that is a simple wrapper script which calls `gitlab-backup`
+to dump all components of the GitLab installation (except artifacts!)
+in the backup directory (`/srv/gitlab-backup`).
+
+GitLab also creates a backup on upgrade. Those are purged after two
+weeks by the wrapper script.
 
 It is assumed that the existing [howto/backup](howto/backup) system
 will pick up those copies and store them for our normal rotation
 periods.
 
+Artifacts are not backed up because they are already backed up by
+Bacula in the normal job and take a tremendous amount of disk
+space. It should also be noted that most of the files provided by
+`gitlab-backup` are *also* already backed up by Bacula and are
+therefore duplicated on the backup storage server. See [issue 40518][]
+to followup on that.
+
+[issue 40518]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40518
+
 Ideally, this rather exotic backup system would be harmonized with our
 existing backup system, but this would require (for example) using our
-existing PostgreSQL infrastructure ([issue 20](https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/20)).
+existing PostgreSQL infrastructure ([issue 20](https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/20)). Other ideas
+(including filesystem snapshots) are also in [issue 40518][].
 
 ## Other documentation