Backups und Wiederherstellung

Nutzen Sie ein JSON-Backup, wenn Sie eine Offline-Kopie ausgewählter Inhaltsdaten brauchen. EmDash kann diese Datei nicht importieren. Ein Wiederherstellungsplan braucht ein Roh-Datenbank-Backup oder Point-in-Time-Recovery und eine separate Kopie der Medien-Binärdateien.

Um Inhalte, Einstellungen und Medien einer Site in eine neue EmDash-Site zu kopieren, auch auf einer anderen Datenbank, verwenden Sie stattdessen ein Site-Paket.

Wenn die Site verschlüsselte Plugin-Einstellungen speichert, bewahren Sie die vollständige EMDASH_ENCRYPTION_KEY-Rotationsliste in einem separaten Secret-Manager-Backup auf. Der Schlüssel wird nie in der Datenbank, D1 Time Travel, einem SQL-Dump oder einem JSON-Export gespeichert.

Was in einem Backup enthalten ist

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. Diese stammen aus der Einstellungsgruppe site: und den Einstellungen emdash:site_title, emdash:site_tagline und emdash:locale.

Es lässt alle anderen Datenbanktabellen aus, einschließlich:

• 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 Zustand geplanter Aufgaben
• Medienordner, Aufzeichnungen darüber, wo Medien verwendet werden, unvollständige oder laufende Uploads und die Medien- Dateien selbst
• Andere Site-Optionen, einschließlich der bei der Einrichtung aufgezeichneten Deployment-URL (emdash:site_url), des Preview-Signaturgeheimnisses und des Backup-Zeitplans

Backups sind JSON-Dateien im gleichen Snapshot-Format wie EmDashs Preview-System, versioniert mit dem EmDash-Release, das sie erstellt hat.

Ein-Klick-Download

Unter Settings → Backups im Admin erzeugt die Schaltfläche Download backup ein frisches Backup und lädt es als JSON-Datei herunter. Erfordert die Admin-Rolle.

Der Download dient der Inspektion oder eigener Tools. Vor Massenimporten, Schemaänderungen oder großen Upgrades erstellen Sie ein wiederherstellbares Datenbank-Backup mit einer der Optionen unten. Um die Site auf eine andere EmDash-Site zu verschieben, exportieren Sie unter Settings → Transfer ein Site-Paket.

Automatische Backups in den Speicher

Wenn Ihre Site ein Storage-Backend konfiguriert hat (R2 auf Cloudflare, S3 oder lokaler Speicher), können Sie tägliche automatische Backups aktivieren:

Archive werden unter dem Präfix backups/ in Ihrem Bucket als emdash-backup-<timestamp>-<random>.json gespeichert. Die Liste Stored Backups im Admin lässt Sie einzelne Archive herunterladen oder löschen, und Back up now erstellt eines auf Abruf.

Automatische Backups hängen am geplanten Wartungs-Tick (derselbe Mechanismus wie geplantes Veröffentlichen) — auf Cloudflare ist das der Cron-Trigger des Workers, unter Node der eingebaute Scheduler. Wenn Ihr Deployment keinen Cron-Trigger konfiguriert hat, nutzen Sie stattdessen Back up now oder die Download- Schaltfläche.

Medienobjekte sichern und wiederherstellen

R2- und S3-kompatible Buckets brauchen zusätzlich zur Datenbank ein Objekt-Level-Backup. Das folgende AWS-CLI-Beispiel kopiert jedes Objekt, einschließlich EmDashs backups/-Archive, 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

Nutzen Sie schreibgeschützte Bucket-Zugangsdaten für Routine-Backup-Jobs. Speichern Sie das Backup außerhalb des Produktionskontos oder Failure-Domain und notieren Sie das gleichzeitig erstellte Datenbank-Backup oder Time-Travel-Punkt.

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 Schreibzugriff nur auf den Recovery-Bucket. Richten Sie ein Nicht-Produktions-Deployment auf diesen Bucket, öffnen Sie mehrere bekannte Medien-URLs und laden Sie eine Wegwerfdatei hoch und löschen Sie sie. Wechseln Sie das Produktions-Binding oder die Bucket-Konfiguration erst, nachdem die wiederhergestellte Datenbank und der Mediensatz ihre Prüfungen gemeinsam bestanden haben.

Eine D1-Datenbank mit Time Travel wiederherstellen

Vor einer riskanten Operation fragen Sie Time Travel nach dem aktuellen Bookmark und notieren Sie ihn mit dem Deployment oder Änderungsdatensatz:

npx wrangler d1 time-travel info my-database

Wenn eine Wiederherstellung nötig ist, stoppen Sie Schreibvorgänge auf der Site und prüfen Sie den verfügbaren Restore-Punkt, bevor Sie den destruktiven Restore-Befehl ausführen:

npx wrangler d1 time-travel restore my-database --timestamp=2026-07-08T13:00:00Z

Time Travel stellt die gesamte Datenbank wieder her, einschließlich Inhalte, Benutzer, Einstellungen, Plugin-Daten und Migrationsdatensätze. Es stellt keine R2-Medienobjekte oder EMDASH_ENCRYPTION_KEY wieder her. Bevor Sie Plugin-Integrationen testen, stellen Sie jeden Verschlüsselungsschlüssel wieder her, auf den die wiederhergestellten Plugin-Einstellungen verweisen. Nach Abschluss des Befehls deployen Sie die Anwendungsversion, die zur wiederhergestellten Datenbank passt, öffnen Sie den Traffic erneut und prüfen Sie Anmeldung, Inhaltslesen, Schemaänderungen, eine verschlüsselte Plugin-Einstellung und einen Schreibvorgang.

Details siehe die D1 Time Travel-Dokumentation.

Einen Offsite-D1-Dump erstellen

Für einen vollständigen SQL-Dump der Rohdatenbank (einschließlich Benutzer- und Auth-Tabellen) verwenden Sie Wrangler:

npx wrangler d1 export my-database --remote --output=backup.sql

Bewahren Sie die SQL-Datei 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 den Dump in eine neu bereitgestellte leere D1-Datenbank importieren, die Runtime-Schlüssel wiederherstellen, ein Nicht-Produktions-Binding auf diese Datenbank aktualisieren und die Site prüfen.

Importieren Sie in die leere Recovery-Datenbank mit dem folgenden Befehl:

npx wrangler d1 execute my-recovery-database --remote --file=backup.sql

SQLite-Backup und Wiederherstellung

Für ein Offline-SQLite-Backup stoppen Sie 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 sind. Für ein konsistentes Online-Backup verwenden Sie den Backup-Befehl von SQLite:

sqlite3 emdash.db ".backup backup.db"

Sichern Sie das lokale Upload-Verzeichnis oder den S3-kompatiblen Bucket und die EMDASH_ENCRYPTION_KEY-Rotationsliste separat. Zur Wiederherstellung stoppen Sie jeden Serverprozess, behalten Sie eine Kopie der beschädigten Datenbank, ersetzen Sie sie durch das geprüfte Backup, stellen Sie die Runtime-Schlüssel und alle erforderlichen Medienobjekte wieder her und starten Sie die passende Anwendungsversion. Prüfen Sie Anmeldung, öffentliche Inhalte, eine verschlüsselte Plugin-Einstellung, eine Bearbeitung und einen Medienlese-Vorgang, bevor Sie den Traffic wieder öffnen.

JSON-Exporte können eine Site nicht wiederherstellen

EmDash hat keine Admin-Aktion, keinen API-Endpunkt und keinen CLI-Befehl für JSON-Wiederherstellung. Nutzen Sie D1 Time Travel, einen Roh- D1-SQL-Dump oder eine Kopie der SQLite-Datenbank wie oben beschrieben.

Um die Inhalte einer Site in einer neuen, leeren EmDash-Site neu aufzubauen, exportieren Sie ein Site-Paket von der Original-Site, solange sie noch verfügbar ist, und importieren Sie es in die neue Site. Ein Site-Paket stellt weder Benutzer, API-Tokens, Plugin-Daten noch Geheimnisse wieder her und ersetzt daher kein Datenbank- Backup für Disaster Recovery.