Tachtler's DokuWiki

Homepage | Kontakt | Rechtliche Informationen | Impressum

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Zuletzt angesehen: • gitlab_archlinux_-_backup
tachtler:gitlab_archlinux_-_backup

Dies ist eine alte Version des Dokuments!

Inhaltsverzeichnis

GitLab ArchLinux - Backup

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.

Beschreibung Externer Link
Homepage https://gitlab.com/
Dokumentation https://docs.gitlab.com/
Versionsvergleich https://about.gitlab.com/install/ce-or-ee/
Installation https://wiki.archlinux.org/title/PostgreSQL
https://wiki.archlinux.org/title/Redis
https://wiki.archlinux.org/title/GitLab
Back up Dokumentation https://docs.gitlab.com/ee/administration/backup_restore/backup_gitlab.html

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:

Vorwort

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.

Voraussetzungen

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

GitLab: Konfiguration

/etc/webapps/gitlab/gitlab.yml

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!

GitLab: Dienste/Daemons stoppen

Nachdem GitLab wahrscheinlich bereits lauffähig gestartet wurde, ist es erforderlich GitLab zu stoppen.

Da ein systemd-Target - hier in diesem Fall gitlab.target nicht einfach gestoppt werden kann, ist es sinnvoll sich den Inhalt von gitlab.target mit nachfolgendem Befehl anzeigen zu lassen: 

# systemctl cat gitlab.target
# /usr/lib/systemd/system/gitlab.target
[Unit]
Description=GitLab - Self Hosted Git Management
Requires=gitlab-puma.service gitlab-workhorse.service
Wants=gitlab-sidekiq.service gitlab-backup.timer gitlab-gitaly.service gitlab-mailroom.service

[Install]
WantedBy=multi-user.target

Hier sind alle Dienste/Daemons welche ebenfalls mittels systemd gestartet werden aus dem gitlab.target in den Bereichen

  • Requires
  • Wants

aufgelistet

Diese können dann mit nachfolgendem Befehl gestoppt werden: 

# systemctl stop gitlab-puma.service gitlab-workhorse.service gitlab-sidekiq.service gitlab-backup.timer gitlab-gitaly.service gitlab-mailroom.service

GitLab: Backup-Befehl

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
# sudo -u gitlab $(cat environment | xargs) bundle exec rake gitlab:backup:create RAILS_ENV=production
2024-03-23 07:32:47 +0100 -- Dumping database ... 
Dumping PostgreSQL database gitlabhq_production ... [DONE]
2024-03-23 07:32:48 +0100 -- Dumping database ... done
2024-03-23 07:32:48 +0100 -- Dumping repositories ... 
2024-03-23 07:32:48 +0100 -- Dumping repositories ... done
2024-03-23 07:32:48 +0100 -- Dumping uploads ... 
2024-03-23 07:32:48 +0100 -- Dumping uploads ... done
2024-03-23 07:32:48 +0100 -- Dumping builds ... 
2024-03-23 07:32:48 +0100 -- Dumping builds ... done
2024-03-23 07:32:48 +0100 -- Dumping artifacts ... 
2024-03-23 07:32:48 +0100 -- Dumping artifacts ... done
2024-03-23 07:32:48 +0100 -- Dumping pages ... 
2024-03-23 07:32:48 +0100 -- Dumping pages ... done
2024-03-23 07:32:48 +0100 -- Dumping lfs objects ... 
2024-03-23 07:32:48 +0100 -- Dumping lfs objects ... done
2024-03-23 07:32:48 +0100 -- Dumping terraform states ... 
2024-03-23 07:32:48 +0100 -- Dumping terraform states ... done
2024-03-23 07:32:48 +0100 -- Dumping container registry images ... [DISABLED]
2024-03-23 07:32:48 +0100 -- Dumping packages ... 
2024-03-23 07:32:48 +0100 -- Dumping packages ... done
2024-03-23 07:32:48 +0100 -- Dumping ci secure files ... 
2024-03-23 07:32:48 +0100 -- Dumping ci secure files ... done
2024-03-23 07:32:48 +0100 -- Creating backup archive: 1711175567_2024_03_23_16.9.2_gitlab_backup.tar ... 
2024-03-23 07:32:48 +0100 -- Creating backup archive: 1711175567_2024_03_23_16.9.2_gitlab_backup.tar ... done
2024-03-23 07:32:48 +0100 -- Uploading backup archive to remote storage  ... [SKIPPED]
2024-03-23 07:32:48 +0100 -- Deleting old backups ... [SKIPPED]
2024-03-23 07:32:48 +0100 -- Deleting tar staging files ... 
2024-03-23 07:32:48 +0100 -- Cleaning up /var/lib/gitlab/backups/backup_information.yml
2024-03-23 07:32:48 +0100 -- Cleaning up /var/lib/gitlab/backups/db
2024-03-23 07:32:48 +0100 -- Cleaning up /var/lib/gitlab/backups/uploads.tar.gz
2024-03-23 07:32:48 +0100 -- Cleaning up /var/lib/gitlab/backups/builds.tar.gz
2024-03-23 07:32:48 +0100 -- Cleaning up /var/lib/gitlab/backups/artifacts.tar.gz
2024-03-23 07:32:48 +0100 -- Cleaning up /var/lib/gitlab/backups/pages.tar.gz
2024-03-23 07:32:48 +0100 -- Cleaning up /var/lib/gitlab/backups/lfs.tar.gz
2024-03-23 07:32:48 +0100 -- Cleaning up /var/lib/gitlab/backups/terraform_state.tar.gz
2024-03-23 07:32:48 +0100 -- Cleaning up /var/lib/gitlab/backups/packages.tar.gz
2024-03-23 07:32:48 +0100 -- Cleaning up /var/lib/gitlab/backups/ci_secure_files.tar.gz
2024-03-23 07:32:48 +0100 -- Deleting tar staging files ... done
2024-03-23 07:32:48 +0100 -- Deleting backups/tmp ... 
2024-03-23 07:32:48 +0100 -- Deleting backups/tmp ... done
2024-03-23 07:32:48 +0100 -- Warning: Your gitlab.rb and gitlab-secrets.json files contain sensitive data 
and are not included in this backup. You will need these files to restore a backup.
Please back them up manually.
2024-03-23 07:32:48 +0100 -- Backup 1711175567_2024_03_23_16.9.2 is done.
2024-03-23 07:32:48 +0100 -- Deleting backup and restore PID file ... done

:!: HINWEIS - Die nachfolgende Warnung, kann ignoriert werden, da dies nur für eine Omnibus Installation relevant ist! 

  • 2024-03-23 07:32:48 +0100 -- Warning: Your gitlab.rb and gitlab-secrets.json files contain sensitive data 
and are not included in this backup. You will need these files to restore a backup.
Please back them up manually

Ob die Erstellung mittels des Backup-Befehls auch eine entsprechende Backup-Datei erzeugt hat, kann mit nachfolgendem Befehl überprüft werden und sollte eine Datei in etwa wie die nachfolgende zum Vorschein bringen: 

# ls -l /var/lib/gitlab/backups
total 472
-rw------- 1 gitlab gitlab 481280 Mar 23 07:32 1711175567_2024_03_23_16.9.2_gitlab_backup.tar

GitLab: Manuelles sichern von Konfigurationsdateien

:!: WICHTIG - !!! Es ist zwingend anzuraten, die nachfolgenden Verzeichnisse ebenfalls zu sichern !!!

GitLab

GitLab: Dienste/Daemons starten

Mit nachfolgendem Befehl wird GitLab wieder gestartet.

Dieser systemd-Start beinhaltet auch den Start alle anderen benötigten Komponenten bzw. Dienste/Daemons von GitLab. 

# systemctl start gitlab.target

Eine Überprüfung, ob der Start des Ziel/Target erfolgreich war, kann mit nachfolgendem Befehl überprüft werden: 

● gitlab.target - GitLab - Self Hosted Git Management
     Loaded: loaded (/usr/lib/systemd/system/gitlab.target; enabled; preset: disabled)
     Active: active since Fri 2024-03-22 09:34:35 CET; 30min ago

Mar 22 09:34:35 vml200 systemd[1]: Reached target GitLab - Self Hosted Git Management.

:!: Hier geht es weiter … / To be continued …

Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
tachtler/gitlab_archlinux_-_backup.1711179816.txt.gz · Zuletzt geändert: 2024/03/23 08:43 von klaus