Backups und Wiederherstellung

Ein Wiederherstellungspunkt muss die gesamte Datenbank wiederherstellen. Die JSON-Backups von EmDash eignen sich zur Inspektion und für eigene Werkzeuge, EmDash kann sie aber nicht wiederherstellen. Verwenden Sie vor einer Datenbankmigration oder einer destruktiven Operation ein Roh-Datenbank-Backup oder Point-in-Time-Recovery.

Sichern Sie Medien-Binärdateien separat. Wenn die Site verschlüsselte Plugin-Einstellungen speichert, bewahren Sie die vollständige EMDASH_ENCRYPTION_KEY-Rotationsliste in einem separaten Secret-Manager-Backup auf. Datenbank-Backups und Exporte enthalten weder diese Dateien noch diese Schlüssel.

Eine Wiederherstellungsmethode wählen

Verwenden Sie die Methode, die zum konfigurierten Datenbank-Adapter der Site passt:

Bewahren Sie den Wiederherstellungspunkt zusammen mit dem passenden Anwendungs-Artefakt, dem Medien-Backup und der Version der Schlüsselliste auf. Notieren Sie vor einer geplanten Migration die genaue Datenbank und Umgebung, stoppen Sie Schreibvorgänge der Anwendung, wenn das Verfahren des Anbieters das verlangt, und bestätigen Sie, dass der Wiederherstellungspunkt für das vorgesehene Rollback-Fenster verfügbar bleibt.

Medienobjekte sichern und wiederherstellen

R2- und S3-kompatible Buckets brauchen zusätzlich zur Datenbank ein Backup auf Objektebene. Der folgende AWS-CLI-Befehl kopiert jedes Objekt, einschließlich der JSON-Archive von EmDash unter backups/, in ein lokales Backup-Verzeichnis. Für AWS S3 lassen Sie --endpoint-url weg.

aws s3 sync s3://emdash-media ./emdash-media-backup \
  --endpoint-url https://<account-id>.r2.cloudflarestorage.com

Ersetzen Sie <account-id> durch die Cloudflare-Konto-ID. Verwenden Sie für routinemäßige Backup-Jobs schreibgeschützte Bucket-Zugangsdaten. Speichern Sie das Backup außerhalb des Produktionskontos oder der Failure-Domain und notieren Sie den gleichzeitig erstellten Datenbank-Wiederherstellungspunkt.

Stellen Sie in einen leeren Recovery-Bucket wieder her, statt die Produktion zu überschreiben, während sie Anfragen bedient:

aws s3 sync ./emdash-media-backup s3://emdash-media-recovery \
  --endpoint-url https://<account-id>.r2.cloudflarestorage.com

Geben Sie dem Restore-Job nur Schreibzugriff auf den Recovery-Bucket. Richten Sie ein Nicht-Produktions-Deployment auf die wiederhergestellte Datenbank und den wiederhergestellten Bucket, öffnen Sie mehrere bekannte Medien-URLs und laden Sie eine Wegwerfdatei hoch und löschen Sie sie wieder. Ändern Sie das Produktions-Binding oder die Bucket-Konfiguration erst, nachdem Datenbank und Medien ihre Prüfungen gemeinsam bestanden haben.

Kopieren Sie bei lokalem Speicher das Verzeichnis, das der local()-Storage-Adapter konfiguriert. Stoppen Sie Medien-Schreibvorgänge, während Sie es kopieren, und prüfen Sie anschließend repräsentative Dateien aus der Kopie.

Eine D1-Datenbank mit Time Travel wiederherstellen

Fragen Sie vor einer Migration bei Time Travel das aktuelle Bookmark der Datenbank ab und notieren Sie die vollständige Ausgabe zusammen mit dem Deployment:

npx wrangler d1 time-travel info my-database

Time-Travel-Wiederherstellungspunkte verfallen. Cloudflare bewahrt sie derzeit 7 Tage im Workers-Free-Tarif und 30 Tage im Workers-Paid-Tarif auf. Erstellen Sie einen Offsite-D1-Dump, wenn das Rollback-Fenster länger sein muss.

Wenn eine Wiederherstellung nötig ist, stoppen Sie Schreibvorgänge auf der Site und stellen Sie genau das vor der Migration notierte Bookmark wieder her:

npx wrangler d1 time-travel restore my-database \
  --bookmark="<pre-migration-bookmark>"

Ersetzen Sie <pre-migration-bookmark> durch das notierte Bookmark. Der Befehl überschreibt die Datenbank an Ort und Stelle und bricht laufende Abfragen ab. Speichern Sie das vom Restore-Befehl ausgegebene vorherige Bookmark, damit sich der Restore selbst rückgängig machen lässt.

Time Travel stellt Inhalte, Benutzer, Einstellungen, Plugin-Daten und Migrationsdatensätze wieder her. Es stellt weder R2-Medienobjekte noch EMDASH_ENCRYPTION_KEY wieder her. Stellen Sie das passende Anwendungs-Artefakt, die Medien und die Schlüssel wieder her, bevor Sie den Traffic erneut öffnen. Prüfen Sie Anmeldung, Inhaltslesen, das Schema, eine verschlüsselte Plugin-Einstellung und einen Schreibvorgang.

Aktuelle Aufbewahrungsfristen, Voraussetzungen und das Restore-Verhalten finden Sie in der D1-Time-Travel-Dokumentation.

Einen Offsite-D1-Dump erstellen

Für einen SQL-Dump der Rohdatenbank (einschließlich Benutzer- und Auth-Tabellen) verwenden Sie Wrangler. Ein einfaches wrangler d1 export my-database --remote schlägt mit D1 Export error: cannot export databases with Virtual Tables (fts5) fehl, sobald in einer Collection die Suche aktiviert ist, weil EmDash seinen Suchindex in virtuellen FTS5-Tabellen ablegt. Exportieren Sie die anderen Tabellen namentlich und lassen Sie den Suchindex weg; die wiederhergestellte Site baut ihn neu auf.

Der Dump wird in vier Dateien aufgeteilt, damit eine Wiederherstellung gelingt:

• backup-schema.sql erstellt die Tabellen.
• backup-folders.sql enthält die Medienordner. Große Importe laufen in Teilen, sodass ein Medienelement sonst vor dem Ordner eingefügt würde, zu dem es gehört, und die Fremdschlüsselprüfung fehlschlagen würde.
• backup-data.sql enthält alle übrigen Zeilen.
• backup-indexes.sql enthält die Indizes und Trigger, die ein Export nach Tabellennamen auslässt. Sie werden zuletzt erstellt, damit die Trigger beim Import der Zeilen nicht ausgelöst werden.

Diese Befehle benötigen jq. Die folgenden Befehle schreiben die vier Dateien:

npx wrangler d1 execute my-database --remote --json \
  --command "SELECT name FROM sqlite_master WHERE type = 'table' AND name NOT GLOB '_emdash_fts_*' AND name NOT GLOB 'sqlite_*' AND name NOT GLOB '_cf_*' AND name != 'media_folders'" \
  | jq -r '.[0].results[] | "--table=" + .name' > backup-tables.txt

npx wrangler d1 export my-database --remote --no-data --output=backup-schema.sql \
  --table=media_folders $(cat backup-tables.txt)
npx wrangler d1 export my-database --remote --no-schema --output=backup-folders.sql \
  --table=media_folders
npx wrangler d1 export my-database --remote --no-schema --output=backup-data.sql \
  $(cat backup-tables.txt)

npx wrangler d1 execute my-database --remote --json \
  --command "SELECT sql FROM sqlite_master WHERE type IN ('index', 'trigger') AND sql IS NOT NULL AND name NOT GLOB '_emdash_fts_*' AND tbl_name NOT GLOB '_emdash_fts_*' AND tbl_name NOT GLOB '_cf_*'" \
  | jq -r '.[0].results[] | .sql + ";"' > backup-indexes.sql

Die Export-Optionen und Grenzen von Wrangler finden Sie in der D1-Dokumentation zu Import und Export.

Bewahren Sie die SQL-Dateien zusammen mit der passenden Anwendungsversion, dem gleichzeitig erstellten Medien-Backup und einer separat gespeicherten Kopie der EMDASH_ENCRYPTION_KEY-Rotationsliste auf. Testen Sie die Wiederherstellung, indem Sie die Dateien in eine neu bereitgestellte leere D1-Datenbank importieren, die Runtime-Schlüssel wiederherstellen, ein Nicht-Produktions-Binding auf diese Datenbank umstellen und die Site prüfen.

Importieren Sie die Dateien in dieser Reihenfolge in die leere Recovery-Datenbank:

npx wrangler d1 execute my-recovery-database --remote --file=backup-schema.sql
npx wrangler d1 execute my-recovery-database --remote --file=backup-folders.sql
npx wrangler d1 execute my-recovery-database --remote --file=backup-data.sql
npx wrangler d1 execute my-recovery-database --remote --file=backup-indexes.sql

Die wiederhergestellte Datenbank hat keinen Suchindex. EmDash baut ihn beim ersten Aufruf der Such-API (/_emdash/api/search) auf der wiederhergestellten Site neu auf, zum Beispiel durch die Befehlspalette der Administration oder ein Suchfeld, das die API nutzt. Bis dahin liefern Seiten, die search() direkt aufrufen, keine Ergebnisse. Um sofort neu aufzubauen, rufen Sie einmal /_emdash/api/search?q=a auf, sobald die Site läuft.

SQLite und lokales libSQL sichern

Stoppen Sie für ein Offline-Backup jeden Prozess, der die Datenbank schreibt, und kopieren Sie die Datenbankdatei zusammen mit allen -wal- und -shm-Dateien daneben. Die -wal-Datei kann festgeschriebene Änderungen enthalten, die noch nicht in der Hauptdatei stehen.

Für ein konsistentes Online-Backup verwenden Sie den Backup-Befehl von SQLite auf den Pfad, den der Datenbank-Adapter konfiguriert:

sqlite3 emdash.db ".backup backup.db"

Prüfen Sie die kopierte Datenbank. Der Befehl muss ok ausgeben:

sqlite3 backup.db "PRAGMA integrity_check"

Öffnen Sie die Kopie mit der passenden Anwendungsversion in einer Nicht-Produktionsumgebung und prüfen Sie Anmeldung, öffentliche Inhalte, eine verschlüsselte Plugin-Einstellung, eine Bearbeitung und einen Medienlese-Vorgang.

Stoppen Sie zur Wiederherstellung jeden Prozess, der die Datenbank schreibt, behalten Sie eine Kopie der beschädigten Datenbank samt ihren -wal- und -shm-Dateien, ersetzen Sie sie durch das geprüfte Backup und stellen Sie das passende Anwendungs-Artefakt, die Medien und die Schlüssel wieder her, bevor Sie den Traffic erneut öffnen.

PostgreSQL und Hyperdrive sichern

Verwenden Sie die Point-in-Time-Recovery oder die Snapshot-Funktion des PostgreSQL-Anbieters, wenn sie eine isolierte Wiederherstellung bietet, die sich testen lässt, bevor Produktion verändert wird. Notieren Sie den genauen Zeitstempel oder die Snapshot-ID und die Aufbewahrungsdauer.

Für ein portables Backup verbinden Sie sich direkt mit dem PostgreSQL-Ursprung und erstellen ein Archiv im Custom-Format:

pg_dump --format=custom --file=emdash.dump "$DATABASE_URL"

pg_dump erstellt ein transaktional konsistentes Archiv, während die Datenbank weiter in Benutzung bleibt. Prüfen Sie das Inhaltsverzeichnis des Archivs, bevor Sie sich darauf verlassen:

pg_restore --list emdash.dump > emdash.dump.list

Stellen Sie eine leere Recovery-Datenbank bereit. Verbinden Sie sich als kanonische EmDash-Anwendungsrolle und stellen Sie wieder her, ohne die Eigentümerschaft der Quelle in die Recovery-Datenbank zu übernehmen:

pg_restore --exit-on-error --no-owner \
  --dbname="$RECOVERY_DATABASE_URL" emdash.dump

Die Rolle in RECOVERY_DATABASE_URL wird Eigentümerin der wiederhergestellten EmDash-Objekte. Verwenden Sie dieselbe stabile Rolle, die auch die wiederhergestellte Anwendung nutzen wird. Richten Sie ein Nicht-Produktions-Deployment auf die Recovery-Datenbank und prüfen Sie Anmeldung, Inhaltslesen, das Schema, eine verschlüsselte Plugin-Einstellung und einen Schreibvorgang.

Bei Hyperdrive muss DATABASE_URL die direkte Verbindung zum PostgreSQL-Ursprung sein, die migrationConnectionStringEnv benennt; das Worker-Binding lässt sich nicht an PostgreSQL-Backup-Werkzeuge übergeben. Folgen Sie dem Wiederherstellungsverfahren des Ursprungs-Anbieters und bewahren Sie die Hyperdrive-Konfiguration zusammen mit dem Anwendungs-Artefakt auf.

Informationen zu anbieterverwalteter Wiederherstellung, großen Datenbanken und kontinuierlicher Archivierung finden Sie in der PostgreSQL-Backup-Dokumentation.

Von Turso gehostetes libSQL sichern

Die Point-in-Time-Recovery von Turso erstellt aus einem früheren Zeitstempel eine separate Datenbank. Notieren Sie unmittelbar vor der Migration einen RFC-3339-Zeitstempel. Wenn eine Wiederherstellung nötig ist, erstellen Sie aus diesem Zeitpunkt eine isolierte Datenbank:

turso db create emdash-recovery \
  --from-db emdash-production \
  --timestamp <pre-migration-rfc3339-timestamp>

Ersetzen Sie <pre-migration-rfc3339-timestamp> durch den notierten Zeitstempel. Erstellen Sie ein Token für die wiederhergestellte Datenbank, richten Sie ein Nicht-Produktions-Deployment darauf und prüfen Sie die Site, bevor Sie die Produktionsverbindung ändern. Die Aufbewahrungsdauer Ihres Tarifs finden Sie unter Turso Point-in-Time-Recovery.

Für eine Offsite-Kopie erstellen Sie einen Dump der gesamten Datenbank:

turso db shell emdash-production .dump > emdash.sql

Testen Sie den Dump, indem Sie daraus eine isolierte Datenbank erstellen:

turso db create emdash-recovery --from-dump ./emdash.sql

Folgen Sie bei einem anderen Remote-libSQL-Anbieter dessen Verfahren für den Export der gesamten Datenbank oder die Point-in-Time-Recovery. Wenden Sie keine Remote-Migration an, bevor dieses Verfahren einen Wiederherstellungspunkt erzeugt und eine isolierte Wiederherstellung getestet wurde.

JSON-Backups zur Inspektion verwenden

Ein JSON-Backup enthält:

• Alle Inhaltseinträge, einschließlich Entwürfe, geplante Beiträge und Papierkorb-Elemente
• Collection- und Felddefinitionen, die das Inhaltsmodell bilden
• Taxonomie-Definitionen, Begriffe und die jedem Eintrag zugewiesenen Begriffe
• Menüs und Menüeinträge, Abschnitte, Widget-Bereiche und Widgets, SEO-Datensätze, Revisionsverlauf, Medien-Metadaten und Datenbank-Migrationsverlauf
• Site-Einstellungen wie Titel, Tagline, URL, Locale, Logo, Anzeigeeinstellungen, Social-Profile und SEO-Standards aus der Einstellungsgruppe site: und den Einstellungen emdash:site_title, emdash:site_tagline und emdash:locale

Es lässt aus:

• Benutzerkonten, Sessions, Passkeys, OAuth-Daten, API-Tokens und andere Authentifizierungsdaten
• Plugin-Speicher und Plugin-Einstellungen, einschließlich Plugin-Geheimnisse
• Kommentare und Reaktionen, Weiterleitungen und 404-Protokolle, Bylines, Inhaltsrelationen und Referenzen, Audit-Logs, Rate-Limits und den Zustand geplanter Aufgaben
• Medienordner, Aufzeichnungen darüber, wo Medien verwendet werden, unvollständige Uploads und die Mediendateien selbst

Unter Settings → Backups erzeugt Download backup eine frische JSON-Datei. Back up now speichert eine unter dem Präfix backups/, wenn ein Speicher konfiguriert ist. Diese Dateien verwenden dasselbe versionierte Snapshot-Format wie die Previews von EmDash.

Um JSON-Backups zu planen, aktivieren Sie unter Settings → Backups die Option Daily automatic backups und wählen Sie eine Aufbewahrung von 1–30 Dateien. Sie laufen während der geplanten Wartung. Auf Cloudflare braucht der Worker einen Cron-Trigger; unter Node führt der eingebaute Scheduler die Aufgabe aus.

Wenn der Bucket eine öffentliche R2-Domain oder einen CDN-Ursprung hat, beschränken Sie diesen Ursprung auf Medienobjekte oder liefern Sie Medien über EmDash aus. Die Medien-Route von EmDash weigert sich, backups/ auszuliefern, aber ein öffentlicher Bucket-Ursprung kann jedes Objekt per URL offenlegen.

Um Inhalte, Einstellungen und Medien in eine neue EmDash-Site zu kopieren, verwenden Sie ein Site-Paket. Ein Site-Paket stellt weder Benutzer, API-Tokens, Plugin-Daten noch Geheimnisse wieder her und ersetzt daher keinen Datenbank-Wiederherstellungspunkt.