Werden versehentlich Inhalte einer Webseite gelöscht, geht dies im Regelfall nicht mit schwerwiegenden Folgen einher. Hierfür existieren schließlich Backups, mit deren Hilfe die ursprünglichen Inhalte wieder regeneriert werden können. Das Beispiel von GitLab zeigt, dass es allerdings auch anders gehen kann. Hier haben fünf verschiedene Backups nicht geholfen, nachdem versehentlich die gesamte Datenbank gelöscht wurde.

GitLab und die Geschichte von schiefgelaufenen Backups

Vor einigen Jahren passierte einem Systemadministrator von GitLab ein folgenschwerer Fehler. Das System lief in den frühen Morgenstunden systemverzögert, worauf hin sich der übermüdete Admin an die Fehlersuche machte. Schnell hatte er eine Datenbank in Verdacht und gab den Befehl zum Löschen ein. Doch die Löschanweisung wurde für die falsche Datenbank eingegeben, die daraufhin ausradiert wurde. Den Fauxpas bemerkte der Administrator erst, als es für einen Stopp oder für eine Umkehr zu spät war. Das Ausmaß der Folgen erahnten die Systemadministratoren bei GitLab zu diesem Zeitpunkt allerdings noch nicht. Schließlich verfügte das Unternehmen über fünf verschiedene Backups, die für ebendiese Fälle angefertigt wurden.

Fünf Backups, keines funktionierte – warum der Online-Tech-Hub Schwierigkeiten hatte

Sicherung Nummer eins, das LVM-Snapshot-Backup, befand sich technisch nicht auf dem neuesten Stand. Daher hatte der Administrator sechs Stunden vor dem Systemausfall ein manuelles Backup erstellt. Dann gab es das zweite Feature, das in der Staging-Umgebung bereitstand und eigentlich funktionieren sollte. Doch hier wurden Webhooks entfernt und die Replikation ging ebenfalls schief, da die Quelle als nicht vertrauenswürdig eingestuft wurde.

Weiter nutzte GitLab die automatische Sicherungsfunktion mit einem unbekannten Speicherort. Doch auch hier lag ein Fehler vor: Die älteren Backups waren offensichtlich bereits bereinigt. Die vierte Methode bezog sich auf die Sicherungen in Azure. Dass lediglich die Inhalte vom NFS-Server, nicht aber die Daten vom DB-Server gesichert wurden, fiel erst auf, als man auf das Backup zugreifen und das System wieder herstellen wollte. Im Bucket von Amazon S3 gab es erst gar keine Backups, da der Versuch der Datensicherung bereits beim Hochladen scheiterte und im Laufe der Zeit schließlich unterging.

Nun blieb nur noch eine Lösung. Die manuell erstellte und bereits sechs Stunden alte Sicherung musste auf das System gespielt werden. Die aufgeführten Probleme sorgten im Zusammenspiel dafür, dass die GitLab Systemadministratoren schließlich einsehen mussten, dass durch die Löschung der Datenbank und die nicht funktionierenden Backups irreversible Schäden entstanden sind. Der Fall von GitLab mag zwar ein Einzelfall sein – dennoch zeigt er, dass ein Backup keine Absicherung gegen jegliche Verluste ist. Deshalb ist die Auswahl eines potenten Systems ebenso wichtig wie die tatsächliche Anfertigung des Backups.

Gute Backups erkennen – darauf kommt es an

Jede Sicherung ist besser als gar keine. Dennoch gilt: Je wichtiger die zu sichernde Masse an Daten ist, desto eher sollten sich Hosts nicht mit semiprofessionellen Tools und Möglichkeiten zufriedengeben, sondern nach einer qualitativen und maßgeschneiderten Lösung suchen. Wer zum Beispiel einen hohen Datenverkehr hat, wird mit Backups im Intervall von 24 Stunden kaum eine adäquate Datensicherung betreiben. Am Beispiel von GitLab zeigt sich, dass das manuell erstellte und bereits sechs Stunden alte Backup die einzige Chance war, die Webseite wieder aufzuspielen und den Fehler des Administrators zumindest teilweise zu beheben.

Backups sollen versehentlich gelöschte, beschädigte oder anderweitig defekte Daten retten und ein dysfunktionales System neu aufzusetzen. Die Sicherungslösung muss zum Nutzer passen und auf dem neuesten technischen Stand sein, was regelmäßige Updates voraussetzt. Ebenfalls sollte sie einfach bedienbar sein und der Webmaster sollte wissen, wo er seine Sicherung speichert. Der unbekannte Ort erschien GitLab als sichere Lösung – doch im Endeffekt hat das Unternehmen sein Backup so gut verborgen, dass es selbst nicht darauf zugreifen konnte.

Eine optimale Sicherungslösung sollte auf die Benutzeraktivität, das Kontingent der Dateneingabe und auf die Serverlast optimiert sein. Dies ermöglicht im Ernstfall den Zugriff auf eine vollständige Sicherung, sodass sich die Webseite leicht wiederherstellen lässt.

Die ideale Sicherung – einfach, schnell und standortunabhängig

Schwierig zu verwaltende und unverständliche Replikationsprozesse bieten keine professionelle Lösung für Backups, wie sich bei der Datensicherung in der Staging-Umgebung von GitLab zeigte. Allein die Wiederherstellung einer Webseite und die Vermeidung von Datenverlusten stellen selbst Herausforderungen dar. Ist der Wiederherstellungsprozess darüber hinaus unnötig komplex, kann das Projekt an der Bedienbarkeit der Sicherungslösung scheitern. Empfehlenswert ist auch, dass die Seitensicherung standortunabhängig erfolgt. Wer Backups auf seinen eigenen, im Unternehmen befindlichen Servern oder auf der Festplatte des Computers erstellt, kann im Falle eines Gerätedefekts oder eines Feuers nicht mehr darauf zugreifen.

GitLab wusste nicht, wo die Backups gespeichert wurden. Aus diesem Grund war es unmöglich, die gelöschte Datenbank in der Sicherung zu finden und sie so wieder herzustellen. Nur wer das Sicherungsziel kennt, kann im Bedarfsfall darauf zugreifen und das Backup nutzen. Wer auf manuelle Sicherungen nicht verzichten möchte, kann diese nebenbei durchführen und sollte sie auf einer externen Festplatte oder auf einem Datenstick, nicht aber auf dem PC speichern.

Einzelbereiche sichern? Nur eine vollständige Sicherung der Datenbank hilft im Ernstfall

Wie sich bei GitLab zeigte, bringt die Azure-Sicherung im Ernstfall nicht den gewünschten Erfolg. Eine Datensicherung von Teilbereichen kann zwar vor dem Totalverlust schützen, wird beim vollständigen Ausfall der Webseite aber kaum zur vollständigen Problemlösung führen. WordPress Backups sichern beispielsweise einige Bereiche der Webseite, doch in WooCommerce erstellte Tabellen mit benutzerdefinierten Inhalten sind in der Sicherungsfunktion ausgeschlossen.

Die besten Backups sind jedoch nutzlos, wenn der Nutzer nicht weiß, ob sie funktionieren und ob sie auf dem technisch neuesten Stand sind. Hätte GitLab die Testung in seine Sicherungsstrategie integriert, wäre im Vorfeld aufgefallen, welche Aspekte bei welcher Lösung nicht funktionieren. Wenn der Ernstfall zum Test wird, ist das Risiko von enormen Datenverlusten vorprogrammiert.

Fazit – Sicherungslösungen sollten bedarfsoptimiert und hochwertig sein

Trotz ihrer Bedeutung bei Datenverlusten machen sich nach wie vor zu wenig Seitenbetreiber über Sicherungen Gedanken. Dies kann jedoch im Ernstfall zu existenziellen Verlusten führen. Im Alltag hat der Systemadministrator oder der Webmaster meist keine Zeit für eine ausreichende manuelle Datensicherung. Deshalb sollte die Sicherung automatisiert und in regelmäßigen Abständen erfolgen. Je größer und umfangreicher eine Datenbank ist, desto häufiger sollte die Sicherung erstellt werden.

Der Verlust von Daten oder Datenbanken kann auch vorsichtige Administratoren ereilen, weshalb die Verwendung eines Backups unabdingbar ist. Hinzu kommen menschliche Fehler wie im Falle von GitLab. Doch auch Systemfehler, Serverabstürze und sonstige Einflüsse können dafür sorgen, dass eine Sicherung als Rettung in der Not vor Daten- und Geldverlusten schützt. Um den Zugriff im Ernstfall zu gewährleisten, muss der Ort der Sicherung bekannt sein. Nur so kann sie schnell gefunden und aufgespielt werden. Es empfiehlt sich daher, sich bereits frühzeitig und ohne einen aktuell vorherrschenden Bedarf mit Backups zu beschäftigen und so für den Fall der Fälle gerüstet zu sein.