KI-gestützte Rettung einer GitLab-Instanz

In einem vorherigen Artikel zu Infrastrukturkomponenten der Softwareentwicklung hatten wir bereits erwähnt, dass unser Raspberry Pi auf eine SSD umgestellt werden sollte. Gesagt, getan: In Zeiten von KI wirkt vieles erstaunlich einfach. Der schnelle Startversuch erfolgte über das Klonen des Laufwerks und einen anschließenden Reboot.

Was danach folgte, gehört allerdings zu den klassischen Momenten, die jedes DIY-Projekt früher oder später bereithält.

Nach Anpassung der Bootreihenfolge und der UUIDs trat jedoch der Super-GAU ein: Das System bootete nicht mehr. Genau dieser Punkt gehört zum Basteln dazu – Dinge selbst umzusetzen bedeutet eben auch, Fehler zu provozieren, sie zu verstehen und daran zu wachsen. Dieser Artikel beschreibt genau diesen Weg und die dabei gewonnenen Erfahrungen.

Nach einem kurzen Brainstorming fiel die Entscheidung für einen pragmatischen Ansatz: eine Neuinstallation von Ubuntu 26.04 auf der SSD und anschließend die Migration der bestehenden GitLab-Instanz. Das vorherige System basierte auf Ubuntu 24.04, wodurch einzelne Fallstricke vorprogrammiert waren.

Wichtig dabei: Ein Backup der relevanten Daten war vorhanden, sodass kein kompletter Neuaufbau notwendig war. Genau hier liegt ein zentraler Punkt: Automatisierte Backups sind essenziell. Technische Defekte oder Probleme nach Softwareupdates sind keine Seltenheit.

Vorgehen

• Installation Ubuntu 26.04
• Gitlab wiederhestellen
• Backup durchführen und automatisieren

Installation Ubuntu 26.04

Mit Hilfe von Raspberry Pi Imager ist das quasi ein Selbstläufer und bedeutet nur ein wenig Geduld.

GitLab wiederherstellen

Zunächst wurde GitLab in der Version 18.11 neu installiert:

sudo apt install -y curl ca-certificates gnupg

curl -fsSL https://packages.gitlab.com/gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/gitlab.gpg

echo "deb [signed-by=/usr/share/keyrings/gitlab.gpg] https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/ noble main" | sudo tee /etc/apt/sources.list.d/gitlab-ce.list

sudo EXTERNAL_URL="http://gitlab.local" apt install gitlab-ce

Das neue System soll sich nahtlos in unsere bestehende Infrastruktur integrieren. Daher soll der alte Zustand so gut wie möglich wiederhergestellt werden. Daher wurde die gitlab.rb anhand des Backups angeglichen. Zusätzlich wurden SSL-Zertifikate sowie die Datei gitlab-secrets.json übernommen.

Das Verzeichnis /var/opt/gitlab/ wurde aus dem Backup wiederhergestellt. Dabei traten zunächst Probleme mit den Dateiberechtigungen auf.

Berechtigungen und Re-Konfiguration

Zur Behebung wurden die Verzeichnisberechtigungen korrigiert und anschließend erneut eine Re-Konfiguration durchgeführt. Der Befehl gitlab-ctl reconfigure setzt einige Berechtigungen automatisch, aber die Vorbedingungen müssen stimmen. Nach mehreren Versuchen funktionierte der Prozess stabil. Die Logs (gitlab-ctl tail) lieferten die notwendigen Informationen welche Verzeichnisberechtigungen nicht korrekt waren.

Probleme nach dem ersten Start

Finally?

Nach dem ersten Moment der Erleichterung folgte schnell die Ernüchterung: Es wurden zunächst keine Projekte angezeigt. Im Adminbereich waren die Projekte jedoch vorhanden und auch die API-Endpunkte lieferten korrekte Ergebnisse. Die GitLab-Oberfläche selbst deutete dennoch auf ein weiter bestehendes Problem hin. Das Vorgehen ist also nicht gescheitert, erfordert aber weitere Schritte.

Die Analyse der Logs führte zu folgenden Schritten:

sudo gitlab-rake gitlab:check

Die dabei identifizierten Hinweise wurden umgesetzt und sind der Übernahme aus dem Backup geschuldet.

sudo gitlab-psql -d gitlabhq_production -c "ALTER DATABASE gitlabhq_production REFRESH COLLATION VERSION;"

sudo gitlab-rake db:migrate RAILS_ENV=production

Ergebnis

Nach einem Neustart des GitLab-Services, erneutem Reconfigure und einem finalen Restart waren alle Projekte wieder verfügbar.

Der abschließende Schritt war die Absicherung des Systems durch ein funktionierendes Backup sowie die Automatisierung zukünftiger Sicherungen. Gleichzeitig ergaben sich wichtige Lessons Learned: Zusätzlich zum Systembackup sollte auch ein dediziertes GitLab-Backup über sudo gitlab-backup create STRATEGY=copy fest in den Backup-Prozess integriert werden.

In diesem Sinne: Always back up your data!