Eine Replik fiel zurück – und die Produktion bekam es zu spüren
Im Januar 2017 verließ sich GitLab.com auf einen PostgreSQL-Primärserver, db1.cluster.gitlab.com, und eine Live-Replik, db2.cluster.gitlab.com, um die Ausfallsicherheit zu gewährleisten. Diese Architektur, die für Hochverfügbarkeits-Setups üblich ist, sollte db2 für ein Failover synchron halten – eine entscheidende, aber oft anfällige Verteidigung.
An jenem Abend führte eine Lastspitze dazu, dass db2 so weit zurückfiel, dass die Replikation stoppte. Die Standardlösung: db2 neu initialisieren, indem der Datenordner gelöscht und alles von db1 kopiert wird. Ein theoretisch einfaches Verfahren.
Während dieser Neuinitialisierung führte ein Ingenieur jedoch versehentlich den Befehl rm -rf nicht auf db2, sondern auf db1, dem Produktions-Primärserver, aus. Der Befehl lief nur ein oder zwei Sekunden, bevor er gestoppt wurde, aber der Schaden war angerichtet: Etwa 300 GB an Daten wurden gelöscht. Dies war keine langsame Beschädigung; es war eine plötzliche, katastrophale Löschung von Live-Produktionsdaten. Die Konsequenzen dieses einen fehlgeleiteten Befehls sollten sich bald entfalten und ein weitaus tieferliegendes Problem offenbaren.
Jedes Backup sah sicherer aus, als es war
Die Katastrophe bei GitLab entstand nicht nur durch einen einzelnen Fehltritt, sondern durch ein Kartenhaus, das auf ungeprüften Annahmen basierte. Das Unternehmen glaubte, eine robuste Backup-Strategie zu haben, doch jede Ebene erwies sich als fatal fehlerhaft, was bewies, dass ein ungeprüftes Backup lediglich eine Hypothese und kein Schutz ist.
Das Vertrauen in einen täglichen pg_dump-Export zu Amazon S3 war unbegründet. Der Job, der die PostgreSQL 9.6-Datenbank sichern sollte, verwendete seltsamerweise ein pg_dump-Tool einer viel älteren PostgreSQL 9.2-Version. Diese Diskrepanz führte dazu, dass der Export stillschweigend fehlschlug und der S3-Bucket leer blieb.
Entscheidend war, dass niemand das systemische Versagen bemerkte. Benachrichtigungs-E-Mails, die auf den fehlerhaften Backup-Job hinweisen sollten, wurden vom Mailserver aufgrund von Authentifizierungsproblemen summarisch abgelehnt. Erschwerend kam hinzu, dass Snapshots der Produktionsdatenbank, eine grundlegende Ebene der Ausfallsicherheit, nie aktiviert wurden. LVM-Snapshots existierten nur für Staging, und Azure Cloud-Snapshots deckten zwar OS-Festplatten ab, aber nicht die kritischen Datenbank-Volumes.
Da die primäre Datenbank kompromittiert war und die Replik während des Wiederherstellungsversuchs bereits gelöscht worden war, stand GitLab vor einer erschreckenden Realität: Es gab kein brauchbares aktuelles Backup. Der einzige Weg zurück war ein etwa sechs Stunden alter manueller Snapshot, den ein Ingenieur für einen unabhängigen Lasttest erstellt hatte. Dieser Glücksfall, statt einer technisch geplanten Lösung, unterstrich die Prekarität ihrer gesamten Backup-Philosophie. Das Kopieren dieses Snapshots von langsamen Festplatten dauerte etwa 18 Stunden, was der Gesamtdauer des Ausfalls entsprach und die wahren Kosten der vernachlässigten Vorbereitung auf die Datenwiederherstellung verdeutlichte.
Die Fehlerbehebung fand vor 5.000 Zuschauern statt
Die Krisenreaktion von GitLab war eine Meisterklasse in radikaler Transparenz. Die Ingenieure teilten Echtzeit-Updates und Fehlerbehebungen öffentlich über ein Google Doc, soziale Medien und einen YouTube-Livestream. Diese Entscheidung verwandelte einen katastrophalen technischen Fehler in einen weithin sichtbaren Vertrauenstest, bei dem in der Spitze über 5.000 Menschen zusahen.
Die Fehlerbehebung war quälend langsam und stützte sich auf einen manuell erstellten Snapshot von vor sechs Stunden, der auf langsamen Speicherfestplatten lag. Die Wiederherstellung dieses Snapshots dauerte etwa 18 Stunden, die Dauer des gesamten Ausfalls. Diese langsame Wiederherstellung bedeutete, dass GitLab.com für einen erheblichen Zeitraum nicht erreichbar war.
Letztendlich verlor GitLab etwa sechs Stunden an Datenbankeinträgen. Dies umfasste ungefähr:
- 5.000 Projekte
- 5.000 Kommentare
- 700 Benutzerkonten
Die Repository-Daten blieben glücklicherweise auf einem separaten Speicher intakt. Obwohl das Ergebnis schmerzhaft war, erntete die öffentliche Zurschaustellung von Resilienz und Ehrlichkeit großen Respekt. Für einen tieferen Einblick in die Details konsultieren Sie das Postmortem of database outage of January 31 - GitLab. Dieser Vorfall hat grundlegend verändert, wie viele in der Branche Incident Response und radikale Transparenz betrachten.
Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.
eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte
Die Lektion war Eigenverantwortung, nicht Schuldzuweisung
Das Postmortem von GitLab suchte keinen Sündenbock; es diagnostizierte ein systemisches Versagen der Eigenverantwortung. Das zentrale Problem war nicht der Fehler eines Ingenieurs, sondern das Fehlen einer dedizierten Rolle für Backup-Zuverlässigkeit und routinemäßige Wiederherstellungsüberprüfungen. Niemand war verantwortlich, daher verkümmerten kritische Sicherheitsvorkehrungen.
Der Vorfall katalysierte bedeutende interne Reformen. GitLab implementierte automatisierte Wiederherstellungstests, um sicherzustellen, dass Backups nicht nur vorhanden, sondern auch funktionsfähig waren. Sie stärkten zudem die Schutzmaßnahmen für den Produktionszugriff, erschwerten versehentliche destruktive Aktionen und wiesen einem dedizierten Team die explizite Verantwortung für die Datenbankzuverlässigkeit zu.
Für jede technische Organisation ist die Lektion klar: Weisen Sie einen spezifischen Verantwortlichen für die Backup-Integrität zu. Etablieren Sie verifizierte Alarmkanäle für Backup-Fehler – verlassen Sie sich nicht auf unbemerkt bleibende E-Mails. Testen Sie entscheidenderweise regelmäßig Wiederherstellungen, um Ihre Wiederherstellungsstrategie zu validieren, und implementieren Sie robuste Sicherheitsvorkehrungen, um versehentlichen Datenverlust zu verhindern. Ihre Backups sind nur so gut wie Ihre letzte verifizierte Wiederherstellung.
Häufig gestellte Fragen
Was verursachte den Datenbankausfall von GitLab im Jahr 2017?
Während der Reparatur eines Replikats, das in Verzug geraten war, löschte ein Ingenieur versehentlich Daten aus der Produktionsdatenbank anstelle des Replikats.
Warum konnte GitLab nicht von seinen Backups wiederherstellen?
Der tägliche Export schlug fehl, da eine inkompatible Postgres-Tool-Version verwendet wurde und Fehler-E-Mails abgewiesen wurden. Produktions-Snapshots waren ebenfalls nicht verfügbar.
Wie lange war GitLab offline?
Die Wiederherstellung dauerte etwa 18 Stunden, hauptsächlich weil die Wiederherstellung eines manuell erstellten Snapshots von einem langsamen Speicher Zeit in Anspruch nahm.
Wie viele Daten hat GitLab verloren?
GitLab verlor etwa sechs Stunden an Datenbankdaten, darunter rund 5.000 Projekte, 5.000 Kommentare und 700 Benutzerkonten.
Was ist die wichtigste Lektion aus dem Vorfall?
Ein Backup ist nur dann vertrauenswürdig, wenn Teams regelmäßig testen, dass sie es wiederherstellen können – und jemand für diesen Prozess verantwortlich ist.