Backups bei EmDash: Was die eingebaute Sicherung kann und was du zusätzlich brauchst

Überarbeitet für EmDash 1.1.0 am 6. Oktober 2026. Alle Varianten neu getestet mit der Blog-Vorlage für Cloudflare, der lokalen Datenbank dieser Site und einer leeren D1-Datenbank bei Cloudflare. Was sich geändert hat, steht am Ende des Artikels.

Du hast dich sicher auch schon gefragt, wie man bei EmDash Backups macht, denn auch hier braucht es sie. Ein Update, das schiefgeht, ein Import, der mehr überschreibt als gedacht, oder ein Beitrag, den jemand aus Versehen löscht: Irgendwann willst du einen früheren Stand zurück. Cloudflare macht es dir dabei leichter als ein eigener Server: Die Datenbank sichert sich selbst, der Speicher für die Bilder liegt schon bereit, und ein Zeitplan für wiederkehrende Aufgaben gehört zu jedem Worker. Genau darauf baut die Backup-Funktion auf, die ich im Juli in EmDash eingebaut habe (PR #1890).

Allein reicht diese Funktion aber nicht, und sie ist auch nicht die einzige Möglichkeit. Für diesen Artikel habe ich jede Variante mit der Datenbank dieser Site und einer Wegwerf-Datenbank bei Cloudflare ausprobiert. Du erfährst hier, was jede davon sichert, was du im Ernstfall zurückbekommst und was ich für eine kleine Site einrichten würde. Falls du noch keine EmDash-Site hast, fang mit dem Einstieg in EmDash an.

Was bei WordPress anders ist

WordPress selbst bringt keine Backup-Funktion mit. Unter Werkzeuge → Daten exportieren bekommst du zwar eine XML-Datei mit Beiträgen, Seiten, Kommentaren, Feldern, Kategorien und Menüs (Doku zum Export), aber ohne die Bilddateien, Plugins, Themes und Einstellungen. Die Anleitung von WordPress rät deshalb, Datenbank und Dateien getrennt zu sichern, mehrere Stände an verschiedenen Orten aufzubewahren und für die Automatik ein Plugin zu nehmen.

Läuft WordPress oder ein anderes CMS auf einem eigenen Server, bleibt das an dir oder deinem Hoster hängen. Jemand muss den Dump der Datenbank einrichten, die Dateien kopieren, beides an einen zweiten Ort bringen und ab und zu ausprobieren, ob sich das Ganze überhaupt zurückspielen lässt. Gerade dieser letzte Schritt fällt im Alltag gern weg, und man merkt es erst, wenn man das Backup wirklich braucht.

Mit EmDash auf Cloudflare fällt ein grosser Teil dieser Arbeit weg. Die Sicherung im Admin brauchst du nur einzuschalten. Die Datenbank in D1 sichert sich ohnehin laufend selbst: Mit Time Travel setzt du sie auf jede Minute der letzten 30 Tage zurück, ohne Cronjob und ohne Speicherplatz, um den du dich kümmern musst. Auf einem eigenen Server müsstest du so etwas mit den Logs der Datenbank selbst aufbauen. Und die Bilder liegen in R2 verteilt über mehrere Rechenzentren. Cloudflare legt R2 auf eine Haltbarkeit von 99,999999999 Prozent im Jahr aus (Doku zur Haltbarkeit). Die eine defekte Festplatte, die auf einem kleinen Server die Uploads mitnimmt, muss dich hier nicht mehr beschäftigen.

Zwei Risiken bleiben trotzdem bei dir. Gegen Löschen schützt die beste Haltbarkeit nicht, egal ob du es selbst warst oder jemand mit Zugriff auf dein Konto. Das schreibt Cloudflare in derselben Doku. Ausserdem liegt bei dieser Lösung alles bei einem Anbieter. Wird dein Konto gesperrt oder gelöscht, verschwinden Datenbank, Bilder und Time Travel zusammen. Eine Kopie ausserhalb von Cloudflare lohnt sich deshalb auch hier, und weiter unten zeige ich dir, welche Variante sich dafür eignet.

Woraus deine Site besteht

Bei WordPress sicherst du zwei Dinge, die Datenbank und die Dateien. Eine EmDash-Site auf Cloudflare ist auf vier Orte verteilt. In der Datenbank D1 liegen Beiträge, Seiten, Revisionen, Menüs, Benutzer, Einstellungen und die Daten von Plugins. Die Bilder und anderen Mediendateien liegen in R2, dem Speicher von Cloudflare, und in der Datenbank steht nur, welche es gibt. Der Code mit Vorlage, Konfiguration und deinen eigenen Komponenten liegt in deinem Projekt und ist mit Git bereits gesichert.

Der vierte Ort wird gern vergessen: der Schlüssel EMDASH_ENCRYPTION_KEY, falls du ihn gesetzt hast. Mit ihm verschlüsselt EmDash geheime Einstellungen von Plugins, zum Beispiel einen API-Schlüssel. Er liegt als Secret bei Cloudflare und steckt in keiner der Sicherungen, um die es hier geht.

Keine Variante deckt alle vier Orte ab. Darum lohnt es sich, sie einzeln anzuschauen.

Variante 1: Die eingebaute Sicherung im Admin

Du findest sie unter Einstellungen → Backups. Ein Plugin brauchst du dafür nicht. Zurückspielen lässt sich die Datei bewusst noch nicht: Ein Restore überschreibt Daten, und dafür soll es zuerst einen durchdachten Weg über das CLI geben (Discussion #142). Für den Ernstfall ist deshalb Variante 2 da.

Oben lädst du mit „Backup herunterladen“ eine Sicherung direkt auf deinen Rechner, darunter schaltest du die automatischen Backups ein.

Sind die täglichen Backups eingeschaltet, legt EmDash einmal am Tag eine Sicherung in deinem Medien-Bucket ab, im Ordner backups/. Wie viele Stände es aufbewahrt, stellst du zwischen 1 und 30 ein, voreingestellt sind 7, und die älteren räumt EmDash selbst weg. Die Sicherung läuft mit denselben Wartungsaufgaben, die auch geplante Beiträge veröffentlichen, und braucht dafür einen Cron-Trigger im Worker. Die Blog-Vorlage bringt ihn in wrangler.jsonc schon mit, du musst also nichts einrichten. Sehen und bedienen können die Seite nur Administratoren.

Was in so einer Datei steckt, habe ich mit der lokalen Datenbank dieser Site nachgeschaut. Die Sicherung war 1,7 MB gross und nach 112 Millisekunden fertig. Sie enthält 16 Tabellen mit allen Beiträgen und Seiten samt Entwürfen und Papierkorb, den Inhaltstypen und Feldern, Rubriken und Themen, Menüs, Widgets, SEO-Angaben, den Metadaten der Medien und den Einstellungen der Site. Den Löwenanteil machen die Revisionen aus, 41 Stück mit zusammen 1,6 MB.

Mindestens so wichtig ist, was fehlt. Benutzer, Passkeys, API-Tokens und alles Geheime habe ich bewusst draussen gelassen, weil die Datei auf deinem Rechner, in einer Mail oder in einem geteilten Ordner landen kann. Ebenfalls nicht dabei sind Kommentare, Weiterleitungen und Autorenangaben, die Daten und Einstellungen von Plugins und die Mediendateien selbst. Die Datei ist gut lesbares JSON und taugt für eigene Auswertungen oder als Archiv, wie ein Beitrag vor Monaten aussah. Weil sie sich nicht einspielen lässt, würde ich mich vor einem Update oder einem grossen Import aber nicht auf sie verlassen.

Einen Hinweis noch, falls du deinen Bucket über eine eigene Domain öffentlich gemacht hast. Die Sicherungen liegen im selben Bucket wie deine Bilder. EmDash selbst verweigert jeden Abruf aus dem Ordner backups/, über eine öffentliche Adresse des Buckets wären die Dateien aber erreichbar, sofern jemand den Namen errät. Darum hängt EmDash an jeden Namen einen zufälligen Teil. Lieferst du deine Bilder über EmDash aus, wie es die Vorlage tut, betrifft dich das nicht.

Variante 2: D1 Time Travel

Im Ernstfall ist das die Sicherung, die dich rettet, und das Schöne daran: Du musst nichts dafür tun. Cloudflare hält für jede D1-Datenbank fest, wie sie zu jedem Zeitpunkt aussah, und setzt sie auf Wunsch auf jede Minute der letzten 30 Tage zurück, im kostenlosen Workers-Plan auf die letzten 7 Tage (Doku zu Time Travel). Extra kostet das nichts.

Time Travel umfasst die ganze Datenbank, also auch Benutzer, Kommentare und die Daten der Plugins. Bevor du etwas Riskantes machst, etwa ein Update von EmDash oder einen grossen Import, lohnt es sich, den aktuellen Stand zu notieren. Den Namen deiner Datenbank findest du in wrangler.jsonc unter database_name:

npx wrangler d1 time-travel info DEINE-DATENBANK

Wrangler antwortet mit einem sogenannten Bookmark und gleich mit dem Befehl, der genau dorthin zurückführt. Statt eines Bookmarks kannst du auch einen Zeitpunkt angeben:

npx wrangler d1 time-travel restore DEINE-DATENBANK --timestamp=2026-10-01T09:00:00+02:00

Geh mit diesem Befehl vorsichtig um, denn er überschreibt die Datenbank vollständig. Alles, was seit dem gewählten Zeitpunkt dazugekommen ist, ist danach weg, auch ein Kommentar von heute Morgen. Immerhin gibt dir Wrangler dabei ein neues Bookmark aus, mit dem du den Restore wieder rückgängig machen kannst.

Grenzen hat Time Travel zwei. Weiter als 30 Tage reicht es nicht zurück, und es kümmert sich nur um die Datenbank. Ein Bild, das du in R2 gelöscht hast, holt es dir nicht zurück.

Variante 3: Das Site-Paket

Unter Einstellungen → Umzug exportierst du die ganze Site in eine Datei mit der Endung .emdash. Gedacht ist das Paket für den Umzug auf eine andere EmDash-Installation, sogar auf eine mit einer anderen Datenbank. Für Sicherungen ist es trotzdem spannend, denn es ist die einzige Variante, in der auch die Bilder stecken.

Bei mir war der Export nach gut einer Sekunde fertig. Das Paket war 1,9 MB gross und bestand aus 20 Dateien. Darin waren die Inhalte mit allen Revisionen und Übersetzungen, Rubriken, Autorenangaben, Menüs und Weiterleitungen, auf Wunsch die Kommentare und die beiden Bilder der Site als echte Dateien. Benutzerkonten, Passkeys, API-Tokens und die Daten von Plugins lässt EmDash draussen. Name und E-Mail-Adresse der Autoren nimmt es dagegen mit, damit du sie auf der neuen Site wieder zuordnen kannst. Behandle die Datei also so sorgfältig wie eine Datenbanksicherung.

Bei grösseren Sites nimmst du am besten „Paket herunterladen“. Dann holt der Browser die Dateien einzeln und prüft jede davon. „Als einzelne Datei herunterladen“ geht schneller, kann laut Admin bei grossen Sites auf Cloudflare aber scheitern. Auf dem Server bleibt ein Export sieben Tage abrufbar (Doku zum Umzug), lad ihn also gleich herunter und leg ihn irgendwo ausserhalb von Cloudflare ab. Wer lieber im Terminal arbeitet, macht dasselbe mit dem CLI:

npx emdash login --url https://deine-site.ch
npx emdash site export --url https://deine-site.ch --output site.emdash

Einen Wermutstropfen hat das Paket. Importieren lässt es sich nur in eine Site ohne eigene Inhalte, und meine bestehende Site hat den Import prompt abgelehnt und aufgelistet, was ihr dafür im Weg steht. Im Notfall setzt du also eine neue EmDash-Site auf, importierst das Paket und lädst die Benutzer neu ein. Das ist mehr Arbeit als ein Restore, klappt aber auch dann noch, wenn Time Travel nicht mehr weit genug zurückreicht.

Variante 4: Ein SQL-Dump mit Wrangler

Wer seine Datenbank komplett und ausserhalb von Cloudflare haben will, greift zu wrangler d1 export. Bei einer EmDash-Datenbank bricht der einfache Befehl allerdings ab:

Schuld ist die Suche. EmDash legt für jeden Inhaltstyp mit eingeschalteter Suche einen Index als sogenannte virtuelle Tabelle an, und solche Tabellen kann D1 nicht exportieren (Doku zum Export). In der Backup-Doku von EmDash habe ich deshalb einen Umweg beschrieben (PR #3876), bei dem du alle anderen Tabellen einzeln exportierst und auf vier Dateien verteilst. Den Suchindex baut EmDash danach selbst wieder auf.

Mit der lokalen Datenbank lief dieser Export in 7 Sekunden über 72 Tabellen und ergab vier Dateien mit zusammen 1,8 MB. In eine normale SQLite-Datei liessen sie sich in unter einer Sekunde einspielen, mit allen 11 Beiträgen, 41 Revisionen, dem Benutzer und den 90 Migrationen. Als vollständige Kopie, die du auf deinem Rechner öffnen und durchsuchen kannst, funktioniert der Dump also bestens.

Ernüchternd wurde es beim Weg zurück nach D1, und zwar für mich ganz besonders, denn getestet hatte ich das Rezept vorher mit der Demo-Site, deren Beiträge kurz sind. Mit den Daten dieser Site liess sich der Dump weder lokal noch in eine leere Datenbank bei Cloudflare einspielen. Tabellen, Indizes und Trigger kamen an, die Datei mit den Inhalten brach mit statement too long ab, und am Ende stand eine Datenbank ohne einen einzigen Beitrag, Benutzer oder Migration da. D1 erlaubt pro SQL-Befehl höchstens 100 KB (Grenzen von D1), und unser Leitfaden für Agenturen mit rund 3400 Wörtern ergab samt Revisionen Befehle von 113 KB. Schreibst du lange Artikel, ist der Dump deshalb eine gute Kopie für den Notfall ausserhalb von Cloudflare, aber kein Weg, die Site mit einem Befehl zurückzuholen. Diese Grenze gehört in die Doku, und darum kümmere ich mich als Nächstes.

Und die Bilder?

Time Travel kümmert sich nur um D1, und weder die eingebaute Sicherung noch der Dump enthalten die Dateien. Für die Bilder bleiben dir zwei Wege: das Site-Paket aus Variante 3 oder eine Kopie des ganzen Buckets. Weil R2 dieselbe Schnittstelle wie Amazon S3 spricht, funktioniert dafür zum Beispiel die AWS-Kommandozeile:

aws s3 sync s3://DEIN-BUCKET ./medien-backup --endpoint-url https://DEINE-ACCOUNT-ID.r2.cloudflarestorage.com

Dafür legst du im Dashboard von Cloudflare einen API-Token für R2 an, am besten nur mit Leserechten. Die Kopie enthält übrigens auch die automatischen Sicherungen aus dem Ordner backups/.

Der Schlüssel, den keine Sicherung enthält

Hast du EMDASH_ENCRYPTION_KEY gesetzt, weil ein Plugin zum Beispiel ein Passwort oder einen API-Schlüssel speichert, dann gehört er zusätzlich in deinen Passwortmanager. Er steht weder in der Datenbank noch in Time Travel, einem Dump oder einem Paket. Ohne ihn kann EmDash die gespeicherten Geheimnisse deiner Plugins nach einer Wiederherstellung nicht mehr lesen, und dann darfst du jeden Schlüssel neu eintragen.

Die Varianten im Vergleich

Was ich für eine kleine Site einrichten würde

Time Travel läuft bei dir schon, du musst es nur kennen. Mach es dir zur Gewohnheit, vor jedem Update und jedem grösseren Import das Bookmark mit npx wrangler d1 time-travel info zu notieren. Das ist ein einziger Befehl und erspart dir im Ernstfall die Suche nach dem richtigen Zeitpunkt.

Die täglichen Backups im Admin würde ich trotz ihrer Grenzen einschalten. Sie kosten nichts und zeigen dir auch nach mehr als 30 Tagen noch, wie ein Beitrag einmal ausgesehen hat. Als einzige Sicherung reichen sie aber nicht.

Am wichtigsten finde ich das Site-Paket. Lad es einmal im Monat herunter und leg es ausserhalb von Cloudflare ab, auf deinem Rechner oder in einem anderen Cloud-Speicher. Es ist die einzige Sicherung, die Inhalte und Bilder zusammen enthält und dich auch nach einem gesperrten Konto oder einem Fehler vor sechs Wochen wieder auf die Beine bringt. Und falls du EMDASH_ENCRYPTION_KEY verwendest, gehört der Schlüssel in deinen Passwortmanager.

Wer es gründlicher mag, ergänzt das um eine regelmässige Kopie des Buckets und einen SQL-Dump, beides lässt sich gut als Skript automatisieren. Für die meisten kleinen Sites reichen die drei Gewohnheiten oben aber völlig.

Und bei dir?

Wie sicherst du deine EmDash-Site? Und musstest du schon einmal etwas zurückspielen, mit Time Travel, einem Paket oder einer eigenen Lösung? Schreib es in die Kommentare. Ich ergänze den Artikel mit dem, was ihr meldet.