Gitlab, ein Service für Entwickler zum Hosten und Verwalten von Projekten, ist nach einem rund zweitägigen Totalausfall wieder erreichbar. Das Unternehmen muss allerdings den Verlust von Daten durch die versehentliche Löschung einer Datenbank eingestehen.

Da die verschiedenen Backup-Mechanismen versagt haben, muss Gitlab einen Snapshot einspielen, der ungefähr sechs Stunden vor dem Ausfall angelegt wurde. Der scheint zu funktionieren, heißt es seitens Gitlab. Daten, die zwischen diesem Snapshot und dem Ausfall geändert dürften damit verloren sein. Gitlab hat einen Post-Mortem-Bericht verfasst, der den Schaden zusammenfasst und die Reaktionen darauf beschreibt. Demnach könnten rund rund 4613 Projekte verloren gegangen sein.

Wie berichtet war der Auslöser für die Probleme das Versehen eines Admins, der einen leeren Ordner löschen wollte, weil er ihn für PostgreSQL-Replikationsprobleme verantwortlich wähnte. Beim Löschen allerdings war der Admin — schon das ist ein Klassiker — auf einem anderen Rechner eingelogt, als er annahm. Dadurch löschte er auch keinen leeren Ordner, sondern die produktive Datenbank. Das wurde ihm nach wenigen Sekunden klar, aber da war es zu spät. Der größte Teil der Daten war weg.

Natürlich gab es gleich mehrere Backupmechanismen, aber die meisten hatten unbemerkt versagt. Das PostgreSQL-Backup war ausgefallen, weil es mit Binaries gestartet wurde, die nicht mehr kompatibel zur eingesetzten Version waren. Snapshots in Azure existierten, aber nur für die NFS-Server, nicht für die Datenbank. Die Backups auf der Grundlage von Amazons Speicherdienst S3 hatten ebenfalls nicht funktioniert. Ein Monitoring der Backups gab es nicht. Offensichtlich war in letzter Zeit auch das Recovery nicht getestet worden.