Supabase-Backup: Datenbank, Storage und Konfiguration sichern

Benötigen Sie einen belastbaren Supabase-Betrieb mit getrennten Datenbank- und Storage-Backups? WZ-IT übernimmt Supabase Managed Hosting und Betrieb einschließlich Monitoring, Backup-Konzept und kontrollierten Updates.

Ein Supabase-Backup muss mehrere Datenebenen gemeinsam wiederherstellbar machen. PostgreSQL enthält Tabellen, Auth-Daten und Metadaten. Die eigentlichen Storage-Dateien liegen jedoch außerhalb des Datenbank-Backups. Functions, Secrets, SMTP und Infrastrukturkonfiguration benötigen ebenfalls eigene Verfahren.

Die wichtigste Frage lautet deshalb nicht „Läuft der Dump?“, sondern: Kann die vollständige Anwendung innerhalb der vereinbarten Zeit auf einen konsistenten Stand zurückkehren?

Welche Supabase-Komponenten müssen gesichert werden?

Ein vollständiges Backup muss nicht alle Geheimnisse im Klartext enthalten. Es muss aber dokumentieren, wie sie im Wiederanlauf sicher wiederhergestellt oder rotiert werden.

Zuerst RPO und RTO bestimmen

Recovery Point Objective (RPO) beantwortet, wie viele Daten im Störungsfall maximal verloren gehen dürfen. Recovery Time Objective (RTO) legt fest, wie schnell der Dienst wieder funktionieren muss.

Beispiele:

• RPO 24 Stunden kann ein tägliches Backup erlauben.
• RPO 15 Minuten benötigt häufig WAL-Archivierung oder einen vergleichbaren PITR-Ansatz.
• RTO 8 Stunden erlaubt mehr manuelle Wiederherstellungsschritte.
• RTO 30 Minuten benötigt vorbereitete Infrastruktur, Automatisierung und regelmäßig belegte Laufzeiten.

RPO und RTO gelten für die Anwendung, nicht nur für PostgreSQL. Wenn die Datenbank nach 20 Minuten läuft, aber Storage-Dateien sechs Stunden benötigen, ist die Anwendungs-RTO nicht erreicht.

Logisches Backup, physisches Backup und PITR

Logische Backups exportieren Datenbankobjekte und Daten. Sie sind portabel und eignen sich für Migrationen oder selektive Wiederherstellung, können bei großen Datenbanken aber lange dauern.

Physische Backups sichern den Datenbankzustand näher an den zugrunde liegenden Dateien. Sie können schneller wiederherstellbar sein, sind aber stärker an Version und Betriebsmodell gebunden.

Point-in-Time-Recovery (PITR) kombiniert einen Basisstand mit fortlaufenden Transaktionsprotokollen. Damit lässt sich ein Zeitpunkt kurz vor einer fehlerhaften Änderung ansteuern.

Ein Betrieb kann mehrere Verfahren kombinieren: tägliche logische Exporte für Portabilität und physische Sicherung oder PITR für kurze Recovery-Ziele.

Storage-Dateien separat sichern

Die offizielle Supabase-Dokumentation stellt klar, dass Datenbank-Backups die in der Storage API gespeicherten Objektdateien nicht einschließen. Gesichert werden müssen:

• alle Buckets und Objektpfade
• Dateien und Dateigrößen
• Content Types und relevante Metadaten
• Versionen, falls im Speicherziel vorhanden
• Zuordnung zu den Metadatensätzen in PostgreSQL

Bei einer Wiederherstellung müssen Datenbankstand und Objektbestand zueinander passen. Neue Datenbank-Metadaten mit alten Dateien oder umgekehrt können zu fehlenden und verwaisten Objekten führen.

Konsistenz zwischen Datenbank und Storage

Für strenge Konsistenz kann während einer vollständigen Sicherung ein kurzes Schreibfenster nötig sein. Andere Systeme akzeptieren eine dokumentierte zeitliche Abweichung und gleichen nach.

Praktische Kontrollen sind:

• Objektzahl pro Bucket
• Gesamtsumme der Dateigrößen
• Prüfsummen für kritische Dateien
• Stichproben über die Storage API
• Vergleich zwischen Storage-Metadaten und vorhandenen Objekten
• Test mit privaten und signierten Downloads

Die 3-2-1-Regel sinnvoll anwenden

Als robuste Ausgangsbasis gilt:

• mindestens drei Kopien der relevanten Daten
• auf mindestens zwei unterschiedlichen Speichertypen oder Systemen
• mindestens eine Kopie getrennt vom Primärsystem

Für produktive Systeme kommen hinzu:

• Verschlüsselung bei Übertragung und Ablage
• getrennte Zugangsdaten
• unveränderbare oder gegen Löschung geschützte Aufbewahrung
• definierte Retention für Tages-, Wochen- und Monatsstände
• Überwachung von Alter, Größe und Erfolg

Ein Backup im selben Host und mit denselben Administratorzugängen schützt nur gegen einen Teil der Risiken.

Auth und Secrets beim Restore

Auth-Daten können in PostgreSQL enthalten sein. Ein funktionsfähiger Login benötigt zusätzlich:

• passende JWT-Konfiguration
• Auth-Provider und OAuth-Credentials
• korrekte Redirect-URLs
• SMTP und E-Mail-Templates
• DNS und öffentliche Domains
• Secrets für Functions und Webhooks

Ändern sich JWT-Secrets, können vorhandene Sessions ungültig werden. Das Restore-Runbook muss festlegen, ob alte Schlüssel wiederhergestellt oder Nutzer kontrolliert neu angemeldet werden.

Restore-Tests statt Backup-Vertrauen

Ein grüner Backup-Job beweist nur, dass ein Prozess ohne gemeldeten Fehler endete. Ein Restore-Test beantwortet die entscheidenden Fragen:

1. Sind Backups auffindbar und entschlüsselbar?
2. Lässt sich PostgreSQL in der Zielversion starten?
3. Sind Storage-Dateien vollständig zugeordnet?
4. Funktionieren Auth, RLS und Functions?
5. Erreicht die Anwendung kritische Nutzerwege?
6. Werden RPO und RTO tatsächlich eingehalten?

Tests sollten in einer isolierten Umgebung erfolgen, damit sie Produktion nicht überschreiben und keine E-Mails oder Webhooks versehentlich auslösen.

Monitoring und Verantwortlichkeit

Überwacht werden mindestens:

• letzter erfolgreicher Lauf
• Alter des jüngsten Wiederherstellungspunkts
• Backup-Größe und auffällige Abweichungen
• Speicherplatz und Retention
• Fehler bei Upload oder Verschlüsselung
• Ergebnis und Dauer des letzten Restore-Tests

Jeder Alarm benötigt einen Empfänger und eine Reaktionsregel. Sonst bleibt aus Backup-Automatisierung nur unbeaufsichtigter Speicherverbrauch.

Quellen

• Supabase: Datenbank-Backups
• Supabase: Self-Hosting
• Supabase: Cloud zu Self-Hosted übertragen
• PostgreSQL: Backup und Restore