Organisationen, die eine selbstverwaltete GitLab-Instanz verwenden, verlassen sich normalerweise darauf, dass sie ihre Quellcode, Projektmanagement und operative Tools. Es ist wichtig, funktionierende Backups zu haben, damit Ihre Daten im Falle eines Hardwarefehlers, eines erfolglosen Server-Updates oder einer böswilligen Kompromittierung geschützt sind.
GitLab verfügt über eine integrierte Backup-Komponente, die kann ein vollständiges Archiv der Daten Ihrer Installation erstellen. Das Archiv kann auf einem neuen Server mit derselben GitLab-Version wiederhergestellt werden.
So richten Sie Backups in Ihrem lokalen Dateisystem oder einem Amazon S3-Bucket ein. Diese Schritte sind für die Verwendung mit GitLab Omnibus-Editionen vorgesehen. Sie müssen die GitLab-CLI-Befehle ändern, indem Sie ihnen Bundle Exec Rake voranstellen, wenn Ihre Instanz aus dem Quellcode erstellt wurde.
Ein On machen -Backup anfordern
Die einfachste Möglichkeit, ein Backup zu erstellen, ist der Befehl zum Erstellen auf Abruf. Führen Sie den folgenden Befehl in Ihrer Shell aus:
sudo gitlab-backup create
Dies funktioniert auf GitLab 12.2 und neuer. Ältere Versionen sollten stattdessen eine alternative Version verwenden:
sudo gitlab-rake gitlab:backup:create Advertisement
Das Backup wird als tar-Archiv in dem Verzeichnis gespeichert, das durch Ihre GitLab-Konfigurationsdatei definiert ist. Omnibus-Installationen verwenden standardmäßig /var/opt/gitlab/backups. Jedes Backup-Archiv wird mit seinem Erstellungszeitstempel und der GitLab-Version benannt.
Was ist in einem Backup enthalten?
Das integrierte Backup-Dienstprogramm von GitLab exportiert Daten, die von Benutzern auf Ihrer GitLab-Instanz erstellt wurden. Dazu gehört alles in der GitLab-Datenbank und Ihren Git-Repositories auf der Festplatte.
Durch das Wiederherstellen der Sicherung werden Ihre Projekte, Gruppen, Benutzer, Probleme, hochgeladenen Dateianhänge und CI/CD-Auftragsprotokolle wiederhergestellt. Das Backup umfasst auch GitLab Pages-Websites und Docker-Images, die in die integrierte Container-Registry hochgeladen wurden.
Pakete, die den Paket-Registrys von GitLab hinzugefügt werden, werden nicht unterstützt. Sie sollten Ihre Installation so konfigurieren, dass Pakete bei einem externen Objektspeicheranbieter gespeichert werden, wenn diese ohne manuelle Neuaufbau wiederherstellbar sein sollen.
Erstellen eines Backup-Zeitplans
h2>
Es gibt keinen integrierten Mechanismus zum Definieren eines automatisierten Backup-Zeitplans. Sie sollten Ihren eigenen Cron-Task einrichten, um den oben gezeigten Backup-Befehl auszuführen.
Führen Sie sudo crontab -e aus, um die crontab von root zu öffnen, und fügen Sie dann den folgenden Inhalt zur Datei hinzu:
0 21 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
Speichern und schließen Sie die Datei, um Ihre Crontab-Änderung zu übernehmen. In diesem Beispiel wird jeden Tag um 21:00 Uhr ein neues Backup erstellt. Das Setzen der Umgebungsvariablen CRON weist GitLab an, die Anzeige des Backup-Fortschritts auszublenden, damit Sie keine redundanten Cron-E-Mails mit der Jobausgabe erhalten.
Wenn Sie diese Aufgabe unverändert verwenden, wird jede Sicherung auf unbestimmte Zeit aufbewahrt, bis Sie sie manuell bereinigen. Dies kann schnell viel Speicherplatz beanspruchen, wenn Sie eine aktive GitLab-Instanz mit großen Projekten ausführen.
Mit einem optionalen Konfigurationsschlüssel können Sie alte Archive als Teil des Backup-Erstellungsskripts löschen. Öffnen Sie Ihre GitLab-Konfigurationsdatei unter /etc/gitlab/gitlab.rb. Suchen Sie nach backup_keep_time, kommentieren Sie die Zeile und legen Sie die Anzahl der Sekunden fest, für die jede Sicherung aufbewahrt werden soll.
gitlab_rails['backup_keep_time'] = 432000
Hier werden Backups fünf Tage lang aufbewahrt. GitLab löscht jedes Mal alle berechtigten Archive im Backup-Verzeichnis, wenn der Befehl zur Backup-Erstellung ausgeführt wird.
Sie müssen GitLab jedes Mal neu konfigurieren, wenn sich die Konfigurationsdatei ändert. Führen Sie sudo gitlab-ctl reconfigure aus, um Ihre neue Einstellung zu übernehmen.
Datentypen ausschließen
Manchmal möchten Sie möglicherweise eine Sicherung mit einer Teilmenge der unterstützten Datentypen ausführen. Durch das Definieren der SKIP-Umgebungsvariable können Sie bestimmte Operationen von der Ausführung ausschließen und so Ihr endgültiges Archiv verkleinern.
Werbung
Die Umgebungsvariable benötigt eine durch Kommas getrennte Liste von Datentypen. Sie finden die derzeit unterstützten Optionen im GitLab-Wiki.
So sichern Sie alles außer Container-Registry-Images:
sudo gitlab-backup create SKIP=registry
Das Ausschließen des Registrierungsinhalts ist oft eine einfache Möglichkeit, die Größe Ihres Backups erheblich zu reduzieren und seine Erstellungsgeschwindigkeit zu beschleunigen. Ein Team mit mehreren aktiven Projekten, das täglich mehrere Docker-Images erstellt, kann schnell Gigabyte an Registrierungsdaten ansammeln. Sie vom Backup auszuschließen ist nicht unbedingt ein großes Risiko, da Sie die Images jederzeit mit dem Dockerfile in Ihrem Repository neu erstellen können.
Backup auf S3
GitLab kann Ihre Backups automatisch auf S3-kompatiblen Objektspeicheranbietern speichern. Entkommentieren Sie die Zeilen backup_upload_connection und fügen Sie Ihre Verbindungsdetails hinzu:
gitlab_rails['backup_upload_connection'] = { "Anbieter" => "AWS", "Region" => "eu-west-1", "aws_access_key_id" => "access_key", "aws_secret_access_key" => "secret_key", # "Endpunkt" => "https://…" }
Fügen Sie Ihren eigenen Zugriffsschlüssel, geheimen Schlüssel und die AWS-Regions-ID hinzu, um die Verbindung herzustellen. Sie sollten auch das Endpunktfeld festlegen, wenn Sie eine Verbindung zu einem anderen Anbieter als AWS herstellen. Geben Sie die URL Ihres Objektspeicherservers an, damit GitLab darauf hochladen kann.
Sie müssen auch einen backup_upload_remote_directory-Schlüssel festlegen. Suchen Sie diese Zeile in der Konfigurationsdatei, entkommentieren Sie sie und legen Sie einen S3-Bucket-Namen fest, um Ihre Backups hochzuladen:
gitlab_rails['backup_upload_remote_directory'] = 'gitlab-backups';
Führen Sie sudo gitlab-ctl reconfigure aus, um Ihre Änderungen zu übernehmen.
Der Befehl zur Sicherungserstellung lädt nun seine Archive in Ihren konfigurierten S3-Bucket hoch. Dadurch erhalten Sie eine viel größere Redundanz, indem Sie Ihre Backups extern speichern und Sie vor physischen Hardwareausfällen schützen.
Werbung
Achten Sie darauf, dass die Einstellung backup_keep_time nicht unterstützt wird, wenn Sie . verwenden S3-Speicher. Sie gilt nur für lokal gespeicherte Backup-Archive. Sie können etwas Ähnliches erreichen, indem Sie die integrierten Ablaufrichtlinien von S3 verwenden, um Uploads nach Ablauf eines festgelegten Zeitraums automatisch zu löschen.
The Copy Backup Strategie
Die Standard-Backup-Strategie von GitLab besteht darin, Daten kontinuierlich in das tar-Archiv zu streamen. Dies funktioniert im Allgemeinen gut, kann jedoch bei sehr aktiven GitLab-Instanzen zu Problemen führen. Daten können sich im Quellverzeichnis ändern, bevor sie das Archiv erreicht haben, was dazu führt, dass tar sie mit einer Datei überspringt, die beim Lesen geändert wurde.
Um dem entgegenzuwirken, hat GitLab eine optionale Kopierstrategie eingeführt. Dadurch werden alle geeigneten Sicherungsdaten in ein temporäres Verzeichnis kopiert und dann der kopierte Inhalt in das endgültige tar-Archiv gestreamt. Dies stellt sicher, dass tar nicht von einer Live-GitLab-Instanz liest, sondern hat den Nebeneffekt, dass der Speicherverbrauch von GitLab vorübergehend erhöht wird. Auch die Backup-Leistung kann spürbar beeinträchtigt werden, insbesondere auf langsameren Speichergeräten.
Die Kopierstrategie wird aktiviert, indem beim Ausführen des Backup-Befehls die Umgebungsvariable STRATEGY gesetzt wird. Sie sollten sicherstellen, dass genügend Speicherplatz zur Verfügung steht. GitLab führt das Backup in Datentypphasen durch, sodass Sie nur die doppelte Größe Ihres größten Datentyps benötigen. Wenn Sie beispielsweise 5 GB Git-Repositorys und 10 GB Container-Registrys haben, benötigen Sie 10 GB zusätzlichen verfügbaren Speicherplatz, nicht 15 GB.
sudo gitlab-backup create STRATEGY=copy
Nicht vergessen: Sichern Sie Ihre Konfigurationsdatei!
Das Backup-Skript von GitLab verwaltet nur von Benutzern erstellte Daten. Es gibt zwei weitere kritische Dateien, die für den Betrieb Ihres GitLab-Servers unerlässlich sind. Diese müssen ebenfalls gesichert werden, um eine erfolgreiche Wiederherstellung Ihrer Instanz zu gewährleisten.
- /etc/gitlab/gitlab.rb – Dies ist Ihre GitLab-Konfigurationsdatei. Alle Installationen mit Ausnahme der einfachsten werden im Laufe der Zeit normalerweise viele Änderungen erhalten. Wenn Sie diese Datei sichern, können Sie sie in einer neuen GitLab-Installation ablegen, ohne von vorne beginnen zu müssen.
- /etc/gitlab/gitlab-secrets.json– Diese Datei muss gesichert werden. Es enthält Ihren Datenbankverschlüsselungsschlüssel, Geheimnisse, die für die Zwei-Faktor-Authentifizierung verwendet werden, und andere nicht wiederherstellbare sensible Daten. Das Verlegen dieser Datei könnte jegliche Wiederherstellung unmöglich machen, selbst wenn Sie ein funktionierendes Backup-Archiv zur Verfügung haben.
Sie könnten eine andere Cron-Aufgabe verwenden, um diese beiden Dateien zu sichern. Sie sollten von Ihrem Server kopiert werden, damit Sie bei einem Hardwarefehler weiterhin darauf zugreifen können.
Schlussfolgerung
Backups sind für jeden GitLab-Administrator unerlässlich. Die Software ist normalerweise für jedes Team in einer Organisation von entscheidender Bedeutung, sodass unerwartete Ausfallzeiten zu ernsthaften betrieblichen Herausforderungen führen können.
Werbung
GitLab wird mit allem geliefert, was Sie für regelmäßige Backups benötigen. Der beste Ansatz besteht darin, eine Cron-Aufgabe zu erstellen, die das integrierte Skript regelmäßig ausführt. Speichern Sie Ihre Backup-Archive in einem externen Objektspeicher, um sich vor Hardwareverlust, -ausfall oder -beschädigung zu schützen. Denken Sie daran, auch Ihre GitLab-Konfigurations- und Secrets-Dateien manuell zu sichern, da sonst der Wiederherstellungsprozess erheblich komplizierter wird.