Letzte Änderung am 22. April 2017 by Christoph Jüngling
Cumulonimbus im Sonnenuntergang über der Po-Ebene
Von Mariofan13 – Eigenes Werk, Lizenz CC BY-SA 3.0, Link
Die Begeisterung für Cloud-Dienste ist ungebrochen. Wolke über Wolke türmt sich auf wie bei einer Cumulonimbus, bis dann das reinigende Gewitter auf die Welt hernieder bricht. Ein solches Gewitter hat sprichwörtlich die Firma Gitlab getroffen (siehe Blogbeitrag auf gitlab.com). Das hat in beiden Fällen unter Umständen weitreichende Folgen.
Das letzte erreichbare Backup war offenbar 6 Stunden alt, weshalb alle Eintragungen in diesem Zeitraum verloren gingen. Das betrifft nach Angaben von Gitlab die Tickets, Merge Requests (das sind Angebote anderer Entwickler, ihren Code in das Projekt zu integrieren), Benutzer, Kommentare und Code-Snippets.
Yesterday we had a serious incident with one of our databases. We lost 6 hours of database data (issues, merge requests, users, comments, snippets, etc.) for GitLab.com.
Was dieses “etc.” allerdings bedeutet, ist nicht so ganz klar. Immerhin schreiben sie weiter, sind die Code-Repositories und die Wikis nicht betroffen, ebenso alle selbst gehosteten Repositories (also die, die auf dem eigenen Server liegen). Hier ist ausdrücklich von “Datenbanken” die Rede. Im Hinblick auf den Code wäre das allerdings tatsächlich das geringste Problem. Da Gitlab, wie der Name vermuten lässt, primär mit Git arbeitet (und die Entwickler da draußen hoffentlich auch), hat nahezu jeder Entwickler eine vollständige Kopie des Projekt-Repositories auf seinem Rechner. Dies kann jederzeit zurückgespielt werden.
Ich sage “nahezu”, denn theoretisch unterstützt Git sog. “shallow clones”, das sind Clones, die nur einen gewissen Restbestand der Commits lokal halten. Dieses Verfahren bietet sich bei sehr großen Projekten für die Entwickler an, die nicht in der uralten Historie des Projektes herumsuchen wollen oder müssen.
Einen solchen Shallow Clone legt man beim Clonen übrigens ganz einfach an:
git clone --depth 100 https://entferntes.repository.com
Der Zusatz “depth” und der Zahlenwert geben an, wie viele der letzten Commits im lokalen Repository enthalten sein sollen.
Das Backup bei Gitlab ist inzwischen wieder eingespielt, die Analyse geht weiter.
Update 18:14 UTC: GitLab.com is back online
Laut Heise war die Ursache ein versehentlich gelöschter Ordner. Der Redakteur dort bringt es auf den Punkt: “Auch das Testen der Datenwiederherstellung scheint in jüngster Zeit stiefmütterlich behandelt worden zu sein.”
Hoffen, wir, dass sich die Schäden für die betroffenen Teams in Grenzen halten.
1 Kommentar
Die allgegenwärtige Angst vor Clouddiensten kann ich nicht mehr nachvollziehen. Mir ist mal die Backupplatte und gleich danach mein Rechner gestorben. Das war schlimm. Ich wäre froh über nur 6 Stunden Verlust gewesen. Seitdem lege ich soviel ich kann in die Cloud. Inzwischen könnte sogar mein Rechner abfackeln. Klar, dann wäre etwas Arbeit nötig, doch meine Daten sind (irgendwo) gut aufgehoben.