Lege zuerst fest, ob du einzelne Workflows übertragen oder eine ganze Instanz wiederherstellen möchtest. Sichere den tatsächlichen Datenbestand konsistent und bewahre den passenden Schlüssel geschützt auf. Ein isolierter Restore-Test ist aussagekräftiger als eine vorhandene Exportdatei.
Workflowexport oder vollständige Instanzsicherung?
Ein JSON-Export enthält die ausgewählten Workflows oder Credentials. Er ist beispielsweise für eine kontrollierte Übertragung nützlich. Nutzer, Rollen, Ausführungshistorie, Variablen und sämtliche Instanzeinstellungen sind damit nicht automatisch mitgesichert.
| Ziel | Was du dafür brauchst |
|---|---|
| Workflows übertragen | Passende Workflow- und gegebenenfalls Credential-Exporte mit geklärter Zuordnung im Ziel. |
| Eine Instanz wiederherstellen | Konsistente Instanzdaten, wirksamen Schlüssel, passende Konfiguration und zusätzlich verwendete Speicher. |
Die aktuelle n8n-Hilfe weist ausdrücklich darauf hin, dass der CLI-Schalter --backup nur Workflows und Credentials exportiert. Sein Name ist keine Zusage für ein vollständiges Systembackup.
Ein vollständiger Rückweg gehört auch dazu, wenn du n8n-Updates mit gesichertem Ausgangsstand planen möchtest. Ein früheres Containerimage allein setzt mögliche Datenbankänderungen nicht zurück.
Datenbank, Schlüssel und Speicherorte inventarisieren
Notiere zuerst n8n-Version, Betriebsform, Datenbanktyp und tatsächliche Speicherorte. Der Benutzerordner heißt standardmäßig ~/.n8n. Bei Docker ist häufig ein Volume nach /home/node/.n8n eingebunden. Maßgeblich ist deine wirkliche Konfiguration, nicht der Beispielname einer Anleitung.
Bei SQLite liegt die Datenbank normalerweise im Benutzerordner. Bei PostgreSQL liegt sie außerhalb; der Benutzerordner bleibt trotzdem relevant. Externe Binär- oder Ausführungsdaten, eigene Speicherpfade und zusätzliche Custom-Node-Verzeichnisse gehören ebenfalls ins Inventar, wenn dein Aufbau sie verwendet.
Du musst außerdem Credentials und Verschlüsselungsschlüssel unterscheiden: Credentials sind die gespeicherten Dienstzugänge. Der Instanzschlüssel verschlüsselt diese Daten. n8n erzeugt ihn beim ersten Start und speichert ihn in der Konfiguration oder verwendet einen passend gesetzten eigenen Schlüssel.
Ein restaurierter verschlüsselter Bestand bleibt ohne den passenden wirksamen Schlüssel nicht nutzbar. Notiere im eigenen Sicherungsprüfblatt nur dessen geschützten Ablageort, niemals den Schlüsselwert. Das Blatt gehört zum privaten Betriebsplan; echte Sicherungen und Schlüssel gehören nicht in einen öffentlichen Websiteordner.
Workflows und Credentials getrennt exportieren
Die Server CLI läuft im Kontext deiner selbst gehosteten Installation und greift direkt auf deren Datenbank zu. Sie ist von der entfernten API-CLI zu unterscheiden und hat weitreichende administrative Möglichkeiten. Führe die dokumentierten Befehle nur für deine bewusst gewählte Instanz und mit einem geschützten Ausgabepfad aus.
Dokumentierte Exportform, privaten Zielpfad vorher ersetzen
n8n export:workflow --backup --output=/DEIN_PRIVATER_BACKUPPFAD/workflows/
n8n export:credentials --backup --output=/DEIN_PRIVATER_BACKUPPFAD/credentials/--backup kombiniert --all --pretty --separate. Die beiden Befehle brauchen getrennte Verzeichnisse. Die aktuelle Hilfe nennt einen Importfehler, wenn Credential- und Workflowdateien im selben Verzeichnis liegen.
In Docker befindet sich die CLI im Container. Ein beliebiger Exportpfad innerhalb des Containers ist nicht automatisch dauerhaft gespeichert. Verwende einen bewusst persistenten, geschützten Zielweg oder übertrage die Dateien kontrolliert heraus. Die Beispiele oben richten diesen Weg nicht selbst ein.
Ein Export mit --decrypted schreibt Dienstzugänge im Klartext. Das ist kein unkritischer Standardschritt dieser Anleitung. Auch normale Exporte können vertrauliche Metadaten enthalten; sie sind nicht als öffentliche Beispieldateien gedacht. Hier wurde kein echter Export ausgeführt.
Datenbank und externe Dateien konsistent sichern
Bei SQLite kann die Kopie einer Datenbankdatei während laufender Schreibvorgänge inkonsistent werden. n8n empfiehlt, den Dienst vor einer Ordnerkopie zu stoppen oder eine geeignete konsistente Snapshotmethode zu verwenden. Ein unkoordiniertes Kopieren einzelner Dateien ist kein gleichwertiger Ersatz.
PostgreSQL wird mit dessen geeigneten Datenbankwerkzeugen gesichert. pg_dump erzeugt einen konsistenten logischen Snapshot einer Datenbank. Rollen und Tablespaces sind globale Objekte; sie sind nicht automatisch Bestandteil dieses einzelnen Dumps. Benutzerordner, Konfiguration und externe Speicher bleiben zusätzliche Teile des Wiederherstellungsplans.
Welche Sicherungs- und Restore-Methode passt, hängt von Version, Datenmenge und Betrieb ab. Kombiniere nicht blind einen alten Datenbankstand mit neueren Dateispeichern. Halte Zeitpunkte und Abhängigkeiten fest.
Beim Containerbetrieb solltest du persistente Daten im n8n-Container prüfen. Ein anderes Compose-Projekt oder ein anderes Volume kann wie eine leere Instanz aussehen, obwohl die ursprünglichen Daten an einem anderen Ort liegen.
Wiederherstellung zuerst isoliert nachweisen
Plane die Probe in einer getrennten Umgebung mit begrenzten ausgehenden Verbindungen. Wiederhergestellte Workflows dürfen nicht versehentlich echte Nachrichten senden, produktive Daten ändern oder denselben Zeitplan parallel zur bestehenden Instanz ausführen.
| Prüfpunkt | Erwartete Beobachtung |
|---|---|
| Datenbestand | Erwartete Nutzer, Workflows und benötigte Dateien sind vorhanden. |
| Entschlüsselung | Die bewusst gewählten Testzugänge lassen sich mit dem passenden Schlüssel lesen. |
| Umgebung | Zieladressen und Konten zeigen auf die Testumgebung. |
| Außenwirkung | Trigger und veröffentlichter Zustand sind bewusst geprüft; kein ungewollter produktiver Lauf. |
CLI-Importe enthalten ursprüngliche IDs. Bereits vorhandene Elemente mit denselben IDs können überschrieben werden. Ein frisches isoliertes Ziel ist daher leichter zu beurteilen als ein ungeprüfter Import in eine volle Produktivinstanz.
Die aktuelle CLI-Referenz beschreibt außerdem modusspezifische Grenzen beim Aktivierungszustand und ein bekanntes Problem mit weiterlaufenden Cron-Triggern nach bestimmten Importen. Verlasse dich deshalb nicht allein auf einen Schalter. Prüfe den tatsächlichen Zustand und die passende aktuelle Restore-Dokumentation.
Sicherungsrhythmus und Wiederanlauf dokumentieren
Lege fest, welche Datenlücke du im Fehlerfall tolerierst und wie schnell der Dienst wieder nutzbar sein soll. Daraus leitest du Sicherungsrhythmus, Aufbewahrung und benötigte Wiederherstellungsschritte ab. Eine pauschale Zahl passt nicht zu jedem Workflow.
Bewahre eine geschützte Kopie getrennt vom ursprünglichen Ausfallort auf. Dokumentiere, wer darauf zugreifen darf und wie der benötigte Schlüssel im Fehlerfall verfügbar wird. Eine Sicherung auf derselben ausgefallenen Festplatte erfüllt diesen Zweck nicht.
Notiere Datum, Version, geprüften Umfang und tatsächlich beobachtetes Ergebnis jeder Restore-Probe. Eine vorhandene ZIP-Datei oder eine erfolgreiche Exportmeldung beweist nur einen Teil des Rückwegs. Auch ein gelungener Test gilt zunächst für den geprüften Stand.
Quellenstand: 20. Oktober 2026. Dieser Artikel beschreibt einen Betriebsplan und eigene Prüfhilfen. Es wurden keine Instanzen gestoppt, Datenbanken kopiert, Zugangsdaten exportiert oder Wiederherstellungen durchgeführt.
Quellen & Methode
Vorgehen und Grenzen
Originaldokumentation am 20. Oktober 2026 im dokumentierten Umfang geprüft; vier ausgewählte vollständige Haupttexte je Thema verglichen. Eigene Planungsbeispiele, Rechenwerte und Grafiken sind Lernhilfen. Keine tatsächlichen Backups, Restores, MCP-Aufrufe, Modelltests oder Activepieces-Läufe behauptet.
Bei Recherche, Texterstellung und Grafiken wird KI eingesetzt. Welche eigenen Versuche vorliegen und was nur als Beispiel dient, beschreibt dieser Beitrag. Unser Redaktionsstandard erklärt die Anforderungen an Belege und Berichtigungen.
