Supabase Storage Backup: deine Datenbankkopie hat keine Dateien

Du hast Backups für deine Lovable- oder Bolt-App eingerichtet, oder du zahlst für den Supabase-Tarif, der sie zieht, und das Wort hat seine Arbeit getan: Du hast aufgehört, dir Sorgen zu machen. Dann eine Wiederherstellung, oder ein Umzug in ein neues Projekt, und die App kommt mit einem kaputten Bild dort zurück, wo früher jedes Profilfoto war. Jede Tabelle und jede Zeile ist da. Die Bilder sind weg, zusammen mit jeder Rechnung, jedem Export und jedem Anhang, den ein Nutzer je hochgeladen hat.

Hier ist der Teil, den das Wort Backup verdeckt: Ein Supabase Storage Backup ist eine eigene Aufgabe, denn ein Datenbank-Backup enthält eine Zeile für jede Datei, die deine Nutzer hochgeladen haben, und keine der Dateien. Die Zeile liegt in deiner Datenbank. Die Datei liegt in Storage, einem eigenen Dienst, und keine Datenbankkopie auf irgendeinem Tarif greift dort hinein. Dieser Artikel zeigt, wie du diese zweite Kopie ziehst, und in welcher Reihenfolge die beiden Hälften zurückgehen, denn das ist der Teil, der selbst dann schiefgeht, wenn du beide hast.

Es hilft, an eine Bibliothek zu denken. Der Katalog ist ein Zettelkasten, eine Karte für jedes Buch, und jede Karte sagt, in welchem Regal das Buch steht. Die Bücher stehen in den Regalen. Ein Datenbank-Backup kopiert den Zettelkasten.

Sichert Supabase meine Storage-Dateien?

Nein, auf keinem Tarif. Supabases Backup-Dokumentation sagt, dass Backups keine Dateien enthalten, die über die Storage-API abgelegt wurden, nur deren Metadaten in der Datenbank, und Point-in-Time Recovery ist eine Funktion der Datenbank, also deckt derselbe Satz auch das ab.

Was jedes Backup sehr wohl enthält, ist die Liste. Supabase führt in deiner Postgres-Datenbank eine Tabelle namens storage.objects, mit einer Zeile pro Datei in jedem Bucket: in welchem Bucket sie liegt, ihr Pfad, wer sie hochgeladen hat, wie groß sie ist und wann sie angekommen ist. Diese Tabelle wird mit allem anderen kopiert, und genau deshalb sieht ein wiederhergestelltes Projekt so vollständig aus. Jede Karte steckt im Kasten.

Die Bytes jeder Datei liegen woanders. Sie leben im Objektspeicher, einem eigenen Dienst neben deiner Datenbank, und ein Werkzeug, das eine Datenbank kopiert, liest ihn nie. Der Gratis-Tarif zieht überhaupt keine automatischen Backups, dort stellt sich die Frage also gar nicht erst; ab Pro enthält die tägliche Kopie deine Zeilen und keinen deiner Uploads.

Wo Supabase deine Dateien aufbewahrt

An zwei Orten, und ein Datenbank-Backup erreicht einen davon.

Wenn ein Nutzer einen Avatar hochlädt, übergibt deine App die Datei an Storage. Storage schreibt die Bytes unter dem Bucket-Namen und dem Pfad in den Objektspeicher und schreibt im selben Vorgang eine Zeile in storage.objects, die sie beschreibt. Deine App merkt sich diesen Pfad dann in einer ihrer eigenen Tabellen, sagen wir in einer profiles-Zeile mit einer Spalte avatar_url, und baut daraus einen Link, wann immer das Bild gebraucht wird.

Ein hochgeladenes Bild ist also drei Dinge: die Bytes im Objektspeicher, die Zeile in storage.objects, die Storage pflegt, und der Pfad in deiner eigenen Tabelle. Ein Datenbank-Backup trägt die letzten beiden. Stell es wieder her, und deine App hat jeden Pfad und Storage hat jede Zeile, und der Link, den die beiden zusammen bauen, zeigt auf eine Stelle, an der nichts ist.

Deshalb ist der Ausfall auch so leise. Jede Zeile stimmt mit jeder anderen Zeile überein, jede Zählung passt, und jede Prüfung, die die Datenbank liest, besteht, auch der Verifizierungsschritt der meisten Backup-Werkzeuge, weil die Dateien nie in dem waren, was geprüft wurde.

Wie eine Wiederherstellung mit nur der Hälfte aussieht

Ein Projekt, das jede Prüfung besteht und überall dort ein kaputtes Bild zeigt, wo eine Datei erscheinen sollte.

Die Wiederherstellung meldet Erfolg, weil sie getan hat, worum sie gebeten wurde: Die Tabellen sind zurück und die Zeilenzahlen stimmen. Öffne das Dashboard, und Storage listet jeden Bucket und jede Datei darin, mit Größen und Daten, denn diese Liste wird aus der Tabelle gelesen, die die Wiederherstellung zurückgebracht hat. Supabases eigene Anleitung, ein Dashboard-Backup in ein neues Projekt zu spielen, beschreibt genau diesen Zustand: Die Buckets und die Dateimetadaten erscheinen, und die Objekte dahinter nicht.

Wie du es erfährst, ist ganz gewöhnlich. Die Teamseite zeigt eine Reihe kaputter Bildsymbole, wo die Avatare waren. Ein Kunde antwortet auf die Rechnungsmail vom letzten Monat, dass der Link auf einen Fehler führt. Jemand klickt im Storage-Browser auf eine Datei, und der Download schlägt fehl. Die Karte sagt Regal vier, drittes Buch von links, und Regal vier ist leer.

Nichts warnt dich vor diesem Moment, denn jede Warnung, die du hast, hängt an der Datenbank. Wie du ein Supabase-Backup wiederherstellst geht die fünf Arten durch, auf die eine Wiederherstellung kaputt zurückkommt, und die Dateien sind die Zeile in dieser Tabelle, für die es keine Lösung gibt, außer du hast eine Kopie von ihnen gezogen.

Wo du die Storage-Seite gerade offen hast, lohnt es sich zu wissen, was sie einem Fremden zeigt. Unser kostenloser Scan liest deine laufende App von außen und fragt jeden Bucket nach seiner Dateiliste, mit nichts als dem Schlüssel, der ohnehin im Code deiner App steckt. Im August 2026 bekam er von 792 der 27.269 Apps, die er prüfen konnte, eine Liste zurück, eine Zahl aus unserer eigenen Untersuchung. Er liest Namen und lädt nie eine Datei herunter, dauert etwa 20 Sekunden und braucht kein Konto: Scanne deine App.

Wie sichere ich einen Supabase-Storage-Bucket?

Über den S3-kompatiblen Endpunkt, mit einem einzigen Befehl, der einen ganzen Bucket in einen Ordner kopiert, den du hältst.

Supabase Storage spricht das S3-Protokoll, und das heißt, die gewöhnlichen Werkzeuge, die für Amazons Speicher gebaut wurden, funktionieren gegen deinen. Das ist der eine Schritt in diesem Artikel, der auf einer Kommandozeile stattfindet, und es lohnt sich, ihn einmal von Hand zu machen, damit du weißt, woraus die Kopie besteht.

1. Öffne in deinem Supabase-Dashboard die Storage-Einstellungen und schalte das S3-Protokoll ein. Dieselbe Seite zeigt die Endpunkt-URL und die Region deines Projekts; kopiere beides von dort und nicht von hier.
2. Erzeuge auf dieser Seite ein S3-Zugangsschlüsselpaar. Das Secret wird nur einmal angezeigt, also lege es in einen Passwortmanager, bevor du den Dialog schließt.
3. Installiere die AWS-Kommandozeile, gib ihr die beiden Schlüssel als Profil und führe pro Bucket einen Sync aus:

aws s3 sync s3://avatars ./supabase-files/avatars \
  --endpoint-url https://<project-ref>.storage.supabase.co/storage/v1/s3 \
  --region <region>

Führst du ihn morgen wieder aus, kopiert er nur, was sich geändert hat. rclone erledigt dieselbe Arbeit, wenn du es lieber magst; bei einem großen Bucket rät Supabases Hinweis zur Fehlersuche, --s3-list-version 2 mitzugeben, sonst kann die Auflistung vorzeitig abbrechen.

Zwei Dinge zu diesem Schlüssel. Supabases Seite zur S3-Authentifizierung sagt, ein S3-Zugangsschlüssel hat vollen Zugriff auf jeden Bucket und umgeht Row Level Security, also gehört er auf einen Server oder auf deinen eigenen Rechner und nie in deine App. Und er kann schreiben und nicht nur lesen, denn Supabase gibt keinen reinen Leseschlüssel für Storage aus; wer ihn hält, kann Dateien ebenso leicht löschen wie kopieren. Behandle ihn so, wie du deinen service_role-Schlüssel behandeln würdest.

Dann leg den Ordner irgendwo außerhalb deines Supabase-Kontos ab, aus demselben Grund, aus dem eine Datenbankkopie außerhalb liegen sollte: Ein gesperrtes Projekt oder ein verlorenes Login reißt jede Kopie mit, die in diesem Konto gespeichert ist.

Zuerst die Dateien, oder zuerst die Zeilen?

Zuerst die Datenbank, dann die Dateien, und die Dateien gehen durch Storage zurück, damit Storage die Zeilen schreibt.

Jeder Upload, der durch Storage läuft, aus deiner App, über den S3-Endpunkt oder über die Supabase-CLI, tut zwei Dinge in einem Vorgang: Er speichert die Bytes und er schreibt die Zeile in storage.objects, die sie beschreibt. Das Buch wird ins Regal gestellt und die Karte von derselben Hand geschrieben. Spiel die Dateien auf diesem Weg zurück, und die Zeilen kommen mit ihnen, und die beiden können nicht auseinanderlaufen.

Die andere Richtung hat keinen solchen Mechanismus. Zeilen aus storage.objects mit einem Datenbankwerkzeug zurückzukopieren schreibt Karten und stellt nichts ins Regal. Es macht auch den nächsten Schritt sperrig: Standardmäßig verweigert Storage einen Upload auf einen Pfad, der schon eine Zeile hat, mit einem Fehler, dass die Ressource bereits existiert, und Supabases Upload-Anleitung sagt, dass du daran vorbeikommst, indem du Überschreiben einschaltest. Wenn die Datenbankwiederherstellung die Zeilen also schon zurückgebracht hat, und genau das lässt Supabases eigene Migrationsanleitung dich tun, muss die Dateikopie danach überschreiben dürfen.

Die Reihenfolge also:

1. Stell die Datenbank wieder her, wie dieser Artikel es beschreibt.
2. Kopiere die Dateien durch Storage zurück, mit aws s3 sync in umgekehrter Richtung (zuerst der Ordner, dann der Bucket) oder mit supabase storage cp -r, und mit eingeschaltetem Überschreiben. Ein Bucket, den es nicht mehr gibt, muss vorher angelegt werden, mit demselben Namen und derselben Public-Einstellung.
3. Öffne eine Datei, und dann noch einige mehr.

Die sauberste Fassung davon lässt das Zurückspielen von storage.objects im Datenbankschritt ganz weg und lässt die Uploads jede Zeile frisch schreiben, sodass nie etwas überschrieben werden muss. So macht es unsere eigene Wiederherstellung. Dafür muss die Kopie gefiltert werden, bevor sie eingespielt wird, und das ist ein Schritt für das Werkzeug, das die Wiederherstellung ausführt.

Wie du prüfst, dass du beides hast

Indem du Dateien öffnest, denn jede Liste, die du abrufen kannst, wird aus der Tabelle gelesen.

Der Dateibrowser des Dashboards, eine Abfrage gegen storage.objects und die Zeilenzahl in einem Backup-Bericht beschreiben alle den Zettelkasten, und nach einer reinen Datenbankwiederherstellung ist der Zettelkasten perfekt. Die einzige Anfrage, die das Regal berührt, ist eine Anfrage nach der Datei selbst.

Also öffne nach einer Wiederherstellung, und nach der ersten Kopie, die du ziehst, Dateien. Nimm eine Handvoll aus jedem Bucket, die ältesten eingeschlossen, und öffne sie durch die App, so wie ein Nutzer es täte. Eine Datei, die sich öffnet, ist zurückgekommen. Eine Datei, die einen Fehler liefert, war nie da, was auch immer die Liste sagt.

Was du diese Woche tun solltest

Wo Reeve Care hineinpasst

Care kopiert die Dateien zusammen mit der Datenbank, in der Reihenfolge, die dieser Artikel beschreibt, und spielt sie auf demselben Weg zurück.

• Die Dateien, die deine Nutzer hochgeladen haben, werden ebenfalls kopiert, sobald du die Storage-Buckets deiner Supabase-App verbindest. Das ist ein zweiter Schlüssel, getrennt erfragt, denn der Schlüssel, den Supabase für Storage ausgibt, kann schreiben und nicht nur lesen, und wir fragen lieber nach, statt ihn mit dem Datenbankschlüssel zu bündeln, der das nicht kann.
• Die Dateikopie läuft, nachdem die Datenbankkopie zurückgelesen und geprüft wurde, nie daneben, sodass ein Wiederherstellungspunkt nie Dateien beansprucht, die er nicht kopiert hat. Eine Kopie, der die Zeit ausging, wird als unvollständig gekennzeichnet, mit den echten Zahlen.
• Jeder Wiederherstellungspunkt hält fest, welcher Pfad welche Datei hielt. Eine auf Dienstag zurückgesetzte Datenbank bekommt die Dateien von Dienstag, und eine Datei, die noch an ihrem Platz ist, wird in Ruhe gelassen.
• Die Wiederherstellung spielt die Dateien durch Storage zurück, sodass jede Zeile von dem Upload geschrieben wird, der die Datei trägt. Nichts, was heute existiert, wird überschrieben oder gelöscht, und das heißt, die Schaltfläche in Panik zu drücken kann nicht das zerstören, was du retten wolltest.
• Die Wiederherstellung ist eine Schaltfläche, und sie zieht vorher einen Abzug des aktuellen Stands, damit auch sie ein Rückgängig hat.

Care beginnt bei €49 im Monat für eine App. Das ist ein Listenpreis, und die Preisseite liegt manchmal unter der Zahl hier und nie darüber.

Wie eine Kopie gezogen, geprüft und zurückgespielt wird, Dateien eingeschlossen, ist Schritt für Schritt auf der Seite zu Supabase-Backups aufgezeichnet.

Bevor du diesen Tab schließt, öffne Storage in deinem Dashboard und zähl die Buckets. Jeder davon ist ein Satz Dateien, den kein Backup, das Supabase zieht, je enthalten wird, und der Sync-Befehl oben ist alles, was es braucht, um das zu ändern. Falls sich ein Bucket zudem als auflistbar herausgestellt hat, ist was ein Fremder aus dieser Liste bekommt das Nächste, was du lesen solltest.