Supabase-Backup wiederherstellen, und was danach kaputt ist

Irgendetwas in deiner Datenbank ist kaputt, und ausnahmsweise hast du eine Kopie davon. Jetzt schaust du auf einen Knopf, den du noch nie gedrückt hast, in einem Projekt mit echten Nutzern darin, und überlegst, was er gleich mit ihnen macht.

Hier ist der Teil, den Anleitung um Anleitung auslässt. Fast jeder Artikel darüber, wie man ein Supabase-Backup wiederherstellt, endet in dem Moment, in dem die Wiederherstellung fertig ist, und genau dort fangen die meisten Schwierigkeiten an. Der übliche Ausgang ist nicht eine Wiederherstellung, die scheitert. Es ist eine, die gelingt und die App trotzdem kaputt zurücklässt, denn ein Datenbank-Backup enthielt immer nur die Datenbank.

Es hilft, das nicht länger als „meine Daten zurückholen" zu sehen. Eine Wiederherstellung tauscht deine Datenbank gegen eine ältere aus, näher am Austausch eines ganzen Aktenschranks als am Zurücklegen einer einzelnen Mappe. Alles Weitere folgt daraus.

Wie stelle ich ein Supabase-Backup wieder her?

Drei Wege, und welcher davon dir heute offensteht, wurde vor heute entschieden.

Die ersten beiden legen deine Daten dorthin zurück, wo sie ohnehin schon waren. Der dritte ist der einzige, der sie woanders hinlegen kann, und das brauchst du an dem Tag, an dem das Problem dein Konto ist und nicht deine Daten.

Falls du nicht sicher bist, was davon du hast: welchen Supabase-Plan du hast, entscheidet die ersten beiden, und das nachzusehen dauert etwa zwei Minuten.

Kopiere erst, was du jetzt hast

Nimm zuerst eine Kopie der Datenbank in ihrem aktuellen kaputten Zustand. Das ist ein einziger Befehl, und er ist das, was jede weitere Entscheidung umkehrbar macht.

pg_dump "postgresql://…deine Verbindungszeichenfolge…" \
  --clean --if-exists --no-owner \
  --file before-restore-2026-08-24.sql

Dafür gibt es zwei Gründe, und den zweiten lernen die meisten hinterher.

Der erste ist, dass eine Wiederherstellung ein Austausch ist. Die Tabellen aus der Kopie kommen genau so zurück, wie sie waren, also geht jede Zeile mit, die seitdem hineingeschrieben wurde. Eine Kundin, die sich heute Morgen angemeldet hat, ist eine Zeile, die du gleich absichtlich löschst.

Der zweite ist, dass deine kaputte Datenbank immer noch der einzige Ort ist, an dem ein Teil deiner Daten überhaupt existiert. Ist die Kopie von Dienstag und der Schaden von Donnerstag, dann liegt alles, was am Mittwoch entstanden ist, gerade jetzt vor dir und sonst nirgends. Spielst du darüber, verschwindet es ein zweites Mal, diesmal durch deine Hand und nicht durch den Unfall.

Schalte während der Arbeit alles ab, was neue Zeilen schreibt. Die Begründung ist dieselbe wie nach jedem versehentlichen Löschen: die Lücke zwischen der Kopie und jetzt wird teurer, je länger die App sie weiterfüllt.

Wiederherstellen im Supabase-Dashboard

Das ersetzt die Datenbank in deinem Projekt durch die Kopie, die du wählst, und das Projekt ist währenddessen nicht erreichbar.

Öffne das Projekt, mit dem deine App spricht, geh auf Database und dann Backups und wähle die datierte Kopie. Die genauen Schritte liest du in der Backup-Dokumentation von Supabase, denn das Dashboard wird umgeräumt, und diese Seite merkt davon nichts.

Wie lange es dauert, hängt von der Größe deiner Datenbank ab, das ist die Antwort von Supabase selbst. Setze vorher einen Wartungshinweis.

Point-in-Time Recovery ist derselbe Vorgang mit feinerem Regler. Statt letzte Nacht zu wählen, nennst du eine Minute, und das Projekt spult dorthin zurück. Supabase nennt das destruktiv, und das ist das richtige Wort dafür. Die Hinweise im Support sagen außerdem, dass eine Point-in-Time-Wiederherstellung erst starten kann, wenn vorhandene Replikations-Slots und Subscriptions entfernt wurden. Falls in deiner App also etwas Datenbankänderungen laufend mitliest, ist das ein Schritt vorher statt ein Fehler auf halber Strecke.

Keiner der beiden Wege kann deine Daten in ein anderes Projekt legen. Beide wirken auf das Projekt, in dem du gerade stehst, also stehen beide an dem Tag nicht zur Verfügung, an dem der Zugang zum Konto das Kaputte ist.

Eine Dump-Datei mit psql wiederherstellen

Du richtest psql auf ein Projekt und spielst die Datei hinein. Dieses Projekt kann das alte sein oder ein brandneues auf einem Konto, das du heute Morgen eröffnet hast.

psql -d "postgresql://…Verbindungszeichenfolge des Zielprojekts…" \
  --variable ON_ERROR_STOP=1 \
  --single-transaction \
  --file backup-2026-08-09.sql

Zwei dieser Optionen solltest du verstehen, denn das Standardverhalten von psql ist das überraschende.

ON_ERROR_STOP=1 hält beim ersten Fehler an. Ohne die Option liest psql den Fehler, gibt ihn aus und macht mit der nächsten Zeile weiter, sodass eine Datei, die in Zeile 400 von 30.000 scheiterte, trotzdem mit einer Eingabeaufforderung endet, die nach Erfolg aussieht, über einer Datenbank, der alles nach dieser Zeile fehlt. --single-transaction fasst die ganze Datei zu einem Vorgang zusammen, sodass ein Fehler die Datenbank so zurücklässt, wie sie war, statt halb verändert.

Dann die Zugangsdaten, an denen viele hängen bleiben. Ein Backup einzuspielen heißt schreiben, also braucht es etwas, das schreiben darf. Ein anon-Schlüssel schafft das nicht und ein nur lesender ebenso wenig. Was psql will, ist das Datenbank-Passwort des Zielprojekts, und das steht in den Supabase-Projekteinstellungen unter Database.

Was zurückkommt, hängt davon ab, was in der Datei steht, und das wurde beim Erstellen des Dumps entschieden. Deine Benutzerkonten sind der Teil, den du prüfen solltest, bevor du dich darauf verlässt. Sie liegen in einem Schema namens auth neben den gehashten Passwörtern, und Supabase beschreibt ihren Umzug zwischen Projekten als eigenen Vorgang mit eigenen Schritten. Wenn du in ein neues Projekt wiederherstellst und die Leute sich mit ihrem bisherigen Passwort anmelden sollen, lies diese Seite vorher.

Und ein neues Projekt hat eine neue URL und neue Schlüssel. Deine App zeigt weiterhin auf das alte, bis du das änderst, und damit fängt der nächste Abschnitt an.

Wiederhergestellt, und die App ist immer noch kaputt

Das ist der normale Ausgang. Es ist fast immer eine von fünf Sachen, und die erste kostet eine Minute.

Die vierte verdient die Aufmerksamkeit. Leserecht und Schreibrecht werden getrennt vergeben, und eine Wiederherstellung kann das eine treffen und das andere verfehlen. Also füllen sich die Seiten mit deinen Daten, alles sieht wiederhergestellt aus, und dann bekommt die erste Person, die ein Formular abschickt, einen Fehler. Ein Blick auf die App zeigt dir das nie, denn Hinsehen ist Lesen.

Woran du erkennst, ob die Wiederherstellung wirklich geklappt hat

Melde dich an, finde eine Zeile, die du benennen kannst, und schreibe dann eine. In dieser Reihenfolge, und die letzte ist die Prüfung, auf die es ankommt.

• Melde dich über die App an, so wie es ein Nutzer täte, statt den Supabase-Tabelleneditor zu öffnen. Das prüft die App, die Verbindung und die Benutzerkonten in einem Rutsch.
• Finde eine Zeile, an die du dich erinnerst. Eine bestimmte Bestellung, eine namentlich bekannte Kundin, das Letzte, was du vor dem Ausfall angelegt hast. „Die Daten sehen aus, als wären sie da" ist ein Gefühl; eine Zeile, die du benennen kannst, ist eine Prüfung.
• Vergleiche eine Anzahl mit deiner Erwartung. Öffne deine größte Tabelle im Supabase-Editor und lies die Zahl der Zeilen. Eine Wiederherstellung, die auf halber Strecke abgebrochen ist, zeigt sich hier meist als eine zu kleine Zahl.
• Und dann schreibe etwas. Lege eine Zeile so an, wie ein Nutzer es tut: eine Testbestellung aufgeben, ein Profil speichern, einen Kommentar posten. Das ist die Prüfung, die fehlschlägt, wenn die anderen drei bestehen, und das Einzige, was belegt, dass die Wiederherstellung fertig ist.
• Öffne etwas, das ein Nutzer hochgeladen hat. Hat deine App Bilder oder Anhänge, klick eines an. Ob deine Dateien zurückgekommen sind, ist eine andere Frage als ob deine Zeilen es sind.

Was jetzt zu tun ist

Bevor du diesen Tab schließt, finde heraus, ob du überhaupt etwas hast, aus dem du wiederherstellen könntest, und wo es liegt. Diese eine Antwort entscheidet, welche Hälfte dieses Artikels du je brauchen wirst. Die 10-Minuten-Sicherheits-Checkliste deckt das neben dem Rest ab, was bei einer frisch gestarteten App zu prüfen ist, und der Supabase-Sicherheitsleitfaden geht durch, was sonst gerne offen bleibt.

Was Reeve Care am Tag der Wiederherstellung tut

Die Kopie existiert bereits, sie wurde bereits zurückgelesen und geprüft, und sie liegt außerhalb deines Supabase-Kontos. Damit wird aus der Stunde oben eine Entscheidung darüber, welche Kopie, und ein Knopfdruck.

Vier Dinge, die sich damit an diesem Artikel ändern.

Die Kopie ist geprüft, bevor du sie brauchst. Jedes Backup wird zurückgelesen und gegen das gezählt, was hineinging, und das Datum in deinem Dashboard ist die letzte Kopie, die bestanden hat, und nicht der letzte Versuch. Die halbfertige Wiederherstellung, vor der dieser Artikel warnt, ist ein Problem, das wir an einem gewöhnlichen Nachmittag finden, bevor es deins wird.

Die Sicherheitskopie ist kein Schritt, an den du denken musst. Ein Druck auf Wiederherstellen nimmt zuerst eine frische Kopie des aktuellen Zustands, sodass sich die Wiederherstellung selbst rückgängig machen lässt.

Deine hochgeladenen Dateien kommen mit zurück, sobald du deine Storage-Buckets verbindest. Das ist die Zeile in der Tabelle oben, die sonst keine gute Antwort hat.

Der Datenbankschlüssel, den wir halten, kann nur lesen. Eine Wiederherstellung muss schreiben, also fragt sie jedes Mal nach deinem Datenbank-Passwort und behält nichts davon. Der optionale Schlüssel für deine Dateien kann schreiben, weil Supabase für Storage keinen nur lesenden Schlüssel ausgibt, und die Seite, auf der du ihn einträgst, sagt das vorher.

Die Grenzen gehören in denselben Atemzug, denn du solltest sie vor dem Bezahlen kennen und nicht während eines Ausfalls:

• Es funktioniert mit Supabase und heute mit nichts anderem.
• Du stellst auf eine Kopie wieder her, die existiert, und nicht auf eine beliebige Minute. Schlimmstenfalls verlierst du ein Intervall, im Einstiegsplan bis zu einer Nacht und in den beiden darüber weniger.
• Benutzerkonten werden nie angefasst. Niemand wird abgemeldet, gelöscht oder zurückgeholt.

Lass deine Supabase-Backups so oder so eingeschaltet. Zwei Kopien an zwei Orten sind der ganze Gedanke, und die günstigere davon steckt schon in deinem Plan. Was jeder Care-Plan abdeckt, steht auf der Startseite.

Wenn du für nichts davon zahlen möchtest, funktioniert alles in diesem Artikel weiterhin. Ein pg_dump nach einem Zeitplan, den du auch wirklich einhältst, abgelegt an einem Ort, den der Verlust deines Supabase-Kontos nicht mitnimmt, plus eine Übungswiederherstellung pro Quartal, bringt dich den größten Teil des Weges. Die drei Wege und was jeder auslässt behandelt das ohne Verkaufsgespräch.

Der ganze Kreislauf ist Schritt für Schritt auf der Supabase-Backup-Seite aufgezeichnet: wie die Kopie Supabase verlässt, die Prüfung, die ihr folgt, und der Knopf, der sie zurücklegt.