Reeve Backups
Drei Wege, eine Supabase-Datenbank zu sichern, und was fehlt
Das Dashboard, pg_dump und ein verwalteter Dienst. Was jeder Weg wirklich sichert, was er stillschweigend auslässt und welcher den Kontoverlust übersteht.
Kurz gesagt
- Die Backups von Supabase sind am einfachsten einzuschalten und am schlechtesten zu vertrauen: Die Kopie liegt in genau dem Konto, das du verlieren kannst.
- pg_dump ist kostenlos und vollständig, und es passiert nur, wenn du daran denkst. Das Daran-Denken ist der Teil, der versagt.
- Keiner der drei Wege sichert deine Storage-Dateien. Das bleibt eine eigene Aufgabe, welchen Weg du auch nimmst.
Wer auf Supabase baut, stellt irgendwann dieselbe Frage, meist etwa eine Woche nach dem Start und meist um zwei Uhr nachts: Wenn ich etwas kaputt mache, bekomme ich meine Daten zurück?
Die Antwort hängt vollständig davon ab, welchen der drei Wege du genommen hast, und jedem von ihnen fehlt etwas, das die beiden anderen abdecken.
Welchen sollte ich nehmen?
Schalte ein, was dein Supabase-Tarif dir gibt, und halte dann eine Kopie woanders. Das sind zwei verschiedene Aufgaben, und nur die erste zu erledigen ist genau der Fehler, den dieser Artikel verhindern soll.
Das Dashboard-Backup schützt dich vor deinen eigenen Fehlern. Eine Kopie, die du selbst hältst, schützt dich davor, das Konto zu verlieren: eine fehlgeschlagene Zahlung, ein gesperrtes Projekt, ein Passwort, das du nicht wiederherstellen kannst. Das sind verschiedene Katastrophen, und sie brauchen verschiedene Antworten.
| Supabase-Dashboard | pg_dump von Hand | Verwaltete Backups | |
|---|---|---|---|
| Läuft ohne dich | Ja | Nein | Ja |
| Du hältst die Kopie | Nein | Ja | Ja |
| Übersteht den Kontoverlust | Nein | Ja | Ja |
| Vor dem Zählen geprüft | Nein | Nein | Ja |
| Kosten | Nur in bezahlten Tarifen | Kostenlos | Ein Abo |
Was in einem Backup wirklich drinsteht
Deine Tabellen, deine Zeilen, deine Indizes und Funktionen und deine Row-Level- Security-Regeln, also die Richtlinien, die entscheiden, wer was lesen darf, nicht bloß die Tabellen, für die sie gelten. Mehr ist es nicht.
Was nicht darin steht, ist alles, was nie in der Datenbank war:
| In der Datei | Nicht in der Datei |
|---|---|
| Der Tabellenaufbau mit jeder Spalte und Bedingung | Dateien in Storage: Uploads, Avatare, Anhänge |
| Jede Zeile, die deine Nutzer angelegt haben | Auth-Einstellungen, etwa deine Google- oder GitHub-App |
| Indizes und Funktionen | Edge Functions, die in deinem Repository liegen |
| Row-Level-Security-Richtlinien |
Woran die meisten scheitern, ist Storage. Jeder Avatar, jedes hochgeladene PDF, jedes Bild, das deine Nutzer hinzugefügt haben, liegt im Objektspeicher, nicht in der Datenbank. Die Datenbank hält nur den Pfad zu jeder Datei. Spiel ein Datenbank-Backup in ein leeres Projekt ein, und du bekommst eine Tabelle voller Links auf Dateien, die nicht da sind.
Weg 1: das Supabase-Dashboard
Der einfachste, und der, den die meisten zuerst einschalten sollten. Supabase macht in bezahlten Tarifen tägliche Backups, und Point-in-Time Recovery gibt es als Zusatz, wenn du auf eine bestimmte Minute zurückspulen musst statt auf Mitternacht.
Was er gut kann: Er läuft ohne dich, er ist vollständig, und Wiederherstellen sind ein paar Klicks in einer Oberfläche statt eines Befehls, den du unter Druck richtig hinbekommen musst.
Was ihm fehlt: Die Kopie liegt im Konto. Ist das Projekt gesperrt, scheitert die hinterlegte Karte, oder verlierst du den Zugang zum Login, dann liegen die Backups hinter derselben Tür wie das, was sie schützen sollten. Es ist ein Notausgang innerhalb des Gebäudes.
Außerdem gibt es ihn im kostenlosen Tarif gar nicht, und dort sitzen die meisten frisch gestarteten Apps.
Welcher Tarif es ist, entscheidet, ob du das überhaupt hast, und die Prüfung dauert zwei Minuten.
Weg 2: pg_dump auf deinem eigenen Rechner
Supabase ist Postgres, also funktioniert das Standardwerkzeug von Postgres.
pg_dump schreibt die ganze Datenbank in eine Datei, die du hältst.
pg_dump "postgresql://…deine Verbindungszeichenfolge…" \
--clean --if-exists --no-owner \
--file backup-2026-08-09.sql
Was er gut kann: Er ist kostenlos, er ist vollständig, die Datei gehört dir, und du kannst sie in ein brandneues Projekt auf einem anderen Konto einspielen. Von den drei Wegen ist das der einzige, der den Verlust von allem anderen übersteht.
Was ihm fehlt: Er passiert nur, wenn du daran denkst. Das ist keine Kleinigkeit, das ist das ganze Versagen. Der Dump auf deinem Laptop trägt das Datum, an dem du zuletzt daran gedacht hast, und der Tag, an dem du ihn brauchst, ist nie ein Tag, an dem du daran gedacht hast.
Es gibt ein zweites, leiseres Problem: Ein ungetesteter Dump ist eine Vermutung. Eine Datei, die geschrieben wurde, während eine Migration halb angewendet war, oder die still abgeschnitten wurde, weil die Verbindung abbrach, sieht genau wie eine gute aus, bis zu dem Tag, an dem du sie benutzen willst.
Weg 3: verwaltete Backups
Etwas anderes nimmt die Kopie nach Zeitplan auf, legt sie außerhalb deines Kontos ab und prüft, ob die Kopie echt ist, bevor sie als erledigt gilt. Genau darauf kommt es wirklich an.
Genau das macht Reeve Care: mehrere Kopien am Tag je nach Tarif, verschlüsselt und außerhalb deines Supabase-Kontos aufbewahrt, jede einzelne geprüft, indem gezählt wird, was herauskam, gegen das, was hineinging. Ein Backup zählt erst als gemacht, wenn es geprüft wurde. Deshalb ist das im Dashboard gezeigte Datum das der letzten geprüften Kopie und nicht das des letzten Versuchs.
Der ehrliche Kompromiss: Es kostet Geld, und es ist ein weiterer Dienst in deinem Stack. Wenn du diszipliniert genug bist, Weg 2 nach einem echten Zeitplan zu fahren und die Wiederherstellungen zu testen, brauchst du ihn nicht.
Der ganze Ablauf ist auf der Seite zu Supabase-Backups dargestellt: die Kopie, die Supabase verlässt, die Prüfung danach und der Knopf, der sie zurückholt.
Hast du jemals eine Wiederherstellung gemacht?
Diese Frage entscheidet, ob du ein Backup hast oder eine Datei, die nie geöffnet wurde. Ein Dump, den niemand zurückgelesen hat, ist eine Vermutung über die Zukunft, und der Moment, in dem du merkst, dass sie falsch war, ist der Moment, in dem sie hätte stimmen müssen.
Ein Wiederherstellungstest muss nicht dramatisch sein. Leg ein neues Supabase-Projekt an, spiel dein neuestes Backup hinein, öffne die App gegen dieses Projekt und schau nach, ob eine Zeile da ist, die du wiedererkennst. Eine halbe Stunde, einmal im Quartal. Scheitert die Wiederherstellung, hast du es an einem Dienstagnachmittag herausgefunden statt mitten in einem Ausfall.
Wenn du die breitere Liste dessen willst, was bei einer frisch gestarteten App zu prüfen ist: Die 10-Minuten-Sicherheitscheckliste deckt Backups neben dem Rest ab, und der Supabase-Sicherheitsleitfaden geht durch, was sonst häufig offen bleibt.
Was diese Woche zu tun ist
Was zu tun ist
- Schalte das Backup ein, das dein Supabase-Tarif enthält. Es ist das Billigste auf dieser Liste und dauert etwa eine Minute.
- Mach heute einen
pg_dumpund leg die Datei irgendwohin, das nicht dein Laptop ist. Auch eine veraltete Kopie schlägt gar keine Kopie. - Sichere deine Storage-Dateien getrennt. Kein Datenbank-Backup auf einem dieser Wege enthält sie.
- Mach eine Wiederherstellung in ein Wegwerf-Projekt, damit das nächste Lesen dieser Datei nicht das erste ist.
- Entscheide, wie viele Daten du verkraften könntest zu verlieren, und wähle den Zeitplan nach dieser Zahl statt danach, was verantwortungsvoll wirkt.
Lesenswert als Nächstes: Falls du angenommen hast, das Rückgängig deines Builders decke auch deine Daten ab, lies zuerst der Versionsverlauf ist kein Backup. Danach: Deine Datenbank ist nur so privat wie die Schlüssel davor, und welche API-Schlüssel im Frontend sicher sind behandelt den einen, der jede Regel umgeht, die du setzt.
FAQ
Sind im kostenlosen Supabase-Tarif Backups enthalten?
Nein. Tägliche Backups beginnen im Pro-Tarif, und Point-in-Time Recovery ist ein Zusatz darüber. Im kostenlosen Tarif gibt es nirgendwo eine automatische Kopie deiner Daten, was die meisten Leute überrascht, wenn sie sie zum ersten Mal brauchen.
Ist ein Backup dasselbe wie die Versionshistorie in meinem Builder?
Nein, und das ist das teuerste Missverständnis in diesem Artikel. Lovable, Bolt und die anderen versionieren deinen CODE. Deine Datenbank ist ein eigener Dienst mit deinen Nutzern, ihren Inhalten und ihren Bestellungen. Den Code auf gestern zurückzusetzen setzt deine Daten nicht zurück, und eine im Supabase-Editor gelöschte Tabelle lässt deinen Code völlig unberührt.
Wie oft sollte ich sichern?
Frag stattdessen, wie viel du bereit bist, neu einzutippen. Wenn ein verlorener Tag an Anmeldungen ärgerlich wäre, reicht nachts. Wenn eine verlorene Stunde an Bestellungen Rückerstattungen bedeuten würde, brauchst du etwas näher an stündlich. Der ehrliche Test ist nicht der Zeitplan, sondern ob du jemals eine Wiederherstellung gemacht hast.
Muss ich sichern, wenn meine App fast keine Nutzer hat?
Das ist der günstigste Zeitpunkt anzufangen, weil die Daten klein sind und es auf die Gewohnheit ankommt. Die schmerzhaften Verluste sind selten dramatisch. Es ist ein vertipptes Löschen bei einer nächtlichen Reparatur, in einem Projekt mit gerade genug echten Nutzern, dass Neuanfangen keine Option ist.