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

Die Konfigurationsdatei /etc/webapps/gitlab/gitlab.yml ist die Haupt-Konfigurationsdatei von GitLab.

Nachfolgende Einstellungen sind für ein Backup bereits standardmässig gesetzt und sind im Bereich:

  #   
  # 4. Advanced settings
  # ==========================

konfiguriert:

Nachfolgend der komplette Konfigurationsabschnitt:

  ## Backup settings
  backup:
    path: "/var/lib/gitlab/backups"   # Relative paths are relative to Rails.root (default: tmp/backups/)
    # gitaly_backup_path: /usr/bin/gitaly-backup # Path of the gitaly-backup binary (default: searches $PATH)
    # archive_permissions: 0640 # Permissions for the resulting backup.tar file (default: 0600)
    # keep_time: 604800   # default: 0 (forever) (in seconds)
    # pg_schema: public     # default: nil, it means that all schemas will be backed up
    # upload:
    #   # Fog storage connection settings, see https://fog.io/storage/ .
    #   connection:
    #     provider: AWS
    #     region: eu-west-1
    #     aws_access_key_id: AKIAKIAKI
    #     aws_secret_access_key: 'secret123'
    #   # The remote 'directory' to store your backups. For S3, this would be the bucket name.
    #   remote_directory: 'my.s3.bucket'
    #   # Use multipart uploads when file size reaches 100MB, see
    #   #  http://docs.aws.amazon.com/AmazonS3/latest/dev/uploadobjusingmpu.html
    #   multipart_chunk_size: 104857600
    #   # Specifies Amazon S3 storage class to use for backups (optional)
    #   # storage_class: 'STANDARD'
    #   # Turns on AWS Server-Side Encryption with Amazon Customer-Provided Encryption Keys for backups, this is     optional
    #   #   'encryption' must be set in order for this to have any effect.
    #   #   'encryption_key' should be set to the 256-bit encryption key for Amazon S3 to use to encrypt or decrypt  your data.
    #   # encryption: 'AES256'
    #   # encryption_key: '<key>'
    #   #
    #   # Turns on AWS Server-Side Encryption with Amazon S3-Managed keys (optional)
    #   # https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html
    #   # For SSE-S3, set 'server_side_encryption' to 'AES256'.
    #   # For SS3-KMS, set 'server_side_encryption' to 'aws:kms'. Set
    #   # 'server_side_encryption_kms_key_id' to the ARN of customer master key.
    #   # storage_options:
    #   #   server_side_encryption: 'aws:kms'
    #   #   server_side_encryption_kms_key_id: 'arn:aws:kms:YOUR-KEY-ID-HERE'

HINWEIS - Grundsätzlich kann das Verzeichnis in das das Backup erstellt wird: /var/lib/gitlab/backups verwendet werden!

Nachfolgende Befehle führen ein Backup von GitLab durch.

Mit nachfolgendem Befehl muss zwingend in das Verzeichnis /usr/share/webapps/gitlab gewechselt werden:

# cd /usr/share/webapps/gitlab

Der nachfolgende Befehl, führt dann das Backup von GitLab aus:

# sudo -u gitlab $(cat environment | xargs) bundle exec rake gitlab:backup:create RAILS_ENV=production

Hier geht es weiter … / To be continued …