So sicherst du deine App-Datenbank (und stellst sie wirklich wieder her)

Um deine App-Datenbank zu sichern, exportierst du sie nach Zeitplan in eine Datei (bei Postgres ist das Standardwerkzeug pg_dump), bewahrst Kopien getrennt von der Datenbank auf und stellst regelmäßig eine davon in einer leeren Datenbank wieder her, um zu beweisen, dass es funktioniert. Mach zusätzlich ein Backup direkt vor jeder riskanten Änderung. Dein Code-Backup, egal ob GitHub-Repository oder Export, enthält deine Daten nicht.

Diese Anleitung richtet sich an Leute, die eine kleine App betreiben und sich keine Sorgen mehr um Datenverlust machen wollen. Die Beispiele nutzen Postgres, weil die meisten mit KI gebauten Apps es verwenden, die Grundsätze gelten aber für jede Datenbank.

Was ein Backup abdecken muss

Eine App ist mehr als ihre Datenbank. Wisse, welchen Teil jedes Backup schützt.

Die Daten sind der Teil, den du nicht neu erschaffen kannst. Code lässt sich neu schreiben und Einstellungen lassen sich neu eingeben, die Bestellungen deiner Kunden nicht.

Schritt 1: Festlegen, wie viel du verlieren darfst

Zwei Fragen bestimmen deinen Backup-Plan:

• Wie viele aktuelle Daten darfst du verlieren? Wenn du einmal am Tag sicherst und die Datenbank am Abend ausfällt, gehen die Änderungen dieses Tages verloren. Für eine Hobby-App ist das in Ordnung. Für eine App, die Bestellungen annimmt, vielleicht nicht.
• Wie lange darf die App während der Wiederherstellung offline sein? Eine kleine Datenbank ist in Minuten wiederhergestellt. Eine große kann deutlich länger brauchen, und das solltest du wissen, bevor du es brauchst.

Für die meisten kleinen Apps ist ein tägliches automatisches Backup plus ein manuelles vor riskanten Änderungen ein vernünftiger Start. Apps, bei denen Geld oder Gesundheitsdaten im Spiel sind, brauchen häufigere Backups oder eine verwaltete Datenbank mit Point-in-Time-Recovery (der Möglichkeit, auf einen beliebigen Zeitpunkt zurückzusetzen, nicht nur auf das letzte Backup).

Schritt 2: Prüfen, was dein Hosting-Anbieter schon macht

Viele Anbieter verwalteter Datenbanken erstellen automatisch Backups. Finde heraus:

• Sind Backups in deinem Tarif aktiv, und wie oft laufen sie?
• Wie lange werden sie aufbewahrt?
• Kannst du auf einen Zeitpunkt zurücksetzen oder nur auf einen täglichen Snapshot?
• Kannst du ein Backup herunterladen oder nur innerhalb ihres Systems wiederherstellen?

Anbieter-Backups sind nützlich, teilen sich aber mit deiner Datenbank einen gemeinsamen Ausfallpunkt: das Konto. Wird das Konto geschlossen oder gesperrt oder das Projekt gelöscht, können die Backups mit verschwinden. Deshalb brauchst du zusätzlich eine eigene Kopie.

Schritt 3: Einen Dump mit pg_dump erstellen

pg_dump exportiert eine Postgres-Datenbank in eine Datei. Es liest einen konsistenten Snapshot, daher kann die App während des Vorgangs weiterlaufen.

Ein typischer Befehl, der den Verbindungsstring verwendet, den deine App bereits in einer Umgebungsvariablen hat:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

Was die Optionen bewirken:

• --format=custom schreibt eine komprimierte Datei, die pg_restore lesen kann, und erlaubt dir, später einzelne Tabellen wiederherzustellen. Verwende --format=plain, wenn du stattdessen eine lesbare .sql-Datei willst.
• --no-owner lässt Befehle zum Besitzer weg, was das Wiederherstellen in eine andere Datenbank vereinfacht.
• Das Datum im Dateinamen hält Backups auseinander.

Die Version von pg_dump sollte gleich oder neuer sein als die Postgres-Version deiner Datenbank. Ein älteres pg_dump verweigert unter Umständen den Start.

Wenn du mit KI baust und die Kommandozeile nicht anfassen willst, kannst du fragen:

Erstelle ein Backup der Datenbank der App mit pg_dump im Custom-Format, mit dem heutigen Datum im Dateinamen. Gib keinen Verbindungsstring und kein anderes Geheimnis aus. Sag mir den Dateinamen und die Größe, wenn es fertig ist.

Schritt 4: Automatisieren

Manuelle Backups werden vergessen. Automatisiere sie mit dem, was dein Setup unterstützt:

• Die geplanten Backups deines Datenbank-Anbieters, falls er welche anbietet.
• Ein geplanter Job auf einem Server oder CI-Dienst, der pg_dump ausführt und die Datei in den Speicher hochlädt.
• Ein gehosteter Backup-Dienst, der sich mit deiner Datenbank verbindet.

Welche Variante du auch wählst: Sorge dafür, dass dich ein Fehlschlag des Backups benachrichtigt. Ein Backup-Job, der drei Monate lang still gescheitert ist, ist die klassische Horrorgeschichte.

Schritt 5: Kopien an einem anderen Ort speichern

Die Faustregel heißt oft 3-2-1: drei Kopien deiner Daten, auf zwei verschiedenen Arten von Speicher, davon eine außerhalb des Standorts. Für eine kleine App sieht das praktisch so aus:

• Die Live-Datenbank
• Die automatischen Backups des Anbieters
• Deine eigenen Dumps in getrenntem Speicher, etwa einem Objektspeicher-Bucket in einem anderen Konto

Außerdem:

• Zugriff einschränken. Ein Backup enthält die Daten jedes Nutzers. Behandle es wie die Live-Datenbank.
• Eine Aufbewahrungsregel festlegen. Zum Beispiel tägliche Backups für zwei Wochen und monatliche für ein Jahr. Lösche alte Backups bewusst, und denk daran, dass Datenschutzgesetze dich unter Umständen verpflichten, personenbezogene Daten auf Anfrage zu löschen.
• Backups niemals in Git committen. Ein Dump in einem Repository ist ein Datenleck, das nur auf seine Chance wartet.

Schritt 6: Eine Wiederherstellung testen

Ein Backup ist nur so gut wie deine letzte erfolgreiche Wiederherstellung. Mindestens alle paar Monate und nach jeder Änderung am Backup-Prozess:

1. Erstelle eine neue, leere Datenbank. Stelle zum Testen niemals über die Live-Datenbank wieder her.
2. Stelle das neueste Backup dort wieder her:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

Für eine einfache .sql-Datei verwende stattdessen psql "$TEST_DATABASE_URL" -f backup.sql.

1. Prüfe, ob alle Tabellen existieren, vergleiche die Zeilenanzahl mit der Live-Datenbank und schau dir ein paar aktuelle Datensätze an.
2. Verbinde eine Kopie der App damit und melde dich an, falls möglich.
3. Notiere, wie lange die Wiederherstellung gedauert hat. Das ist deine tatsächliche Wiederherstellungszeit.

Schritt 7: Vor riskanten Änderungen sichern

Erstelle ein frisches Backup direkt vor:

• Einer Datenbankmigration, die Spalten löscht oder umbenennt
• Einem Massenimport von Daten
• Einem KI-Agenten, der große Änderungen am Datenmodell vornimmt
• Dem Löschen alter Datensätze

In einer mit KI gebauten App kann der Agent die Tabellenstruktur als Teil einer Funktion ändern. Checkpoints und Versionskontrolle setzen deinen Code zurück, machen aber gelöschte Zeilen nicht wieder sichtbar. Ein Backup von dreißig Sekunden vor einer großen Änderung ist eine günstige Versicherung.

Häufige Fehler

• Annehmen, Git oder ein Code-Export sei ein Backup. Er enthält den Code, nicht die Daten.
• Nie eine Wiederherstellung testen. Viele Backups stellen sich erst dann als leer, unvollständig oder unlesbar heraus, wenn man sie braucht.
• Backups im selben Konto wie die Datenbank aufbewahren. Ein kompromittiertes oder geschlossenes Konto verliert beides.
• Hochgeladene Dateien vergessen. Die Datenbank speichert nur den Pfad der Datei; das Bild selbst liegt im Speicher.
• Geheimnisse in Backup-Skripten lassen. Lies den Verbindungsstring aus einer Umgebungsvariablen, nie aus dem Text des Skripts. Siehe wie du API-Schlüssel sicher aufbewahrst.

Backups und Mythex

Mythex-Projekte können eine eigene Postgres-Datenbank haben, und deren Verbindungsdaten werden in den Workspace und die veröffentlichte App eingespeist. Die Mythex-Dokumentation beschreibt keine Backup- oder Wiederherstellungsfunktion für Datenbanken, plane daher selbst: Bitte den Agenten, einen Dump zu erstellen, lade ihn herunter und bewahre ihn sicher auf, besonders vor großen Änderungen. Ein Projektexport (Pro) enthält deinen Code, wobei Geheimnisse und node_modules ausgelassen werden; er enthält keine Datenbankzeilen. Siehe Datenbank und Datenhoheit in der Dokumentation. Mehr zur Datenbank selbst findest du unter was ist Postgres.

Backup-Checkliste

• Festgelegt, wie viele Daten du verlieren darfst und wie lange du offline sein kannst
• Geprüft, welche automatischen Backups dein Datenbank-Anbieter bietet
• Dein eigener Dump läuft nach Zeitplan, und Fehler lösen eine Benachrichtigung aus
• Kopien getrennt von der Datenbank gespeichert, mit eingeschränktem Zugriff
• Aufbewahrungsregel schriftlich festgehalten
• Hochgeladene Dateien ebenfalls gesichert, nicht nur die Datenbank
• Wiederherstellung in eine leere Datenbank getestet, Zeilenanzahl geprüft
• Vor jeder riskanten Änderung ein Backup erstellt

Fragen