GitLab ist ein, in der Community Edition unter einer MIT-Lizenz zur Verfügung gestelltes System, zur Verwaltung von Git-Repositorys im Browser, was den unentgeltlichen Betrieb auf einem eigenen Server ermöglicht.

Ab hier werden root-Rechte zur Ausführung der nachfolgenden Befehle benötigt. Um der Benutzer root zu werden, geben Sie bitte nachfolgenden Befehl ein:

$ su -
Password: 

Als grobe Richtlinie gilt:

Wenn eine Architektur mit weniger als 100 GB Daten Verwendung findet, sind die nachfolgenden drei Schritte für ein erfolgreiches Backup ausreichend:

1. Backup-Befehl ausführen.
2. Objektspeicher sichern, falls zutreffend.
3. Manuelles sichern von Konfigurationsdateien.

Welche Daten müssen gesichert werden?

1. PostgreSQL-Datenbanken
   1. Im einfachsten Fall verfügt GitLab über eine PostgreSQL-Datenbank auf einem PostgreSQL-Datenbank-Server auf dem selben Server wie alle anderen GitLab-Dienste ebenfalls.
   2. Im Allgemeinen sind diese Daten die einzige Quelle der Wahrheit für die meisten Benutzer generierten Inhalte in der Weboberfläche, wie z. B. Inhalte von Problemen und Zusammenführungsanfragen, Kommentare, Berechtigungen und Anmeldeinformationen.
   3. In der PostgreSQL-Datenbank werden auch einige zwischengespeicherte Daten wie HTML-rendered Markdown und standardmässig Zusammenführungsanfrage-Diffs gespeichert. Merge Request Diffs können jedoch auch so konfiguriert werden, dass sie in das Dateisystem oder den Objektspeicher ausgelagert werden.
   4. Der Praefect-Dienst von Gitaly Cluster verwendet eine PostgreSQL-Datenbank als einzige Quelle der Wahrheit, um seine Gitaly-Knoten zu verwalten.
   5. Ein gängiges PostgreSQL-Dienstprogramm, pg_dump, erstellt eine Sicherungsdatei, die zur Wiederherstellung einer PostgreSQL-Datenbank verwendet werden kann. Der Backup-Befehl verwendet dieses Dienstprogramm unter der Haube.
2. Git-Repositories
   1. Mit dem Backup-Befehl wird für jedes Repository ein Git-Bundle erstellt und die Daten aller Repositories gesichert. Dadurch werden die Daten der Pool-Repositorys in jedem Fork dupliziert.
3. Blobs
   1. GitLab speichert Blobs (oder Dateien) wie z. B. Issue-Anhänge oder LFS-Objekte entweder im: Hier - im Dateisystem an einem bestimmten Ort.
   2. Objektspeicher
      1. Der Backup-Befehl sichert keine Blobs, die nicht im Dateisystem gespeichert sind.
4. Container-Registrierung
   1. Im Dateisystem an einem bestimmten Ort.
   2. Der Backup-Befehl sichert die Registrierungsdaten, wenn sie am Standardspeicherort im Dateisystem gespeichert sind.
5. Konfigurationsdateien
   1. Es sollten Sicherungskopien des Konfigurationsverzeichnisses erstellt werden. Zumindest muss ein Backup von nachfolgenden Dateien manuell erstellen werden:
      1. /etc/webapps/gitlab/gitlab.yml
      2. /etc/webapps/gitlab/secrets.yml
      3. /etc/webapps/gitlab/secret
      4. /etc/webapps/gitlab-shell/secret
   2. oder am besten von den beiden nachfolgenden Verzeichnissen:
      1. /etc/webapps/gitlab
      2. /etc/webapps/gitlab-shell
6. Andere Daten
   1. GitLab verwendet Redis sowohl als Cache-Speicher als auch zur Speicherung von persistenten Daten für das System für Hintergrundaufträge, Sidekiq, der mitgelieferte Backup-Befehl sichert keine Redis-Daten. Das bedeutet, dass für eine konsistente Sicherung mit dem Backup-Befehl keine anhängigen oder laufenden Hintergrundaufträge vorhanden sein dürfen.

Als Voraussetzung für die hier, nachfolgend durchgeführtes Backup von GitLab Version 16.x ist:

• Lauffähige Installation von GitLab
  • Siehe auch den internen Link: GitLab ArchLinux
  • Siehe auch den internen Link: GitLab ArchLinux - LDAP-Konfiguration
• Erstelltes Backup von GitLab
  • siehe auch den internen Link: GitLab ArchLinux - Backup