Teste dein Supabase-Backup, bevor du es brauchst

Irgendwo liegt eine Datei mit deiner Datenbank darin. Eine GitHub Action schreibt jede Nacht eine, oder du hast Supabases drei Backup-Befehle einmal ausgeführt, oder dein Tarif zieht tägliche Kopien. Sie hat den richtigen Namen und ungefähr die Größe, die du erwarten würdest. Geöffnet hat sie noch nie jemand.

Hier ist der Teil, den die Einrichtungsanleitungen auf später verschieben: ein Backup, das nie wiederhergestellt wurde, ist eine Behauptung, keine Kopie. Die einzige Art, ein Supabase-Backup zu testen, ist, es absichtlich irgendwo einzuspielen, wo nichts davon abhängt, und nachzusehen, was zurückkommt. Ein Dump, der mittendrin abbricht, ein Dump ohne eine einzige Zeile und ein Dump des falschen Projekts liegen alle im Speicher und sehen genau aus wie ein guter.

Denk an einen Probealarm. Ein Gebäude macht ihn an einem gewöhnlichen Vormittag, wenn nichts brennt, weil niemand die Treppe zum ersten Mal an dem Tag hinuntergehen sollte, an dem sie voller Rauch ist. Draußen zählt jemand die Leute anhand der Liste, wer drin war, und jemand schreibt das Datum auf das Blatt an der Tür. Eine Wiederherstellungsübung ist dasselbe: den Weg gehen, zählen, aufschreiben.

Woher weiß ich, ob mein Supabase-Backup wirklich funktioniert?

Spiel es ein und sieh nach. Das ist der einzige Test, den es gibt, denn an der Datei selbst lässt sich ein gutes Backup nicht von einem kaputten unterscheiden.

Die Übung nimmt deine neueste Kopie, spielt sie in ein Projekt ein, an dem nichts hängt, und stellt dem Ergebnis drei Fragen. Ist jede Tabelle da, mit ungefähr so vielen Zeilen wie die Live-Tabelle? Stammt die neueste Zeile aus der Nacht, in der die Kopie gezogen wurde? Kannst du dich als du selbst anmelden? Eine gute Datei beantwortet alle drei mit Ja, und jede Art, wie ein Backup schiefgeht, scheitert an mindestens einer davon.

Fünf Arten, wie ein Backup falsch ist und trotzdem richtig aussieht

Alle fünf laufen in der Nacht ohne Fehler durch, und alle fünf hinterlassen eine Datei mit dem üblichen Namen am üblichen Ort. Auseinander gehen sie erst, wenn die Datei eingespielt wird.

Um die zweite und dritte geht es in warum dein Supabase-Dump keine Nutzer enthält, und beide entstehen durch einen Dump-Befehl mit weniger Flags, als er gebraucht hätte. Die erste hat uns überrascht, deshalb bekommt sie einen eigenen Abschnitt.

Schlägt die Wiederherstellung einer abgeschnittenen Backup-Datei fehl?

Nicht immer. Wir haben eine mitten in einer Tabelle abgeschnitten, mit den Flags eingespielt, die Supabases eigene Anleitung verwendet, und psql lief ohne Fehler durch.

Der Test war klein und leicht nachzumachen. Am 27. September 2026 haben wir eine Datenbank mit zwei Tabellen gedumpt, eine mit 5.000 Zeilen und eine mit 300, die Datei an drei verschiedenen Stellen abgeschnitten und jede Version mit psql aus Postgres 17.11 eingespielt. Jeder Lauf nutzte --single-transaction und --variable ON_ERROR_STOP=1, die beiden Flags, die eine Wiederherstellung beim ersten Problem anhalten und alles rückgängig machen sollen.

• Schnitt mitten in einem Wert: psql brach mit einem Fehler ab und schrieb nichts. Das ist das Ergebnis, auf das du hoffen würdest.
• Schnitt in der letzten Spalte einer Zeile: Der Lauf endete mit Exit-Code 0, so meldet ein Programm Erfolg. Die erste Tabelle kam mit 2.596 ihrer 5.000 Zeilen zurück, der letzten davon fehlte die Hälfte ihres Texts, und die zweite Tabelle kam leer zurück.
• Schnitt genau zwischen den beiden Tabellen: Auch hier Exit-Code 0. Die erste Tabelle war vollständig, die zweite leer.

Der Grund liegt darin, wie ein Dump Zeilen speichert. Die Zeilen jeder Tabelle stehen in einem Block, der mit einer Zeile endet, in der nur \. steht. Endet die Datei vor dieser Zeile, nimmt psql das Dateiende als Ende des Blocks. Das einzige Zeichen, dass noch mehr kommen sollte, ist eine Zeile, die ganz am Ende hätte stehen müssen.

Diese Zeile ist die Abschlussformel von pg_dump. Ein vollständiger Dump enthält kurz vor dem Ende die Worte PostgreSQL database dump complete, und ein abgeschnittener nicht. Von den drei Dateien, die die Supabase CLI schreibt, überlebt die Zeile nur in data.sql, weil die CLI jeden Kommentar aus der Schema-Datei entfernt (geprüft mit Version 2.111 der CLI). Damit ist data.sql die Datei, in der du suchst, und die Suche ist der zweite Schritt der Übung.

Wo soll ich es einspielen?

In ein Supabase-Projekt, an dem nichts hängt: ein Übungsprojekt in deinem Konto oder ein Supabase, das auf deinem eigenen Rechner läuft. Nie in das Projekt, das deine App benutzt.

Ein Übungsprojekt bei Supabase kommt deinem echten Projekt am nächsten, und genau dafür ist Supabases Anleitung zu Backup und Wiederherstellung geschrieben: Ihr erster Schritt ist, ein neues Projekt anzulegen. Im Free-Tarif stehen dir zwei aktive kostenlose Projekte zu, pausierte zählen nicht mit, also kostet ein Übungsprojekt meistens nichts, solange deine Datenbank in den Free-Tarif passt. In einer bezahlten Organisation wird die Rechenleistung eines neuen Projekts stundenweise berechnet, also lösch es, wenn die Übung vorbei ist.

Supabase auf deinem eigenen Rechner kostet nichts und braucht kein Konto. Die Supabase CLI startet den ganzen Stack lokal in Docker: supabase init, dann supabase start, und sie gibt eine Datenbankadresse auf Port 54322 und einen Publishable Key für das lokale Projekt aus. Bevor du es startest, öffne supabase/config.toml und setz major_version auf die Postgres-Hauptversion deines Projekts. Der Kommentar über dieser Einstellung sagt, dass sie übereinstimmen muss, und die Version deines Projekts findest du unter Project Settings, dann General.

Bei Postgres 15 gibt es einen Haken. Hat der Backup-Job keine Version festgelegt, hat die CLI die Kopie mit pg_dump 17 erstellt, und die Datendatei enthält dann weit oben SET transaction_timeout = 0, eine Einstellung, die Postgres 15 nicht kennt, also bricht das Einspielen an dieser Zeile ab. Setz für die Übung major_version auf 17. Gib dem Backup-Job danach die einzeilige Korrektur aus dem Artikel zur GitHub Action, denn das Projekt, in das du im Ernstfall wiederherstellen würdest, läuft weiter auf 15.

Ein nacktes Postgres in Docker, ohne etwas von Supabase darin, reicht nicht. Ein Supabase-Dump verweist auf Dinge, die nur Supabase anlegt, etwa das auth-Schema, in dem deine Nutzer leben, und die Rolle authenticated, die deine Sicherheitsregeln nennen, und die Wiederherstellung bricht an der ersten Zeile ab, die eins davon erwähnt.

Eine Warnung, weil das Übungsprojekt jetzt eine echte Kopie enthält. Darin stehen die E-Mail-Adressen deiner Nutzer, also richte weder deine App noch ihre Webhooks darauf, und lösch es, wenn du fertig bist.

Geplante Jobs sind der Teil, der nicht mitkommt. Führt dein Projekt sie über die Erweiterung pg_cron aus, bringen die drei Dateien der CLI die Erweiterung zurück und keinen ihrer Jobs, denn die Jobs sind Zeilen in cron.job, und der Daten-Dump lässt diese Zeilen weg. Wir haben das am 4. Oktober 2026 mit Version 2.119 der CLI geprüft, indem wir eine Datenbank mit einem geplanten Job wiederhergestellt haben. Das Übungsprojekt bleibt dadurch ruhig, und eine echte Wiederherstellung aus diesen Dateien startet ebenfalls ohne einen einzigen geplanten Job, also bewahr deine cron.schedule-Aufrufe irgendwo auf, wo du sie erneut ausführen kannst.

Wie du ein Supabase-Backup testest, Schritt für Schritt

Sechs Schritte, und die ersten drei passieren, bevor du irgendetwas einspielst.

1. Such die neueste Kopie und lies ihr Datum. Ist sie älter als der letzte geplante Lauf, ist der Job stehen geblieben, und das ist dein erster Befund.
2. Such in data.sql nach dump complete. Ein Treffer heißt, die Datei hat ihr Ende erreicht. Keiner heißt, sie wurde abgeschnitten, egal wie groß sie ist. Die Suche in einem Texteditor funktioniert genauso gut wie ein Terminal:

   grep -c 'dump complete' data.sql
   

3. Such darin nach deinen Nutzern. Eine Zeile, die mit COPY "auth"."users" beginnt und unter der Zeilen stehen, heißt, deine Konten sind in der Datei:

   grep -n 'COPY .*auth.*users' data.sql
   

4. Spiel sie in das Übungsprojekt ein, mit dem Befehl aus Supabases Anleitung und dem Connection String des Übungsprojekts. Bei einem lokalen Supabase lautet er postgresql://postgres:postgres@127.0.0.1:54322/postgres.

   psql \
     --single-transaction \
     --variable ON_ERROR_STOP=1 \
     --file roles.sql \
     --file schema.sql \
     --command 'SET session_replication_role = replica' \
     --file data.sql \
     --dbname "postgresql://…the spare's connection string…"
   

5. Zähl die Zeilen und lies die neueste, in beiden Datenbanken. Die Abfrage steht im nächsten Abschnitt.
6. Melde dich im Übungsprojekt als du selbst an. Der Befehl steht im Abschnitt danach.

Bricht Schritt 4 mit einem Fehler ab, hat die Übung ihre Arbeit früh erledigt. Die Troubleshooting-Hinweise am Ende von Supabases Anleitung behandeln die beiden Fehler, auf die Leute am häufigsten stoßen, beide zu Rollen, und wie du ein Supabase-Backup wiederherstellst erklärt, wovor dich jedes Flag in diesem Befehl schützt.

Zwei weitere Abbrüche in roles.sql fehlen in diesen Hinweisen. Wir sind am 4. Oktober 2026 auf beide gestoßen, als wir die Dateien von zwei Postgres-17-Datenbanken, eine davon ein Supabase-Projekt, in eine frische lokale Kopie von Supabase eingespielt haben: "supabase_admin" is a reserved role, only superusers can modify it auf einer Zeile, die mit ALTER ROLE "supabase_admin" beginnt, und permission denied for parameter log_min_messages auf einer Zeile, die mit GRANT SET ON PARAMETER beginnt. Beide Zeilen richten Rollen ein, die Supabase in jedem Projekt selbst anlegt, also setz -- an den Anfang jeder dieser Zeilen, damit sie zu Kommentaren werden, und führ den Befehl erneut aus. Unsere Backup-Action kommentiert sie schon beim Erstellen der Kopie aus.

Was du zählst, und womit du es vergleichst

Zähl jede Tabelle im Übungsprojekt und in deinem Live-Projekt mit derselben Abfrage und leg die beiden Listen nebeneinander. Die Kopie sollte der Live-Datenbank eine Nacht hinterherhinken: bei einer wachsenden Tabelle etwas niedriger, und bei einer Tabelle, die Zeilen hatte, nie null.

Das ist das Durchzählen anhand der Liste, wer drin war. Füg die Abfrage in den SQL-Editor jedes Projekts ein und drück Run. Sie zählt die Zeilen jeder Tabelle in deinem eigenen Schema und in auth:

select table_schema, table_name,
       (xpath('/row/n/text()',
         query_to_xml(format('select count(*) as n from %I.%I', table_schema, table_name),
                      false, true, '')))[1]::text::bigint as row_count
  from information_schema.tables
 where table_schema in ('public', 'auth')
   and table_type = 'BASE TABLE'
 order by table_schema, table_name;

Sie liest jede Zeile jeder Tabelle, also lass sie bei einer großen Datenbank außerhalb deiner geschäftigsten Stunden laufen.

Dann lies die neueste Zeile einer Tabelle, die du kennst, nur im Übungsprojekt. Jede Tabelle mit einer Spalte created_at geht; setz ihren Namen anstelle von orders ein:

select max(created_at) from public.orders;

Die Antwort sollte nah an dem Zeitpunkt liegen, an dem das Backup lief. Ein Datum, das Wochen älter ist, oder Zeilen, die du nicht wiedererkennst, heißen, dass die Datei aus einem anderen Projekt stammt.

Warum die Anmeldung der Test ist, der deine Konten beweist

Eine Zählung von auth.users beweist, dass die Zeilen angekommen sind. Eine Anmeldung beweist, dass sie funktionieren: dass das gespeicherte Passwort, der Anmeldedienst des Übungsprojekts und deine E-Mail-Adresse noch zusammenpassen.

Nimm dein eigenes Konto, mit einem Passwort, das du kennst. Die Projektadresse und der Publishable Key des Übungsprojekts stehen in dessen Connect-Panel, bei einem lokalen Supabase in der Ausgabe von supabase start:

curl -X POST 'https://…the spare's project ref….supabase.co/auth/v1/token?grant_type=password' \
  -H "apikey: sb_publishable_…" \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com", "password": "…"}'

Das ist der Anmeldeaufruf aus Supabases eigener Dokumentation, auf das Übungsprojekt gerichtet. Eine Antwort mit access_token heißt, dein Konto ist mit einem funktionierenden Passwort angekommen. Invalid login credentials, bei einem Konto, das sich in deiner Live-App ohne Probleme anmeldet, heißt, es ist nicht angekommen, und warum ein Dump ohne die Konten ankommt ist der Artikel für dieses Ergebnis.

Melden sich alle in deiner App mit Google an, hat dieser Aufruf nichts zu testen, weil im Übungsprojekt keine Google-Anmeldung eingerichtet ist. Such stattdessen in der wiederhergestellten auth.users nach deiner eigenen E-Mail-Adresse. Das zeigt, dass die Kontozeile angekommen ist, aber nicht, dass ihr Passwort funktioniert.

Dateien: die Hälfte, die eine Datenbank-Wiederherstellung nicht testen kann

Die Datenbankkopie enthält eine Zeile für jede hochgeladene Datei und keine einzige Datei. Kopierst du deine Storage-Buckets in einem eigenen Job, und nur so werden sie überhaupt kopiert, dann gib dieser Kopie auch eine Übung.

Nimm die drei neuesten Zeilen aus der wiederhergestellten Datenbank:

select bucket_id, name from storage.objects order by created_at desc limit 3;

Such diese drei Pfade in deiner Kopie der Dateien und öffne jede einzelne. Ein Pfad ohne Datei dahinter ist ein Bild, das deine Nutzer nach einer echten Wiederherstellung kaputt sehen würden.

Kann ich die Backups testen, die Supabase für mich macht?

Im bezahlten Tarif ja, mit Restore to a New Project. Nur so lässt sich eine von Supabases eigenen Tageskopien öffnen, denn bei aktuellen Projekten kannst du sie nicht herunterladen.

Supabase beschreibt die Funktion als Weg, gefahrlos zu testen. Wähl im Tab Restore to a New Project auf der Backups-Seite eine Kopie, und Supabase baut daraus ein neues Projekt mit deinen Nutzern und ihren gehashten Passwörtern, bereit für dieselben Zählungen und dieselbe Anmeldung. Zwei Dinge solltest du wissen, bevor du klickst. Das neue Projekt wird als eigenes Projekt abgerechnet, und Supabase zeigt dir die Kosten, bevor es losgeht. Und es kopiert alles, auch geplante Jobs: Supabase schreibt, dass Jobs von pg_cron, pg_net und Wrappers loslaufen, sobald die Wiederherstellung fertig ist, ohne Möglichkeit, sie vorher anzuhalten. Verschickt ein Job in deiner App E-Mails oder belastet eine Karte, tut das Testprojekt das auch.

Bewahrst du zusätzlich eine Datei außerhalb des Kontos auf, braucht diese Datei eine eigene Übung.

Wie oft sollte ich eine Wiederherstellung testen?

Einmal jetzt, dann alle drei Monate und wieder, sobald sich irgendetwas daran ändert, wie das Backup entsteht.

Es zählen die Änderungen, die ein Backup still kaputt machen: ein neuer oder ein geänderter Workflow, ein zurückgesetztes Datenbank-Passwort, ein Wechsel auf einen neuen Tarif oder eine neue Postgres-Version, eine neue Tabelle, in die deine App jetzt schreibt. Nach jeder davon beschreibt die Übung vom letzten Quartal die Datei von diesem Quartal nicht mehr.

Dann schreib es auf, das ist das Blatt an der Tür. Eine Zeile pro Übung, an einem Ort, den du ohne das erreichst, was kaputtgegangen ist: das Datum, welche Datei, die Zählungen, auf die es ankam, ob die Anmeldung geklappt hat und wie lange die ganze Übung gedauert hat. Eine Textdatei im Backup-Repository reicht, genauso ein wiederkehrender Kalendereintrag mit den eingefügten Ergebnissen. Das Datum beantwortet „wann haben wir das zuletzt bewiesen“ in der Stunde, in der es jemand wissen muss, und die Dauer ist deine erste Schätzung, wie lange eine echte Wiederherstellung deine App lahmlegen würde.

Wo Reeve Care passt

Care bewahrt Kopien deiner Supabase-Datenbank außerhalb deines Supabase-Kontos auf, nach dem Zeitplan deines Tarifs, prüft jede Kopie beim Erstellen und spielt sie per Klick zurück.

• Die Kopien laufen nach dem Zeitplan deines Tarifs, von einmal täglich bis alle sechs Stunden.
• Eine abgeschnittene Kopie fällt schon beim Erstellen auf. Die Schlusszeile von pg_dump muss in der Datei stehen, sonst fällt die Kopie durch die Prüfung und wird nie zum Datum in deinem Dashboard.
• Jede Tabelle wird gezählt, während die Kopie geschrieben wird. Hat eine Tabelle, die in der vorigen Kopie Zeilen hatte, in dieser keine mehr, erfährt ein Mensch bei Reeve davon.
• Deine Konten sind in der Kopie, und deine hochgeladenen Dateien kommen mit, sobald du einen Storage-Zugang verbindest.
• Wiederherstellen ist ein Klick, und bevor irgendetwas ersetzt wird, wird eine Kopie des aktuellen Zustands gezogen.
• Jede Kopie lässt sich als Zip herunterladen, mit schema.sql, data.sql, roles.sql und einem Manifest mit der Zeilenzahl jeder Tabelle. Das ist die Hälfte dieses Artikels mit dem „womit vergleichen“, schon aufgeschrieben.

Eine vierteljährliche Übung beweist die Kopie, die du an dem Tag ausgewählt hast, und die Prüfung läuft bei jeder Kopie, während sie entsteht. Kopie, Prüfung und Wiederherstellung sind Schritt für Schritt auf der Seite zu Supabase-Backups gezeichnet, und was jeder Tarif enthält, samt Zeitplan, steht auf der Preisseite.

Was du diese Woche tun solltest

Bevor du diesen Tab schließt, such in deiner neuesten data.sql nach dump complete. Es ist eine einzige Suche, und sie sagt dir, ob die Datei, die du Backup nennst, ihre eigene letzte Zeile erreicht. Hast du noch keine Datei zum Durchsuchen, ist eine kostenlose GitHub Action der schnellste Weg, damit anzufangen.