n8n self-hosted Backup-Strategien: Workflows & Daten sichern

n8n self-hosted Backup-Strategien bezeichnen alle Maßnahmen, mit denen du Workflows, Credentials und die Datenbank deiner selbst gehosteten n8n-Instanz zuverlässig sicherst. Dazu gehören Docker-Volume-Mappings, automatisierte pg_dump-Cronjobs, CLI-Exporte und Tools wie restic – damit du nach einem Update oder Serverausfall in Minuten wiederherstellst.

Wer n8n selbst hostet, trägt die volle Verantwortung für seine Daten. Kein Cloud-Anbieter springt ein, wenn nach einem Docker-Update plötzlich alle Workflows weg sind. Laut Community-Berichten ist genau das der häufigste Fehlerfall: anonyme Volumes, kein Host-Pfad-Mapping, kein Backup. Wer dagegen eine durchdachte n8n self-hosted Backup-Strategie betreibt, stellt nach einem Totalausfall in unter 10 Minuten wieder her. Dieser Leitfaden zeigt dir, welche Daten du sichern musst, welche Tools dabei helfen und wie du den Prozess automatisierst.

Was sind n8n self-hosted Backup-Strategien?

n8n self-hosted Backup-Strategien: Alle technischen und organisatorischen Maßnahmen, mit denen du Workflows, Credentials, die Datenbank und den Verschlüsselungsschlüssel einer selbst betriebenen n8n-Instanz regelmäßig, automatisiert und redundant sicherst – sodass du nach einem Datenverlust vollständig wiederherstellst.

Selbst gehostetes n8n absichern bedeutet mehr als einen gelegentlichen Export. Denn n8n speichert mehrere Datenkategorien an unterschiedlichen Orten. Deshalb braucht jede Datenkategorie eine eigene Sicherungsstrategie.

Welche Daten müssen gesichert werden?

Folgende vier Bereiche musst du bei einer n8n Datensicherung self-hosted abdecken:

• Workflows: JSON-Definitionen aller Automations – der Kern deiner n8n-Arbeit.
• Credentials: Verschlüsselte Zugangsdaten zu APIs, Datenbanken und Diensten.
• Datenbank: SQLite-Datei oder Postgres-Schema mit Ausführungshistorie und Einstellungen.
• N8N_ENCRYPTION_KEY: Der Schlüssel, mit dem Credentials verschlüsselt sind – ohne ihn sind alle Backups der Credentials wertlos.

Wer einen dieser Bereiche vergisst, hat kein vollständiges Backup. Besonders der N8N_ENCRYPTION_KEY wird laut Community-Erfahrungen am häufigsten übersehen – mit fatalen Folgen beim Restore.

Die 3-2-1-Regel angewendet auf n8n

Die 3-2-1-Regel ist das bewährteste Grundprinzip für Datensicherung: 3 Kopien deiner Daten, auf 2 verschiedenen Medien, davon 1 Kopie außerhalb des Servers (offsite). Angewendet auf n8n heißt das konkret:

• Lokal auf dem Host: täglicher pg_dump oder SQLite-Kopie im Verzeichnis /srv/docker/n8ndata.
• Zweites Medium: restic-Backup in einen S3-kompatiblen Object Storage (z. B. Hetzner Storage Box oder Backblaze B2).
• Offsite: Verschlüsseltes Archiv auf einem zweiten Cloud-Anbieter oder lokaler NAS an einem anderen Standort.

Damit bist du gegen Serverausfall, Ransomware und menschliche Fehler gleichzeitig abgesichert. Die empfohlene Retention liegt bei 7 bis 30 Tagen – so kannst du auch einen Fehler, der erst nach einer Woche auffällt, noch rückgängig machen.

Docker-Volumes und Dateisystem richtig absichern

Datenverlust durch anonyme Docker-Volumes ist laut Community-Berichten der häufigste Fehlerfall bei selbst gehosteten n8n-Instanzen. Daher beginnt jede solide n8n self-hosted Backup-Strategie mit dem richtigen Volume-Setup – noch bevor ein einziges Backup-Tool zum Einsatz kommt.

Benannte Volumes statt anonymer Volumes verwenden

Anonyme Docker-Volumes erhalten bei jedem Redeploy eine neue ID. Dadurch verlierst du beim Update alle Daten, die nicht explizit gemappt wurden. Benannte Volumes hingegen bleiben über Updates hinweg stabil und sind einfach zu sichern.

Statt volumes: - /home/node/.n8n (anonym) verwendest du in deiner docker-compose.yml einen benannten Volume-Eintrag:

volumes:
  n8ndata:
    driver: local

Anschließend referenzierst du diesen Volume im Service-Block. Dadurch bleibt der Volume-Name konstant und du kannst ihn zuverlässig in Backup-Skripte einbinden.

Host-Pfad-Mapping für /home/node/.n8n

Noch direkter ist das Host-Pfad-Mapping: Du bindest das n8n-Datenverzeichnis direkt an einen Pfad auf dem Host. Der empfohlene Pfad lautet /srv/docker/n8ndata:/home/node/.n8n.

In der Praxis bedeutet das: Du öffnest deine docker-compose.yml und trägst unter volumes des n8n-Services ein:

volumes:
  - /srv/docker/n8ndata:/home/node/.n8n

Danach liegt alles – SQLite-Datei, Workflow-JSONs, Config – unter /srv/docker/n8ndata auf deinem Host. Dieses Verzeichnis kannst du mit jedem Standard-Backup-Tool direkt sichern. Wer außerdem den n8n Docker-Setup Guide von Contabo als Referenz nutzt, findet dort weitere Empfehlungen zum Volume-Setup auf VPS-Systemen.

Datenbank-Backup: SQLite vs. Postgres im Vergleich

Die Wahl der Datenbank bestimmt, wie du das Backup technisch umsetzt. Hier ein direkter Vergleich beider Optionen aus Backup-Perspektive:

Kriterium	SQLite	Postgres
Backup-Methode	Dateikopie (cp, rsync)	pg_dump / pg_dumpall
Konsistenz	Nur bei gestopptem Container sicher	Online-Dump möglich (MVCC)
Automatisierung	Einfach per Cron + cp	Cron + pg_dump-Skript
Produktionstauglichkeit	Default, für Tests geeignet	Empfohlen für Produktion
Restore-Aufwand	Datei zurückkopieren	psql-Import, etwas komplexer

SQLite ist der Standard bei einfachen Installationen. Für Produktionsumgebungen empfiehlt die Community jedoch Postgres – weil Online-Dumps möglich sind und die Datenbank stabiler mit gleichzeitigen Schreibzugriffen umgeht.

SQLite-Backup per Dateikopie

Bei SQLite liegt die Datenbank als einzelne Datei unter /srv/docker/n8ndata/database.sqlite. Für ein konsistentes Backup musst du den n8n-Container vorher anhalten – sonst riskierst du eine korrupte Kopie.

Ein einfaches Bash-Skript für den Cron-Job sieht so aus:

docker stop n8n
cp /srv/docker/n8ndata/database.sqlite /backup/n8n/database-$(date +%F).sqlite
docker start n8n

Damit hast du eine datierte Kopie. Kombiniere das mit einer Retention von 7 bis 30 Tagen, indem du ältere Dateien automatisch löschst.

Postgres mit pg_dump und Cron automatisieren

Bei Postgres verwendest du pg_dump für tägliche Dumps. Dabei läuft der Container weiter – Postgres erlaubt konsistente Snapshots im laufenden Betrieb dank MVCC (Multi-Version Concurrency Control, ein Mechanismus für gleichzeitige Lese- und Schreibzugriffe).

Ein Cron-Eintrag für nächtliche n8n Datenbank Backups um 2 Uhr:

0 2 * * * docker exec n8n-postgres pg_dump -U n8n n8n > /backup/n8n/n8n-$(date +%F).sql

Zusätzlich empfiehlt sich pg_dumpall für einen vollständigen Dump inklusive Rollen und Berechtigungen. Bewahre die Dumps 7 bis 30 Tage auf – das ist die in der Community etablierte Retention für /srv/docker/n8ndata.

n8n self-hosted Backup-Strategien mit restic, Borg und Duplicati

Für das Dateisystem-Backup des gesamten n8n-Datenverzeichnisses eignen sich dedizierte Backup-Tools. Hier die drei gängigsten Optionen für die Backup-Strategie für selbst gehostetes n8n:

• restic: Deduplizierender, verschlüsselter Backup-Client. Sichert /srv/docker/n8ndata direkt in S3-kompatiblen Object Storage. Einfache Syntax, schnelle Restores, aktiv gepflegt. Ideal für automatisierte Cron-Jobs oder systemd-Timer.
• borgbackup: Verschlüsselte, inkrementelle Backups mit flexibler Retention-Policy über systemd-Timer oder Cron. Besonders stark bei großen Datenmengen durch Deduplizierung auf Block-Ebene. Gut geeignet, wenn du auf eine lokale NAS oder einen SSH-Zielserver sicherst.
• Duplicati: GUI-basiertes Backup-Tool, das als eigener Container läuft. Sichert Docker-Volumes und Datenbank-Dumps über eine Web-Oberfläche. Einsteigerfreundlicher als restic oder borgbackup, jedoch mit etwas höherem Overhead.

restic für inkrementelle Backups in Object Storage

restic ist die erste Wahl, wenn du n8n Docker Backup in einen Cloud-Speicher automatisieren willst. Ein typisches Backup-Skript stoppt zuerst den n8n-Container, sichert das Volume und startet den Container neu – so gewährleistest du Datenkonsistenz:

docker stop n8n
restic -r s3:s3.amazonaws.com/mein-bucket/n8n backup /srv/docker/n8ndata
docker start n8n
restic -r s3:s3.amazonaws.com/mein-bucket/n8n forget --keep-daily 14 --prune

Mit --keep-daily 14 behältst du 14 tägliche Snapshots und löschst ältere automatisch. Das entspricht der GCE-Empfehlung, Snapshots älter als 14 Tage automatisch zu löschen, um Storage-Kosten zu begrenzen.

borgbackup und Duplicati als Alternativen

borgbackup eignet sich besonders, wenn du auf einen SSH-Server oder eine lokale NAS sicherst. Die Retention-Policy lässt sich feingranular steuern – etwa täglich für 7 Tage, wöchentlich für 4 Wochen. Viele erfahrene n8n-Admins kombinieren borgbackup lokal mit restic in Object Storage, weil sich beide Tools dabei ideal ergänzen.

Duplicati richtet sich an alle, die eine grafische Oberfläche bevorzugen. Es läuft als Docker-Container im selben Stack und sichert Volumes und Datenbank-Dumps ohne Kommandozeile. Allerdings empfiehlt sich auch hier ein Blick auf den n8n Backup Manager im Community-Forum – ein speziell für n8n entwickeltes, selbst gehostetes Backup-Tool, das Workflows und Datenbank über eine eigene Web-Oberfläche verwaltet. Es wurde am 18.12.2025 im n8n Community Forum veröffentlicht.

Workflows und Credentials per CLI exportieren

n8n bietet eine eingebaute CLI für den Export von Workflows und Credentials. Damit erstellst du menschenlesbare JSON-Exporte, die unabhängig vom Datenbankformat funktionieren – ein wichtiger zweiter Sicherungsweg neben dem Datenbank-Backup.

1. Öffne ein Terminal und wechsle in das Verzeichnis deines n8n-Docker-Stacks.
2. Exportiere alle Workflows: docker exec n8n n8n export:workflows --all --output=/home/node/.n8n/backups/workflows.json
3. Exportiere alle Credentials: docker exec n8n n8n export:credentials --all --output=/home/node/.n8n/backups/credentials.json
4. Sichere den Zielordner /srv/docker/n8ndata/backups/ zusätzlich mit restic oder borgbackup in deinen Offsite-Speicher.
5. Automatisiere beide Befehle als Cron-Job – täglich um 3 Uhr empfiehlt sich als Zeitfenster mit wenig Last.
6. Prüfe wöchentlich, ob die Export-Dateien tatsächlich Inhalt haben – ein leeres JSON ist ein stiller Fehler.

n8n export:workflows und export:credentials im Cron-Job

Der Cron-Eintrag für den automatisierten Export sieht so aus:

0 3 * * * docker exec n8n n8n export:workflows --all --output=/home/node/.n8n/backups/workflows-$(date +%F).json
5 3 * * * docker exec n8n n8n export:credentials --all --output=/home/node/.n8n/backups/credentials-$(date +%F).json

Dadurch entstehen täglich datierte JSON-Dateien. Kombiniere das mit deiner restic- oder borgbackup-Routine, damit die Exporte auch offsite landen. Wer außerdem auf der Suche nach der passenden Marketing-Automatisierungssoftware ist, findet bei soeners.digital einen Überblick, welche Tools sich mit n8n sinnvoll kombinieren lassen.

N8N_ENCRYPTION_KEY sichern – der häufigste Fehler

Der N8N_ENCRYPTION_KEY ist der kritischste Bestandteil deiner n8n Datensicherung self-hosted. Dieser Schlüssel verschlüsselt alle Credentials. Einmal gesetzt, darf er sich nie ändern – eine Änderung macht alle gesicherten Credentials unbrauchbar.

Deshalb gilt: Den Key einmal setzen, sofort in einem Passwort-Manager oder einem verschlüsselten Vault sichern – getrennt vom Server. Wenn du den Key verlierst, sind alle Credential-Backups wertlos, selbst wenn Workflows und Datenbank intakt sind. Das ist der häufigste Grund, warum Restores scheitern, obwohl ein Backup vorhanden ist.

Trage den Key als Umgebungsvariable in deine docker-compose.yml ein und sichere diese Datei ebenfalls in deinem Offsite-Backup.

Backup-Strategien für n8n vor Updates testen und wiederherstellen

Ein Backup, das nie getestet wurde, ist kein Backup. Daher gehört der Restore-Test fest zur n8n self-hosted Backup-Strategie – besonders vor jedem größeren Update.

1. Stoppe den n8n-Container: docker compose down
2. Stelle das Datenverzeichnis aus dem Backup wieder her – entweder per restic restore latest --target /srv/docker/n8ndata oder per Dateikopie.
3. Importiere bei Postgres den Dump: psql -U n8n n8n < /backup/n8n/n8n-DATUM.sql
4. Starte den Container neu: docker compose up -d
5. Prüfe in der n8n-Oberfläche, ob Workflows, Credentials und Einstellungen vollständig vorhanden sind.

Führe diesen Test mindestens einmal im Quartal durch – und immer vor einem Major-Update.

Restore-Prozess Schritt für Schritt

In der Praxis sieht ein erfolgreicher Restore so aus: Du stoppst den Container, stellst /srv/docker/n8ndata aus dem restic-Snapshot wieder her, importierst den pg_dump und startest neu. Bei korrektem N8N_ENCRYPTION_KEY sind danach alle Credentials sofort nutzbar. Der gesamte Prozess dauert bei einer typischen Instanz unter 10 Minuten.

Wichtig: Teste den Restore auf einer zweiten Instanz oder einer Staging-Umgebung – nicht direkt auf dem Produktionssystem. So vermeidest du, ein funktionierendes System durch einen fehlerhaften Restore zu beschädigen.

Upgrade-Sicherheit: Version pinnen statt latest

Ein weiterer kritischer Punkt bei der n8n Datensicherung: Verwende niemals das latest-Image für Produktionsinstanzen. Pinne stattdessen eine konkrete Version wie n8nio/n8n:1.71.0 in deiner docker-compose.yml.

Bevor du auf eine neue Version wechselst, legst du einen Snapshot an – entweder per restic, ZFS oder als VM-Snapshot. Damit ist ein Rollback in unter 5 Minuten möglich, falls das Update Probleme verursacht. Wer seinen gesamten Stack sauber aufgesetzt hat, findet im n8n Docker-Setup Guide von Contabo eine gute Referenz für das Versions-Pinning im Compose-File.

Häufige Fragen

Was muss ich bei einer selbst gehosteten n8n-Instanz alles sichern?

Du musst vier Bereiche sichern: alle Workflows (JSON-Exporte), alle Credentials (verschlüsselt), die Datenbank (SQLite-Datei oder Postgres-Dump) und den N8N_ENCRYPTION_KEY. Wer einen dieser Bereiche auslässt, hat kein vollständiges Backup. Besonders der Encryption Key wird häufig vergessen – ohne ihn sind Credential-Backups wertlos.

Was ist die 3-2-1-Regel und wie wende ich sie auf n8n an?

Die 3-2-1-Regel besagt: 3 Kopien deiner Daten, auf 2 verschiedenen Medien, davon 1 Kopie offsite. Für n8n bedeutet das: ein lokales Backup auf dem Host, ein zweites per restic in Object Storage und ein drittes auf einem separaten Anbieter oder einer NAS an einem anderen Standort. Die empfohlene Retention liegt bei 7 bis 30 Tagen.

Wie sichere ich den N8N_ENCRYPTION_KEY und warum ist das so wichtig?

Trage den N8N_ENCRYPTION_KEY als Umgebungsvariable in deine docker-compose.yml ein und sichere ihn sofort in einem Passwort-Manager oder verschlüsselten Vault – getrennt vom Server. Der Key darf sich nie ändern, da eine Änderung alle gesicherten Credentials unbrauchbar macht. Ohne diesen Key ist ein Restore der Credentials unmöglich, selbst wenn alle anderen Daten vorhanden sind.

Wie automatisiere ich Postgres-Backups für n8n mit pg_dump und Cron?

Trage folgenden Cron-Eintrag ein: 0 2 * * * docker exec n8n-postgres pg_dump -U n8n n8n > /backup/n8n/n8n-$(date +%F).sql. Damit läuft täglich um 2 Uhr ein automatischer Dump. Bewahre die Dumps 7 bis 30 Tage auf und lösche ältere Dateien automatisch. Kombiniere das mit restic, damit die Dumps auch offsite gesichert werden.

Wie stelle ich n8n-Workflows und Credentials aus einem Backup wieder her?

Stoppe den Container, stelle das Verzeichnis /srv/docker/n8ndata aus dem Backup wieder her und importiere bei Postgres den Dump per psql. Starte danach den Container neu und prüfe in der Oberfläche, ob Workflows, Credentials und Einstellungen vollständig vorhanden sind. Der gesamte Prozess dauert bei korrektem N8N_ENCRYPTION_KEY unter 10 Minuten.

Warum verliere ich n8n-Workflows nach einem Docker-Update?

Der häufigste Grund ist ein anonymes Docker-Volume ohne Host-Pfad-Mapping. Anonyme Volumes erhalten bei jedem Redeploy eine neue ID – die alten Daten sind danach nicht mehr erreichbar. Die Lösung: Verwende das Host-Pfad-Mapping /srv/docker/n8ndata:/home/node/.n8n in deiner docker-compose.yml, damit die Daten auf dem Host liegen und über Updates hinweg erhalten bleiben.

Fazit: Backup ist kein Einmalprojekt

Solide n8n self-hosted Backup-Strategien bestehen aus vier Bausteinen: richtige Volume-Konfiguration, automatisierte Datenbank-Dumps, Dateisystem-Backups mit restic oder borgbackup und gesicherte CLI-Exporte. Dazu kommt der N8N_ENCRYPTION_KEY – der am häufigsten vergessene Teil. Wer außerdem Versionen pinnt statt latest zu verwenden, schläft vor jedem Update ruhiger. Schnacken is Silber, Liefern is Gold: Ein Backup-Konzept, das du heute einrichtest und morgen testest, ist mehr wert als zehn Artikel, die du liest und nicht umsetzt.