Die KI hat meine Projektdatenbank gelöscht – meine Erfahrungen mit (fehlenden) Backups

Für die Entwicklung nutze ich heute natürlich KI. Wer sie im Jahr 2026 noch nicht verwendet, ist meiner Meinung nach völlig verrückt. Manuell programmiere ich inzwischen praktisch gar nicht mehr, weil die KI meine Entwicklung schätzungsweise um 80 % beschleunigt hat — und das ist eine Zahl, die man einfach nicht ignorieren kann. Daher empfehle ich den Einsatz von KI ganz eindeutig.

Was mich in letzter Zeit allerdings wirklich amüsiert hat, ist etwas anderes. Schon lange bin ich auf Reddit immer wieder auf diese berüchtigten Horrorgeschichten gestoßen — Geschichten, in denen eine KI innerhalb weniger Sekunden jemandem die gesamte Produktionsdatenbank gelöscht hat. Ich habe das immer als Warnung verstanden, mir aber gleichzeitig gesagt, dass mir so etwas nicht passieren könne. Schließlich verwende ich ausschließlich Flaggschiffmodelle und habe alles sauber voneinander getrennt. Und es passierte nichts. Monate, über ein Jahr lang nichts.

Bis jetzt.

Ernste Nachricht für dich — ich breche die Tests ab

Vor Kurzem habe ich meinen Blog codedtrip.com neu programmiert — ich plane einen Mitgliederbereich, Kommentare, ein paar Neuerungen und eine etwas bessere Infrastruktur für die Leser. Die KI arbeitete ruhig im Hintergrund an irgendetwas, als plötzlich — und wirklich völlig aus dem Nichts — eine Nachricht auftauchte, die ich eine Weile nur mit offenem Mund „anstarrte“. Sie amüsierte mich und erschreckte mich zugleich ein wenig:

„Ernste Nachricht für dich — ich breche die Tests ab. Die Dev-DB wurde während der Tests geleert.“

Was war eigentlich passiert? Bei den ersten Versuchen, die Tests auszuführen, kam es zu einer unglücklichen Kombination aus einer falsch eingestellten Konfiguration und einem automatischen Mechanismus, der die Datenbank vor den Tests zurücksetzt. Statt das Zurücksetzen für die Testdatenbank auszuführen, wurde es für die Dev-Datenbank gestartet — und innerhalb einer einzigen Sekunde war sie vollständig leer.

Alle Anwendungsdaten waren verschwunden. Übrig blieben nur die Systemtabellen, aus denen sich kaum noch etwas Sinnvolles zusammensetzen lässt.

Zum Glück handelte es sich nur um die Dev-Datenbank, daher hat mich das ehrlich gesagt nicht besonders beunruhigt. Ich stellte sie wieder her, führte die Migrationen erneut aus, spielte die Seed-Daten ein und machte weiter. Kein Problem, keine Panik. Eine interessante Erfahrung mehr für die Sammlung.

Die Namen der DB-Tabellen usw. habe ich aus Sicherheitsgründen geschwärzt.

Bei Produktionsdatenbanken hört der Spaß jedoch auf

Ich kann mir jedoch sehr gut Entwickler vorstellen, die sogenanntes Vibe-Coding betreiben, kein einziges Backup haben, direkt mit der Produktionsdatenbank verbunden sind und von einem solchen Desaster im echten Betrieb getroffen werden. Wenn sie keine Sicherungen haben, ist schlicht alles futsch.

Und kommt das tatsächlich vor? Daran besteht kein Zweifel. Der wohl bekannteste Fall der letzten Zeit ereignete sich im Januar 2017 bei GitLab. Für alle, die diesen Vorfall nicht kennen: Einer der Ingenieure versuchte, eine Verzögerung bei der Replikation zwischen der primären und der replizierten Datenbank zu beheben, und wollte im Rahmen der Reparatur das Datenverzeichnis auf der Replik leeren. Allerdings war er auf dem Primärsystem angemeldet. Bis er den Vorgang abbrechen konnte, waren von 300 GB an Live-Daten nur noch etwa 4,5 GB übrig. GitLab verlor damals sechs Stunden an Daten — Issues, Merge Requests, Kommentare und Benutzer. Und noch schlimmer: Von fünf eingesetzten Backup-Systemen funktionierte kein einziges richtig. Das einzige brauchbare Backup war eines, das derselbe Ingenieur durch reinen Zufall sechs Stunden zuvor manuell erstellt hatte, als er an etwas anderem arbeitete. Ironischerweise rettete seine eigene Paranoia somit seinen eigenen Fehler. Die Wiederherstellung dauerte mehr als achtzehn Stunden, und GitLab übertrug sie live auf YouTube — bis heute ist das eine der lehrreichsten Postmortem-Geschichten der Branche.

Und leider ist mir das ebenfalls schon passiert

Mir selbst ist vor ungefähr zwei Jahren etwas Ähnliches passiert, glücklicherweise jedoch ohne Beteiligung von KI.

Ich nahm in einem Datenbankclient schnell eine Änderung am Projekt Editee vor. Dort habe ich immer drei Datenbanken untereinander geöffnet — die Produktions-, die Staging- und die Dev-Datenbank. Damals war die Aufteilung einfacher als heute; inzwischen sind unsere Datenbanken je nach Dienst unterschiedlich aufgeteilt. Wegen eines Problems mit der Zahlungsintegration musste ich schnell eine Tabelle leeren und gab den Befehl ein, sie zu löschen.

In der Eile bemerkte ich jedoch nicht, dass ich im Client versehentlich auf den benachbarten Tab gewechselt war — auf die Produktionsdatenbank.

Also löschte ich die Tabelle in der Produktion.

Zum Glück verfügen wir über ein sehr robustes Backup-System, sodass keine Daten verloren gingen. Ich musste jedoch die Produktionsdatenbank wiederherstellen — und da wir wirklich große Datenmengen haben, dauerte der Ausfall fast eine Stunde. Das ist nicht mit einem einzigen Klick erledigt. Es war jedoch eine sehr interessante und notwendige Erfahrung, die mich in einer Regel noch mehr bestärkt hat: Backups erstellen, Backups erstellen, Backups erstellen. Und dann noch einmal ein Backup erstellen.

Wasser im Rechenzentrum oder warum ich bei Backups paranoid bin

Meine Backup-Paranoia ist allerdings nicht dadurch entstanden. Sie begann viel früher — und sehr viel schmerzhafter.

Ich glaube, es war im Jahr 2012, also inzwischen schon fast mehr als 14 Jahre her. Damals hatten wir Server in einem Prager Rechenzentrum von Casablanca und in dessen Cloud-Hosting Big Blue One, das ständig damit prahlte, über eine vollständig gespiegelte Redundanz zu verfügen — eins zu eins in ein zweites Rechenzentrum in Ostrava repliziert, sodass beim Ausfall eines Rechenzentrums das andere sofort den Betrieb übernehmen würde. Das klang großartig.

Über dem Rechenzentrum befand sich jedoch eine Sporthalle (ja, eine Sporthalle). Und in dieser Sporthalle platzte eine Wasserleitung. Das Wasser sickerte durch die Decke in die Räume des Rechenzentrums, überflutete die Server — und sie funktionierten einfach nicht mehr. Die Wiederherstellung dauerte fast 14 Tage, und am Ende konnten unsere Daten überhaupt nicht wiederhergestellt werden. Wir verloren alles, was sich auf diesen Servern befand.

Zum Glück hatte ich damals zwei Tage vor dem Vorfall ein großes manuelles Backup erstellt (damals machte ich solche Sicherungen eher aus Intuition als nach einem Prozess oder einem festen Zeitplan regelmäßig). Ich verbrachte die ganze Nacht damit, alles wiederherzustellen und an einen anderen Ort zu migrieren — ich glaube, wir wechselten damals zu DigitalOcean, wo seitdem nie etwas Vergleichbares passiert ist und alles hervorragend funktioniert.

Das war für mich eine eindringliche Lektion. Vertrauen Sie dem Versprechen eines Anbieters über replizierte Redundanz niemals vollständig, solange Sie sie nicht selbst überprüft haben.

Wenn ein ganzes Rechenzentrum abbrennt — der Fall OVH 2021

Falls Sie Wasser in einem Rechenzentrum für extrem halten: Die wohl eindringlichste Warnung der vergangenen Jahre kam am 10. März 2021. Damals brannte in Straßburg das Rechenzentrum SBG2 des französischen Unternehmens OVHcloud, eines der größten europäischen Cloud-Anbieter, vollständig nieder. Das 500 m² große Gebäude SBG2 wurde komplett zerstört und das benachbarte SBG1 schwer beschädigt. Als wahrscheinliche Ursache wurden zwei kurz zuvor reparierte USV-Backup-Einheiten identifiziert, die überhitzt waren.

Was an dieser Geschichte jedoch noch interessanter ist: Zahlreiche Kunden verloren ihre Daten für immer — darunter auch solche, die für Backups zusätzlich bezahlt hatten. Ein französisches Gericht entschied später in mehreren Fällen, dass OVHcloud die Backups der Kunden im selben Rechenzentrum wie die Produktivdaten gespeichert hatte. Als also die Produktionssysteme verbrannten, verbrannte auch das „Backup“. Bei einem Kunden nahm die Geschichte eine noch absurdere Wendung: OVH behauptete, die Daten von dessen Backup-Server wiederhergestellt zu haben, doch der Server sei angeblich ohne Vorwarnung eingeschaltet worden, woraufhin ein automatisches Skript die Kundendaten als „alt“ löschte. Der Kunde erhielt daraufhin einen leeren Server zurück.

Das beliebte Spiel Rust verlor damals seine kompletten europäischen Spielserver, ohne Möglichkeit zur Wiederherstellung. Insgesamt sollen mehr als 130 Unternehmen von dem Brand betroffen gewesen sein, die sich anschließend zu einer Sammelklage zusammenschlossen.

Die Lehre daraus? Ein Backup, das im selben Rechenzentrum wie die Produktion gespeichert ist, ist kein Backup. Es ist eine Kopie.

Wie ich Backups erstelle

Aufgrund all dieser Erfahrungen habe ich eine Backup-Paranoia entwickelt, die schon an Besessenheit grenzt. Bei Editee haben wir:

• Stündliche Backups an sechs verschiedenen Standorten auf mehreren Kontinenten.

• Einmal pro Woche große vollständige Backups mit langer Aufbewahrungsdauer.

• Für Produktionsdatenbanken sekundengenaue Point-in-Time-Backups mit einer Aufbewahrungsdauer von bis zu einer Woche.

• Ich sichere auch GitHub — ja, sogar GitHub.

• Und manuelle Checkpoints vor jedem größeren Eingriff.

Unsere Backups haben also ein wirklich großes Datenvolumen und kosten einiges an Geld. Doch sobald etwas schiefgeht (und früher oder später geht immer etwas schief), ist das eine Investition, die sich schon bei einer einzigen Wiederherstellung auszahlt.

Was lässt sich abschließend sagen?

KI ist ein unglaubliches Werkzeug und hat meine Entwicklung so stark beschleunigt, dass ich mir die Arbeit ohne sie gar nicht mehr vorstellen kann. Gleichzeitig ist sie jedoch ein weiterer Akteur an der Tastatur, der einen Fehler machen kann. Genauso, wie Sie selbst über einen Datenbankclient einen Fehler machen können, wie ein Cloud-Anbieter einen Fehler machen kann oder wie eine geplatzte Wasserleitung über einem Rechenzentrum beziehungsweise eine überhitzte USV-Einheit einen Fehler verursachen kann.

Für mich persönlich hat das nur eine Regel bestätigt, an die ich mich seit mehr als zehn Jahren halte:

Sichern Sie alles. Und sichern Sie es anschließend noch einmal. Und bewahren Sie eine Kopie der Backups an einem völlig anderen Ort auf.

Bei mir wurde glücklicherweise nur die Dev-Datenbank geleert. Es hätte jedoch sehr viel schlimmer ausgehen können — und genau deshalb ist mein Backup-System an allen möglichen Orten 20-fach abgesichert. Denn man weiß nie, wann man es brauchen wird. Und glauben Sie mir: Dieser Tag wird kommen. Die Frage ist nicht, ob, sondern nur wann.