Warum du dein Supabase-Backup nicht herunterladen kannst

Du bist auf einem bezahlten Supabase-Tarif, also hast du Backups. Du öffnest Database, dann Backups, und da sind sie: eine Liste datierter Tageskopien, jede mit einem Restore-Button. Du suchst den Button, mit dem du dein Supabase-Backup herunterladen und irgendwo bei dir ablegen kannst, und es gibt keinen.

Kaputt ist nichts. Hier ist der Teil, den ältere Anleitungen immer noch falsch darstellen: Auf einem aktuellen Projekt gibt es kein Tages-Backup zum Herunterladen. Supabase hat seine täglichen Kopien auf eine andere Art von Backup umgestellt, eine, die Supabase für dich wiederherstellen und nicht herausgeben kann. Der Download-Button aus diesen Anleitungen gehörte zur älteren Art. Eine Datei, die du selbst hältst, machst du heute selbst, und es ist eine andere Art von Datei.

Am einfachsten stellst du dir den Unterschied mit deinem Handy vor. Das Backup, das es jede Nacht von sich selbst macht, ist vollständig und exakt, und es kommt in einem Schritt zurück auf ein Handy, das im selben Konto angemeldet ist. Du kannst es nicht auf einem Laptop öffnen und deine Fotos herausholen. Für Fotos, die du überall behalten kannst, exportierst du sie, und was du bekommst, ist ein Ordner mit ganz gewöhnlichen Dateien. Das tägliche Supabase-Backup ist jetzt die erste Art. Die Datei, die du halten kannst, ist die zweite.

Kann ich mein Supabase-Backup herunterladen?

Das tägliche nicht, wenn dein Projekt auf Postgres 15.8.1.079 oder neuer läuft. Die Backup-Dokumentation von Supabase sagt, dass alle Projekte ab dieser Version physische Backups nutzen, und die Troubleshooting-Hinweise sagen, dass Supabase mit physischen Backups die herunterladbare Backup-Datei nicht mehr erzeugt. Wiederherstellen kannst du diese Kopien, wann immer du willst. Mitnehmen kannst du keine.

Die letzte Zeile solltest du zweimal lesen. Supabase schreibt, dass beim Löschen eines Projekts alle zugehörigen Daten entfernt werden, einschließlich aller in S3 gespeicherten Backups. Wer das Projekt löscht, löscht die Tageskopien im selben Schritt mit.

Was ist der Unterschied zwischen einem physischen und einem logischen Backup?

Woher die Kopie genommen wird. Ein physisches Backup kopiert die Dateien, die Postgres selbst auf die Platte schreibt, was Supabase als Snapshot des zugrunde liegenden Datenbankverzeichnisses beschreibt. Ein logisches Backup bittet die Datenbank, sich selbst in SQL zu beschreiben, Tabelle für Tabelle und Zeile für Zeile, und schreibt diese Beschreibung in eine Textdatei.

Jede kann etwas anderes gut. Eine physische Kopie ist schnell gemacht und schnell zurückgespielt, und sie kommt genau so zurück, wie sie war. Lesen kann sie nur dieselbe Art von Postgres-Installation, aus der sie stammt, und bei Supabase heißt das: Supabases eigene Maschinen. Eine logische Kopie spielt sich langsamer ein und braucht mehr Platz, und jedes Postgres derselben oder einer neueren Version kann sie laden. Es ist wieder das Handy-Backup und der exportierte Ordner, und nur das zweite ist eine Datei, die du halten kannst.

Der Download-Button, an den sich viele erinnern, war die logische Art. Die eigene Dokumentation von Supabase aus dem Jahr 2025 beschrieb, dass der tägliche Job pg_dumpall ausführte, die SQL-Datei zippte und ablegte, und dass physische Backups die Datenbank weniger belasten und deine Tabellen nicht lange sperren. Auf derselben Seite stand, dass physische Kopien sich nicht im Backups-Bereich des Dashboards herunterladen lassen.

Wie finde ich heraus, welche Art mein Projekt hat?

Such auf der Backups-Seite nach einer Download-Möglichkeit. Öffne in deinem Supabase-Dashboard Database, dann Backups. Hat jede datierte Kopie eine Möglichkeit zum Herunterladen, läuft dein Projekt noch mit logischen Backups. Bietet jede nur Restore und sonst nichts, sind es physische Backups, und die ältere Dokumentation von Supabase nutzte genau diesen Test.

Die zweite Prüfung ist die Versionsnummer. Sie steht unter Project Settings, dann General. Alles ab 15.8.1.079 bedeutet physische Backups. Lies sie von links nach rechts: Eine Version, die mit 17 beginnt, ist neuer als jede 15, und 15.8.1.100 ist neuer als 15.8.1.079.

Zwei Fälle musst du gar nicht prüfen:

• Point-in-Time-Recovery ist an. Das läuft per Definition auf physischen Backups. Supabase schreibt außerdem, dass es nach dem Abschalten von Point-in-Time-Recovery weiter physische Backups nimmt, der Download kommt also nicht zurück.
• Du bist auf dem Gratis-Tarif. Auf der Backups-Seite gibt es nichts zum Herunterladen oder Wiederherstellen, weil dir der Gratis-Tarif keine nutzbaren Tages-Backups gibt. Eine Kopie ohne Terminal machen ist der Anfang.

Wovor schützt mich welche Kopie?

Das Tages-Backup schützt dich davor, dass innerhalb des Projekts etwas schiefgeht. Eine Datei, die du selbst hältst, deckt auch den Verlust des Projekts selbst ab.

Die erste Art von Verlust verursachst du selbst. Ein Löschbefehl, der mehr Zeilen erwischt hat als gedacht, eine Migration, die ein KI-Agent geschrieben und du abgenickt hast, ein Skript, das auf die falsche Tabelle zeigte. Dafür ist die Tageskopie genau das richtige Werkzeug: gestern auswählen, Restore drücken, und das Projekt ist wiederhergestellt. Wie weit sie zurückreicht, hängt von deinem Tarif ab, und auf welchem Tarif du bist, klärst du in etwa zwei Minuten.

Die zweite Art hat mit einem Fehler in der Datenbank gar nichts zu tun. Eine Karte, die abgelaufen ist, während du weg warst, ein Login, das du nicht wiederherstellen kannst, ein Projekt, das jemand gelöscht hat. Die Kopien liegen hinter derselben Tür wie das Projekt, und die Tür ist das, was zugefallen ist. Dein Handy-Backup verhält sich genauso: Es rettet dich, wenn das Handy ins Meer fällt, und es hilft dir nicht an dem Tag, an dem du dich nicht mehr in das Konto einloggen kannst, in dem es liegt. Supabase bewahrt seine Backups bei der Plattform auf, weil eine Wiederherstellung genau deshalb nur einen Klick braucht. Eine Kopie, die das Konto übersteht, muss woanders liegen, und bei Supabase heißt das: ein logischer Dump, der aus dem Konto herausgeholt wurde.

Was bedeutet Wiederherstellen bei welcher Kopie?

Bei der Tageskopie macht Supabase die Arbeit, und du wählst, wo sie landet. Bei einer Datei, die du hältst, machst du die Arbeit, und sie kann überall landen.

Die Tageskopie ins selbe Projekt wiederherstellen ersetzt die Datenbank durch die Kopie, die du auswählst. Supabase schreibt, dass das Projekt währenddessen nicht erreichbar ist und eine größere Datenbank länger braucht.

Sie in ein neues Projekt wiederherstellen ist eine kostenpflichtige Funktion, die Supabase Restore to a New Project nennt und noch als Beta kennzeichnet. Sie legt ein eigenes Projekt in derselben Region an, mit deinen Nutzern und ihren gehashten Passwörtern, und es wird als zweites Projekt abgerechnet. Ein Hinweis auf derselben Seite geht leicht unter. Sie kopiert die gesamte Datenbank, einschließlich Erweiterungen, die nach außen wirken, etwa pg_cron und pg_net, und diese Jobs laufen los, sobald die Wiederherstellung fertig ist. Wenn ein geplanter Job in deiner App E-Mails verschickt oder eine Zahlungs-API aufruft, tut das neue Projekt das ab dem Moment, in dem es existiert, ebenfalls.

Eine Datei wiederherstellen, die du hältst, heißt, sie mit psql in das einzuspielen, worauf du zeigst: ein neues Supabase-Projekt, eines in einem anderen Konto oder ein Postgres auf deinem eigenen Rechner. Wie du ein Supabase-Backup wiederherstellst geht die Befehle durch und auch das, was danach noch kaputt ist.

Wie bekomme ich eine Kopie meiner Supabase-Datenbank als Datei?

Zieh selbst einen logischen Dump. Supabase veröffentlicht ihn in seiner Anleitung zu Backup und Restore als drei Befehle, von denen jeder eine Datei schreibt:

supabase db dump --db-url "postgresql://…" -f roles.sql --role-only
supabase db dump --db-url "postgresql://…" -f schema.sql
supabase db dump --db-url "postgresql://…" -f data.sql --use-copy --data-only

Den Connection String bekommst du über den Connect-Button oben in deinem Projekt, mit deinem Datenbankpasswort anstelle des Platzhalters. Die Supabase CLI braucht ein installiertes Docker, weil sie pg_dump in einem Container ausführt, statt eines von deinem Rechner zu nehmen.

Behalte alle drei Dateien. Die zweite allein ist die Form deiner Tabellen ohne eine einzige Zeile darin, und deine Nutzer stecken nur in der dritten.

Du kannst pg_dump auch direkt ausführen. Zwei Dinge solltest du vorher wissen. Supabase schreibt, dass ein rohes pg_dump die internen Schemas von Supabase mit deinen zusammen mitnimmt und dass das Einspielen dieser Schemas Berechtigungsfehler auslöst. Und Postgres dokumentiert, dass pg_dump nicht von einem Server dumpt, der eine neuere Hauptversion hat als es selbst. Eine ältere Kopie auf deinem Rechner weigert sich also zu starten, statt eine fehlerhafte Datei zu schreiben.

Leg die Dateien irgendwo ab, das nicht dein Supabase-Konto ist, und nicht nur auf deinen Laptop.

Kann ich ein Supabase-Backup auf meinem eigenen Rechner wiederherstellen?

Ein logisches schon, in ein Postgres derselben Hauptversion oder einer neueren. Die physische Tageskopie lässt sich nirgends außer bei Supabase wiederherstellen.

Die Versionsregel kommt von Postgres selbst. Seine Dokumentation sagt, dass sich ein Dump in neuere Versionen laden lassen sollte und in eine ältere nicht garantiert, nicht einmal in die, aus der er stammt. Die Anleitung von Supabase zum Umzug eines Plattform-Projekts auf selbst gehostetes Supabase zeigt, wie das aussieht. Die Plattform kann Postgres 17 fahren, während das selbst gehostete Image standardmäßig auf 15 läuft, und die Datendatei enthält dann eine Zeile, SET transaction_timeout = 0, die Postgres 15 nicht kennt.

Dieselben drei Dateien sind auch der Weg ganz weg von Supabase. Diese Anleitung beschreibt, wie du Supabase auf einem eigenen Server betreibst, und der Versionskonflikt ist das Erste, wovor sie warnt.

Auf deinem eigenen Rechner startet die Supabase CLI mit supabase start eine lokale Kopie von Supabase in Docker. Spiel die drei Dateien mit dem psql-Befehl aus der Anleitung zu Backup und Restore von Supabase ein, gerichtet auf postgresql://postgres:postgres@localhost:54322/postgres, und deine Daten sind auf deinem eigenen Rechner lesbar, ganz ohne Konto.

Es gibt eine Stelle, an der Supabase noch ein Backup zum Herunterladen anbietet. Ein Gratis-Projekt, das über sein Wiederherstellungsfenster hinaus pausiert ist, ersetzt den Restore-Button durch einen Download der letzten Kopie vor der Pause, und was du mit dieser Datei machst, ist ein eigener Artikel.

Was ist in keiner der beiden Kopien?

Deine hochgeladenen Dateien, deine Edge Functions und die meisten Einstellungen deines Projekts.

Supabase schreibt, dass Datenbank-Backups keine über die Storage API gespeicherten Objekte enthalten. Die Datenbank hält eine Zeile, die jede Datei beschreibt, und die Datei selbst liegt woanders, also enthält kein Datenbank-Backup auf irgendeinem Tarif die Uploads deiner Nutzer. Storage sichern ist eine eigene Aufgabe.

Die Liste, die Supabase für Restore to a New Project angibt, ist eine gute Bestandsaufnahme des Rests: Edge Functions, Auth-Einstellungen und API-Schlüssel, Realtime-Einstellungen, Erweiterungseinstellungen und Read Replicas müssen alle von Hand neu eingerichtet werden.

Eine Lücke betrifft nur die Datei, die du hältst. Wenn deine App Geheimnisse in Supabase Vault ablegt oder verschlüsselte Spalten nutzt, schreibt Supabase, dass Backup-Dateien nie den Root Key enthalten, nur die verschlüsselten Daten. Ein neues Projekt startet mit einem eigenen Schlüssel, also kommen diese Werte unlesbar an, bis der alte Schlüssel hinüberkopiert ist. Und der alte Schlüssel lässt sich nur abrufen, solange das alte Projekt noch aktiv ist. Ist dieses Projekt pausiert oder gelöscht, lässt sich der Schlüssel nicht mehr abrufen, und alles, was damit verschlüsselt wurde, auch nicht.

Was du diese Woche tun solltest

Wo Reeve Care passt

Care zieht die logische Kopie für dich, bewahrt sie außerhalb von Supabase auf, und jede Kopie ist eine Datei, die du herunterladen kannst.

• Lade jede Kopie als Zip herunter. Darin stecken schema.sql, data.sql und roles.sql, ein Manifest, das die Zeilen jeder Tabelle zählt, und eine Notiz, wie du alles in ein beliebiges Postgres lädst. Es ist ein Standard-Dump, also kann ihn jede Entwicklerin und jeder Entwickler öffnen, und jeder andere Hoster auch.
• Außerhalb deines Supabase-Kontos gespeichert, verschlüsselt, also noch da an einem Tag, an dem das Konto es nicht mehr ist.
• Zurückgelesen, bevor sie zählt. Das Datum in deinem Dashboard ist die letzte Kopie, die geöffnet und geprüft wurde, nie die letzte, die versucht wurde.
• Deine Nutzer sind drin. Das auth-Schema reist mit deinen Tabellen, und die Dateien, die deine Nutzer hochgeladen haben, kommen mit, sobald du einen Storage-Zugang verbindest.

Care bewahrt eine Kopie deiner Supabase-Datenbank auf. Lass die täglichen Supabase-Backups daneben eingeschaltet: Sie sind der schnellste Weg zurück nach einer schiefgegangenen Migration, und die Datei ist das, was bleibt, wenn du das Konto verlierst. Wie eine Kopie gezogen, geprüft und heruntergeladen wird, ist Schritt für Schritt auf der Seite zu Supabase-Backups gezeichnet, und was jeder Tarif enthält, steht auf der Preisseite.

Bevor du diesen Tab schließt, öffne Database, dann Backups, und schau neben deine neueste Kopie. Gibt es dort nichts zum Herunterladen, ist die nächste Datei, die du hältst, die, die du selbst machst, und was einen Dump vollständig macht, liest du am besten, bevor du ihn machst.