Eine Automatisierung, die monatelang zuverlässig Rechnungen verbucht und Anfragen verteilt, sammelt mit der Zeit echten Wert an: ausgefeilte Workflows, sauber hinterlegte Zugänge, eingespielte Abläufe. Genau dieser Wert steht auf einer einzigen Festplatte, wenn niemand an ein Backup gedacht hat. In diesem Artikel zeige ich, was bei einer selbst betriebenen Automatisierung wirklich gesichert sein muss, warum die Datenbank allein nicht reicht – und wie Sie sich überzeugen, dass Ihre Sicherung im Ernstfall auch zurückläuft.
Was bei einem Ausfall verloren geht – und wie er passiert
Bei einer selbst gehosteten Automatisierungsplattform wie n8n liegt fast alles in einer Datenbank: die Workflows mit ihrer kompletten Logik, die verschlüsselten Zugangsdaten zu allen angebundenen Systemen und die Ausführungshistorie. Geht diese Datenbank verloren, ist nicht eine Datei weg, sondern der gesamte Maschinenraum Ihrer Abläufe.
Und Datenverlust ist kein exotischer Sonderfall. Eine Festplatte stirbt, ein Server wird neu aufgesetzt, jemand löscht versehentlich den falschen Workflow, ein größeres Update bricht die Instanz (warum das passiert, steht in Wartung von Automatisierungen), oder Verschlüsselungs-Trojaner sperren das ganze System. Die Frage ist nicht, ob einer dieser Fälle eintritt, sondern wann – und ob Sie dann eine Sicherung haben, die diesen Namen verdient.
Drei Dinge gehören ins Backup, nicht nur die Datenbank
Der häufigste Fehler ist, nur die Datenbank zu sichern. Eine vollständige Sicherung besteht aus drei Teilen, die nur zusammen einen Wiederanlauf erlauben:
| Was gesichert werden muss | Womit |
|---|---|
| Workflows | n8n export:workflow --backup oder Datenbank-Sicherung |
| Zugangsdaten (verschlüsselt) | n8n export:credentials --backup oder Datenbank-Sicherung |
| Verschlüsselungs-Schlüssel | N8N_ENCRYPTION_KEY getrennt im Passwort-Manager |
| Konfiguration und Umgebung | .env, docker-compose.yml, eigene Nodes |
Die ersten beiden Zeilen sind der eigentliche Inhalt. Die dritte – der Schlüssel – ist der unscheinbare Teil, an dem die meisten unvollständigen Backups scheitern; dazu gleich mehr. Die vierte stellt sicher, dass Sie die Umgebung überhaupt wieder in den gleichen Zustand bringen: dieselben Umgebungsvariablen, dieselbe Version, dieselben selbst gebauten Bausteine.
Workflows und Zugänge mit n8n sichern
Für die Sicherung gibt es zwei Wege, die sich gut ergänzen.
Der Export über die Kommandozeile
n8n bringt dafür eigene Befehle mit. Laut Dokumentation schreibt n8n export:workflow --backup alle Workflows als einzelne Dateien weg – der Schalter --backup setzt intern --all --pretty --separate. Das Gegenstück n8n export:credentials --backup sichert die Zugangsdaten, und zwar standardmäßig verschlüsselt. Eine Datei pro Workflow zu erzeugen hat einen angenehmen Nebeneffekt: Legen Sie das Verzeichnis unter Versionskontrolle (Git), bekommen Sie eine nachvollziehbare Historie jeder Änderung gratis dazu.
Einen Schalter sollten Sie mit Vorsicht behandeln: --decrypted exportiert die Zugangsdaten im Klartext. Die Dokumentation warnt unmissverständlich, dass dann „alle sensiblen Informationen in den Dateien sichtbar“ sind. Solche Dateien sind hochbrisant – nutzen Sie den Schalter nur, wenn Sie ihn wirklich brauchen, und bewahren Sie das Ergebnis so sicher auf wie das Passwort zu Ihrem Bankkonto.
Die Datenbank selbst sichern
Der zweite Weg sichert die Datenbank direkt. n8n nutzt von Haus aus SQLite – eine einzelne Datei (database.sqlite) im Datenverzeichnis, üblicherweise ~/.n8n. Diese Datei lässt sich kopieren, am saubersten bei kurz gestopptem Dienst. Für den produktiven Betrieb empfiehlt n8n PostgreSQL; dort übernimmt das Standardwerkzeug pg_dump die konsistente Sicherung im laufenden Betrieb. Die oft umfangreiche Ausführungshistorie bleibt beim Export übrigens außen vor – sie ist für den Wiederanlauf nicht nötig und kann sehr groß werden.
In der Praxis ist die Kombination am robustesten: ein regelmäßiger Datenbank-Dump für den vollständigen Zustand plus ein Workflow-Export in Git für die saubere Änderungshistorie.
Der Schlüssel entscheidet über den Wiederanlauf
Jetzt zum Teil, der über Erfolg oder Totalverlust entscheidet. n8n verschlüsselt die gespeicherten Zugangsdaten mit einem Schlüssel, den es beim ersten Start erzeugt oder den Sie über N8N_ENCRYPTION_KEY selbst setzen. Dieser Schlüssel steckt nicht in der Datenbank.
Ein Backup einer Automatisierung besteht aus drei Teilen: den Workflows, den verschlüsselten Zugangsdaten und dem Schlüssel, der sie entschlüsselt. Fehlt der Schlüssel, ist die sauberste Datenbanksicherung wertlos – die Zugänge bleiben für immer unlesbar. Bewahren Sie ihn deshalb getrennt von der Datenbank auf, und prüfen Sie regelmäßig, ob sich aus Ihren Sicherungen tatsächlich eine lauffähige Instanz herstellen lässt.
Das ist keine Theorie, sondern steht so in der Dokumentation: Wer gesicherte Zugangsdaten in eine neue Instanz einspielt, dessen Zielsystem „muss denselben Verschlüsselungs-Schlüssel konfiguriert haben wie das Quellsystem“. Setzen Sie beim Wiederanlauf also zuerst den alten Schlüssel, bevor Sie irgendetwas importieren – sonst spielen Sie eine Datenbank voller unbrauchbarer Geheimnisse zurück. Wie Sie diesen Schlüssel im Alltag schützen und wo Sie ihn ablegen, habe ich in Automatisierungen absichern ausführlicher beschrieben.
Drei Kopien, zwei Orte, ein Test
Eine Sicherung, die auf demselben Server liegt wie das Original, hilft gegen einen versehentlich gelöschten Workflow – aber nicht gegen einen Festplattendefekt oder Verschlüsselungs-Trojaner, die beide zugleich mitnehmen. Deshalb die bewährte Faustregel der Datensicherung: drei Kopien, auf zwei verschiedenen Medien, davon eine an einem anderen Ort. Auch das Bundesamt für Sicherheit in der Informationstechnik rät in seinen Empfehlungen zur Datensicherung ausdrücklich dazu, Sicherungen räumlich getrennt aufzubewahren.
Konkret heißt das für eine kleine Automatisierung: ein automatischer Dump auf dem Server, eine Kopie in einem getrennten Speicher (etwa Objektspeicher bei einem Cloud-Anbieter) und der Verschlüsselungs-Schlüssel im Passwort-Manager. Wichtig ist, dass die Sicherung wirklich automatisch läuft – ein Backup, an das man jeden Freitag denken muss, ist über kurz oder lang kein Backup mehr. Legen Sie außerdem fest, wie viele Stände Sie aufbewahren, damit Sie auch auf einen Zustand von vor einer Woche zurück können, falls ein Fehler erst spät auffällt.
Der am häufigsten übersprungene Schritt ist der wichtigste: Spielen Sie die Sicherung einmal testweise zurück. Eine Sicherung, die nie wiederhergestellt wurde, ist eine Hoffnung, kein Plan. Der Test dafür ist überschaubar: eine frische Instanz aufsetzen, denselben Verschlüsselungs-Schlüssel setzen, Zugangsdaten und Workflows importieren – und dann gegen die echten Systeme prüfen, ob die Zugänge entschlüsselt werden und ein Workflow tatsächlich durchläuft. Dieselbe Disziplin, die ich in Automatisierung testen, bevor sie live geht für neue Workflows beschrieben habe, gilt fürs Backup: Was Sie nicht geprüft haben, funktioniert im Ernstfall erfahrungsgemäß nicht.
Was das für Ihren Betrieb heißt
Backup und Wiederanlauf sind kein Großprojekt, sondern eine einmalige Einrichtung plus ein vierteljährlicher Test. Der Aufwand steht in keinem Verhältnis zum Schaden, den ein Totalverlust anrichtet: Workflows, die über Monate gewachsen sind, lassen sich nicht in einer Stunde nachbauen, und die Zugänge zu einem Dutzend Systemen neu einzurichten kostet Tage. Wer Automatisierung als laufenden Betrieb versteht und nicht als einmaliges Bastelprojekt, plant die Sicherung von Anfang an mit ein.
Wenn Sie wissen wollen, wie robust Ihre Automatisierung gegen einen Ausfall aufgestellt ist – oder ob es überhaupt eine Sicherung gibt –, schauen wir uns das im kostenlosen Prozess-Check gemeinsam an. Ich sage Ihnen ehrlich, wo Sie gut abgesichert sind und wo ein einzelner Defekt teuer werden könnte.