Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

News

Gitlab löscht versehentlich 300 Gigabyte – und bekommt dann Probleme mit dem Backup

(Grafik: Gitlab)

Skizze eines Unglücks: Erst löscht ein Gitlab-Admin 300 Gigabyte an Daten, dann stellt das Unternehmen fest, dass alle fünf eingesetzten Backup-Methoden nicht wie gewünscht funktionieren.

Das reinste Chaos: Bei Gitlab läuft gerade alles schief

Die Quellcode-Plattform Gitlab hat derzeit mit ernsten Problemen zu kämpfen. Angefangen hat alles am 31. Januar: Ein Administrator des Startups löscht ein vermeintlich leeres Verzeichnis von den Servern des Anbieters. Als er bemerkt, dass sich darin aber tatsächlich Daten von Gitlab-Nutzern befinden, ist es bereits zu spät. Nach Abbruch des Löschvorgangs sind von den ursprünglichen 310 Gigabyte an Daten nur noch 4,5 Gigabyte übrig. Damit ist Gitlabs Pleitenserie allerdings längst nicht vorbei.

Rein theoretisch ist natürlich auch dem Gitlab-Team klar, wie wichtig regelmäßige Backups sind. Um sich abzusichern, hat das Startup daher gleich fünf Backup-Mechanismen am Start. Das ist für die betroffenen Gitlab-Kunden allerdings kein echter Trost, denn wie sich herausstellt, haben alle fünf versagt. Es gibt zwar eine Sicherheitskopie, die ist aber sechs Stunden alt und enthält keine Webhooks, was die Wiederherstellung erschwert. Um die ganze Sache noch peinlicher zu machen: Das Backup existiert nur, weil es manuell gestartet wurde. Hätte sich Gitlab auf seine automatisierten Backups verlassen, wäre die Sicherungskopie sogar noch älter gewesen.

Gitlab zeigt eindrucksvoll, wie es nicht geht. (Screenshot: gitlab.com)

Pleiten, Pech und Pannen: Was wir aus dem Gitlab-Unfall lernen können

Zum jetzigen Zeitpunkt ist Gitlab.com noch immer nicht wiederhergestellt. Immerhin gibt sich das Pannen-Startup aber mühe, die Probleme öffentlich zu dokumentieren. Dazu hat Gitlab ein fortlaufend aktualisiertes Dokument bei Google Docs veröffentlicht. Hier werden die Umstände des Unfalls und die Wiederherstellungsarbeiten festgehalten. Außerdem gibt es sogar einen Live-Stream der Arbeit auf Youtube. Für Kunden, die Issues und Merge-Requests bei dem Debakel verloren haben, dürfte das allerdings auch kein Trost sein.

Wenn wir etwas aus den Problemen bei Gitlab lernen können, dann auf jeden Fall, dass eingesetzte Backup-Mechanismen auch auf ihre Funktionstüchtigkeit überprüft werden müssen. Außerdem sollten Administratoren nach einer gewissen Uhrzeit vermutlich nicht mehr am Produktivsystem rumschrauben. Oder, wie es der für die Löschung verantwortliche Admin etwas verspätet einsieht: „Ich sollte heute nichts mehr mit Sudo ausführen.“

Ebenfalls interessant:

Finde einen Job, den du liebst

Bitte beachte unsere Community-Richtlinien

2 Reaktionen
crackzko

Nunja in den meisten fällen wäre es ja nicht ein kompletter Verlust des Quellcodes. Das Begründet sich ja mit der natur von git und den lokalen Repositories. Da werden sicherlich noch ein Paar teammitglieder ihre letzten Commits verfügbar haben.

Was ich eher als kritisch empfinde würde wären die Meta-Daten zu einem Programmierungsprojekt . Gitab bietet darüber hinaus ja wesentlich mehr features unde ine ausladene Historie und statistik. Ebenfalls ärgerlich wäre ein evtl. verlust der Ganzen "alten" oder der letzten Releases und Konfigurationsdateien in der CI umgebung, das Issue Tracking, die Wikis uvm.. Aber wie heiß es ja: "hätte hätte Fahrradkette", die Daten sind ja nicht Komplett weg. Lediglich ein Arbeitstag ... oder wenn man in einem Startup unterwegs ist, was bei der intensiven Nutzung von GitLab denkbar ist, ein halber Arbeitstag. Das Kann man in der Regel wieder aufholen. Darüber hinaus wird sich GitLab für diesen Schnitzer sicherlich was einfallen lassen um zumindest die zahlende Kundschaft milde zu stimmen.

Was ich aber GitLab sehr hoch anrechne ist, wie transparent mit der problemlösung umgegangen wird. Das Google Docs war schon schön jedoch ist der youtube Livestream echt eine neue Liga in der Unternehmenskommunikation bei Fehlern. Ich kann mir nur vorstellen unter welchen druck die Admins bei GitLab jetzt stehen und das sie dann das Problem auch noch in einem Livestream zu lösen, was den Druck ebenfalls noch einmal erhöht, verdient meinen vollsten Respekt. Insgesamt unterstreicht es IMHO die Annahme, dass die Transparenzphilosophie von OpenSource bei GitLab tief verankert ist.

Interessant wäre, warum kein Staging für den Test für das "recovern" von Backups zum einsatz kam. Vielleicht erklärt sich das Unternehmen diesbezüglich mal ausführlich. Wobei ich die Vermutung habe, dass es aufgrund der Kosten nicht realisierbar war.

Antworten
Karl Marks

Und ergänzend: eigene Backups fahren! (dies kann man in dem Fall natürlich 'nur' für die sources machen - aber das sollte trotzdem getan und erwähnt werden).

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.