... | ... | @@ -1746,20 +1746,32 @@ separately: |
|
|
|
|
|
It is assumed that the existing [howto/backup](howto/backup) system
|
|
|
will pick up those files, but also the actual backup files in
|
|
|
`/srv/gitlab-backup` and store them for our normal rotation periods.
|
|
|
`/srv/gitlab-backup` and store them for our normal rotation
|
|
|
periods. For repositories, this is actually not completely clear, see
|
|
|
[upstream issue 432743](https://gitlab.com/gitlab-org/gitlab/-/issues/432743) for that discussion.
|
|
|
|
|
|
This implies that the files covered by the `gitlab-backup` job are
|
|
|
*also* already backed up by Bacula and are therefore duplicated on the
|
|
|
backup storage server. Ultimately, we need to make sure everything is
|
|
|
covered by our normal backup system and retire the rake task, see
|
|
|
[issue 40518][] to track that work.
|
|
|
This implies that some of the files covered by the `gitlab-backup` job
|
|
|
are *also* already backed up by Bacula and are therefore duplicated on
|
|
|
the backup storage server. Ultimately, we need to make sure everything
|
|
|
is covered by our normal backup system and possibly retire the rake
|
|
|
task, see [issue 40518][] to track that work.
|
|
|
|
|
|
[issue 40518]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/40518
|
|
|
|
|
|
Note that, since 16.6 (late 2023), GitLab has [slightly better
|
|
|
documentation about how backups work](https://docs.gitlab.com/ee/administration/backup_restore/). It's still [lacking
|
|
|
information about server-side backups](https://gitlab.com/gitlab-org/gitaly/-/issues/5691), which we were
|
|
|
[experimenting with as of late 2023](https://gitlab.torproject.org/tpo/tpa/team/-/issues/41425).
|
|
|
documentation about how backups work](https://docs.gitlab.com/ee/administration/backup_restore/). We have [experimenting
|
|
|
server-side backups in late 2023](https://gitlab.torproject.org/tpo/tpa/team/-/issues/41425), and found many issues:
|
|
|
|
|
|
* [lacking documentation about server-side backups](https://gitlab.com/gitlab-org/gitaly/-/issues/5691)
|
|
|
* [backups are never pruned](https://gitlab.com/gitlab-org/gitlab/-/issues/435265#note_1695246922) (!)
|
|
|
* [incremental support is unclear](https://gitlab.com/gitlab-org/gitlab/-/issues/435266#note_1695256441)
|
|
|
* [runaway backup size](https://gitlab.com/gitlab-org/gitaly/-/issues/3384)
|
|
|
|
|
|
The backup size is particularly problematic. In the 2023 test, we
|
|
|
found that our 90GiB of repositories were generating a *new* 200GiB of
|
|
|
object storage data *at every backup*. It seems like shared `@pool`
|
|
|
repositories are not backed up correctly, which begs the question of
|
|
|
the backups' integrity in the first place.
|
|
|
|
|
|
## Other documentation
|
|
|
|
... | ... | |