Totalausfall bei Gitlab

01.02.2017

Der Git-Repository-Provider Gitlab ist vorübergehend komplett offline, weil ein Admin produktiv genutzte Daten gelöscht hat.

Der Git-Repository-Provider Gitlab ist seit gestern nicht erreichbar, weil ein Systemadministrator versehentlich wichtige Daten gelöscht hat, von denen es kein Online-Duplikat gibt. Nachdem er sich eine zeitlang mit LVM-Snapshots und der Replikation der PostgreSQL-Datenbanken beschäftigt hatte, beschloss der Gitlab-Mitarbeiter, ein leeres Verzeichnis zu löschen, von dem er vermutete, dass es hinter den Replikationsproblemen steckte. Allerdings war dieses Verzeichnis, da er sich zu diesem Zeitpunkt irrtümlich auf dem falschen Rechner arbeitete, gar nicht leer, sondern enthielt die komplette Datenbank der Gitlab-Site. Als er sich dazu entschloss, den Löschbefehl abzubrechen, waren davon bereits über 300 GByte gelöscht und nur noch 4 GByte übrig.

Seither arbeiten die Gitlab-Techniker daran, die gelöschte Datenbank aus älteren Snapshots soweit möglich wieder herzustellen. Erschwert wird dies dadurch, dass es keine vollkommen aktuellen Backups gibt, denn von den insgesamt fünf Backup-Strategien sind offensichtlich alle fehlgeschlagen: die PostgreSQL-Backup etwa deswegen, weil die verwendeten Binaries von PG-Dump nicht zur Datenbankversion passen. In der der Azure-Cloud gab es Disk-Snapshots nur von den NFS-, aber nicht von den Datenbank-Servern. Die Backups auf Amazon S3 sind anscheinend ebenfalls fehlgeschlagen.

Den aktuellen Fortschritt der Wiederherstellung dokumentiert Gitlab auf dem Twitter-Account der Firma. Eine Rekonstruktion der Ereignisse, die zu dem Totalausfall geführt haben, ist in einem Google-Doc zu finden. Laut Gitlab sind die gehosteten Kunden-Repositories nicht von dem Datenverlust betroffen.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Loadtests ohne Server

Für Loadtests der eigenen Server bietet sich die Cloud an, denn kurz getaktet lassen sich dort viele Rechnerinstanzen starten, die das eigene Budget nur wenig belasten. Noch flexibler, günstiger und besser skalierbar sind Tests mit einer Serverless-Infrastruktur wie AWS Lambda. Wir führen vor, wie Sie dort mit Serverless Artillery eigene Loadtests starten. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018