GitLab.com hat nach einem Bedienfehler rund sechs Stunden Datenbankeinträge verloren. Der Anbieter nennt unter anderem Issues, Merge Requests, Kommentare und Nutzerdaten aus dem Zeitraum 31. Januar 2017, 17:20 bis 23:25 Uhr UTC. Git- und Wiki-Repositories sowie selbst betriebene GitLab-Instanzen sind laut dem vorläufigen Bericht nicht betroffen.
Der offizielle Statuskanal bestätigte die versehentliche Löschung von Produktionsdaten und verwies auf öffentliche Arbeitsnotizen zur Wiederherstellung. Am 1. Februar meldete GitLab den Dienst um 18:14 Uhr UTC, entsprechend 19:14 Uhr deutscher Zeit, wieder online.
Fehler am Primärserver und Lücken in der Sicherung
Nach Problemen mit Datenbanklast und Replikation wurde ein Datenverzeichnis auf dem Primärserver statt auf dem vorgesehenen Zweitsystem entfernt. Zur Wiederherstellung diente eine etwa sechs Stunden alte Sicherung. Der erste Bericht beschreibt zugleich unzuverlässige Backup-Verfahren und mögliche Versionskonflikte beim PostgreSQL-Sicherungswerkzeug. Eine abschließende Ursachenanalyse steht noch aus.
Repository-Kopie ersetzt keine Projektdatenbank
Der Vorfall betrifft die Trennung zwischen Quellcode und dessen organisatorischem Umfeld. GitLab verbindet Repository-Verwaltung mit Issues und CI-Funktionen. Ein lokaler Git-Klon enthält jedoch nicht automatisch die Kommentare, Aufgaben und weiteren Datenbankeinträge der Plattform. Für Entwicklungsteams sind das unterschiedliche Sicherungsobjekte.
Aus technischer Sicht reicht es deshalb nicht, lediglich das Vorhandensein von Sicherungsdateien zu prüfen. Eine belastbare Wiederherstellungsplanung muss klären, welche Daten sie enthalten und ob ein Rückspielen tatsächlich gelingt. Diese Schlussfolgerung ist von den noch vorläufigen Angaben zur konkreten Fehlerkette zu unterscheiden.