Ein KI-Agent hat meine Supabase-Daten gelöscht. Was hole ich zurück?

Du hast den Agenten gebeten, ein paar Testzeilen aufzuräumen, oder eine Migration zu reparieren, die nicht durchlief. Er hat das SQL selbst geschrieben, es gegen das Projekt laufen lassen, das deine Live-App benutzt, und gemeldet, dass es erledigt sei. Die App lädt weiterhin. Die Tabelle ist leer.

Wenn ein KI-Agent Daten aus deiner Datenbank gelöscht hat, stand schon vorher fest, was du zurückholen kannst. Die nächsten Minuten entscheiden, wie viel davon übrig bleibt.

Hier ist der Punkt, den die meisten Antworten darauf verfehlen. Sie sagen dir, du sollst den Code zurücksetzen oder den Agenten bitten, es rückgängig zu machen. Keines von beidem rührt deine Daten an, und während du es versuchst, wird das eine, was du noch in der Hand hast, still schlechter: was deine App gerade in die Datenbank schreibt.

Was kann ich zurückholen, nachdem eine KI meine Daten gelöscht hat?

Was in der letzten Kopie deiner Datenbank stand, die vor dem Löschen gezogen wurde, und nichts, was danach entstanden ist.

Das ist die ganze Antwort, und das meiste daran wurde vor Wochen entschieden. Es gibt hier keinen forensischen Schritt, nichts zu entlöschen, kein Protokoll, das in Supabase darauf wartet, abgespielt zu werden. Eine Zeile, die ein DELETE oder ein DROP TABLE entfernt hat, ist in dem Moment aus der Datenbank verschwunden, in dem die Anweisung bestätigt wird. Zurück kommt eine Kopie, und eine Kopie existiert entweder oder eben nicht.

Vor dir liegen also zwei Aufgaben. Herausfinden, welche Kopien es gibt. Und verhindern, dass die Lücke zwischen der neuesten und jetzt noch teurer wird, als sie ohnehin schon ist.

Halte zuerst an, was in die Datenbank schreibt

Bevor du nach einem Backup suchst, schalte alles ab, was neue Zeilen schreibt. Lesen ist in Ordnung.

Dafür gibt es zwei Gründe, und der zweite erwischt Leute.

Der erste: Eine Wiederherstellung ist keine Zusammenführung. Eine Kopie zurückzuspielen ersetzt die Tabellen darin durch das, was sie damals enthielten, und alles danach Geschriebene geht mit. Ein Kunde, der sich in der Stunde anmeldet, in der du das hier liest, ist eine Zeile, die du später selbst löschst, in einem Schritt, für den du dich bereits entschieden hast.

Der zweite: Manche Wege werden schlechter, während du wartest. Die Wiederherstellung auf einen Zeitpunkt bei Supabase dreht das ganze Projekt auf eine Minute deiner Wahl zurück, und je weiter sich die App vom Fehler entfernt, desto mehr echte Arbeit wirft dieses Zurückdrehen zusammen mit dem Schaden weg.

Eine Stunde hinter einem Wartungshinweis ist billig. Jemandem zu erklären, dass seine Bestellung angelegt und dann absichtlich entfernt wurde, ist es nicht.

Kann ich den Agenten bitten, es rückgängig zu machen?

Nein. Er hatte deine Zeilen nie.

Der Agent hat eine Anweisung geschrieben, und deine Datenbank hat sie ausgeführt. Was er jetzt hat, ist ein Protokoll dieses Gesprächs, und das ist etwas anderes als eine Kopie der Tabelle. Bitte ihn, das Löschen umzukehren, und du bekommst eine selbstsichere Antwort, plausibles SQL und keine Daten.

Über das Risiko lohnt es sich genau zu sprechen, weil die Bitte harmlos wirkt. Den Agenten erneut laufen zu lassen heißt: eine zweite unbeaufsichtigte Sitzung gegen eine Live-Datenbank, die bereits etwas verloren hat. Entscheidet er, die fehlende Tabelle repariere man am besten, indem man eine anlegt, steht jetzt eine neue leere Tabelle dort, wo die alte war, und du hast den Verlust schwerer beschreibbar gemacht für den, der dir als Nächstes hilft.

Nimm ihn vom Projekt, bis du weißt, wo du stehst. Dasselbe gilt für den Versionsverlauf deines Builders: Deinen Code auf heute Morgen zurückzusetzen stellt deine Seiten wieder her und lässt deine Daten genau dort, wo sie jetzt sind, aus Gründen, die man einmal verstanden haben sollte.

Wo du nachsiehst, in dieser Reihenfolge

Arbeite diese Liste ab und halte bei der ersten Stelle an, die es gibt. Sie ist danach sortiert, wie viel von deinen Daten zurückkommt, und nicht danach, wie einfach es ist.

Jeder Weg, der überhaupt etwas zurückgibt, hat dieselbe Voraussetzung, und die entscheidet die Sache: Er musste vor dem Löschen schon da sein. Keiner lässt sich jetzt anschalten und rückwärts reichen. Welchen Supabase-Tarif du hast, entscheidet über die oberen zwei, und das Nachsehen dauert etwa zwei Minuten.

Was zurückkommt und was in die Lücke fällt

Die Kopie, so wie sie war, und nichts, was danach passiert ist.

Die Zeilen, die zwischen dieser Kopie und dem Löschen entstanden sind, sind nicht beschädigt und liegen nicht irgendwo unglücklich herum. Sie wurden nirgends aufgeschrieben außer in der Datenbank, aus der sie entfernt wurden. Das ist der Teil, den man vor einer leeren Tabelle schwer akzeptiert, weil etwas zu verlieren sonst heißt, dass es noch irgendwo ist.

Wie breit dieses Band ist, hängt allein daran, was die Kopien gezogen hat. Ein nächtliches Backup kann einen ganzen Arbeitstag hineinlegen. Die Wiederherstellung auf einen Zeitpunkt verengt es auf eine Minute, und das ist der Grund, warum sie extra kostet. Ein Dump, den du gezogen hast, als es dir gerade einfiel, legt hinein, wie lange das her ist.

Es gibt eine Variante, in der die Lücke kaum zählt, bei einer App, deren Daten überwiegend deine eigenen Inhalte sind und sich langsam ändern. Und es gibt eine, in der sie sehr zählt: alles mit Bestellungen, Nachrichten oder Anmeldungen, wo ein Tag Zeilen ein Tag Menschen ist, denen es auffällt.

Der Agent hat einen Teil davon gelöscht, nicht alles

Dann hast du eine echte Wahl zu treffen, und keine der beiden Antworten ist sauber.

Eine Wiederherstellung legt nicht die fehlenden Zeilen zurück und lässt den Rest in Ruhe. Sie ersetzt die Tabellen der Kopie durch das, was diese Tabellen damals enthielten, komplett. Wiederherstellen holt zurück, was der Agent entfernt hat, und macht jede gute Zeile rückgängig, die seitdem geschrieben wurde. Nicht wiederherstellen behält die guten Zeilen und lässt das Loch.

Was richtig ist, hängt daran, wie viel echte Arbeit nach der Kopie liegt. Lautet die Antwort fast keine, stell wieder her und mach deinen Tag weiter. Lautet sie drei Tage Kundendaten, gewinnt meist der langsamere Weg: die überlebenden Zeilen zuerst exportieren, wiederherstellen, dann die exportierten Zeilen obendrauf zurücklegen. Das ist fummelig, und es ist der einzige Weg, der nichts verliert.

Es ist auch das Argument dafür, die Datenbank in ihrem jetzigen kaputten Zustand zu kopieren, bevor du überhaupt etwas anfasst. Wie du dich auch entscheidest, du willst zu dem Stand zurückkönnen, mit dem du angefangen hast.

So läuft dieselbe Stunde, wenn es schon eine Kopie gibt

Kürzer, und eher eine Entscheidung als eine Suche. Du wählst eine Kopie, du siehst nach, was sie enthielt, und du drückst den Knopf.

Genau das macht Reeve Care: geprüfte Kopien deiner Supabase-Datenbank nach Zeitplan, verschlüsselt und außerhalb deines Supabase-Kontos aufbewahrt, mit einer Wiederherstellung auf einen Klick dahinter. Bevor eine Wiederherstellung läuft, zieht sie eine frische Kopie des aktuellen Stands, damit auch sie sich rückgängig machen lässt.

Die Grenzen gehören in denselben Atemzug, denn nur wer sie kennt, kann entscheiden, ob es passt:

• Es kopiert deine Datenbank, und die Dateien, die deine Nutzer hochgeladen haben, sobald du deine Storage-Buckets verbindest. Das ist optional und braucht einen zweiten Schlüssel.
• Es arbeitet heute mit Supabase und mit sonst nichts.
• Du stellst auf eine Kopie wieder her, die existiert, nicht auf eine beliebige Minute, die du nennst. Schlimmstenfalls verlierst du ein Intervall, also bis zu einer Nacht im Einstiegstarif und weniger in den beiden darüber.
• Anmeldekonten werden nie angerührt. Niemand wird ausgeloggt, gelöscht oder zurückgeholt.
• Der Datenbankschlüssel, den es aufbewahrt, kann nur lesen, und das war das Versprechen, als du ihn angebunden hast. Daten zurückzuschreiben braucht einen, der schreiben darf, also fragt eine Wiederherstellung jedes Mal nach deinem Datenbankpasswort und behält keines davon. Der optionale Schlüssel für deine Dateien kann schreiben, weil Supabase für Storage keinen Nur-Lese-Schlüssel ausgibt, und die Seite, auf der du ihn übergibst, sagt das vorher.

Was die einzelnen Tarife abdecken, steht auf der Startseite. Willst du dafür nichts zahlen, ist die schlichte Fassung desselben Schutzes ein pg_dump nach einem Zeitplan, den du wirklich einhältst, aufbewahrt an einem Ort, den der Verlust deines Supabase-Kontos nicht mitnimmt. Die drei Wege und was jedem davon entgeht geht das ohne Verkaufsrede durch.

Diese Stunde ist auf der Seite zu Supabase-Backups Kopie für Kopie dargestellt.

Was du jetzt sofort tun solltest

Bevor du diesen Tab schließt: Öffne dein Supabase-Projekt und finde heraus, ob überhaupt irgendetwas deine Datenbank kopiert, und schreib dir auf, wo diese Kopie liegt. Die 10-Minuten-Sicherheitscheckliste deckt das zusammen mit dem Übrigen ab, was bei einer frisch gestarteten App zu bestätigen ist.