Sie haben n8n auf Ihrem VPS mit Docker Compose und PostgreSQL eingerichtet. Das war Tag eins. Tag zwei bedeutet: am Laufen halten mit automatisierten Backups, getesteten Wiederherstellungen und sicheren Updates.

Dieser Leitfaden behandelt alles, was Sie brauchen, um eine n8n-Produktionsinstanz zu schützen. Wir erstellen ein Backup-Skript, automatisieren es mit cron, kopieren Backups vom Server weg, führen eine Disaster Recovery auf einem frischen VPS durch und aktualisieren n8n sicher mit Rollback-Unterstützung. Wir behandeln auch den Migrationspfad von 1.x auf 2.x.

Dieser Leitfaden setzt voraus, dass Sie unsere n8n-Docker-Compose-Installationsanleitung befolgt haben. Ihr Stack läuft mit Docker Compose und PostgreSQL, einem Nicht-Root-Deploy-Benutzer und einem Reverse Proxy.

Welche Daten speichert n8n und warum müssen Sie diese sichern?

n8n speichert fünf Komponenten, die Sie zusammen sichern müssen. Fehlt auch nur eine davon, kann die Wiederherstellung unvollständig oder unmöglich sein. Die PostgreSQL-Datenbank enthält Ihre Workflows, Credentials (verschlüsselt), den Ausführungsverlauf und Benutzerkonten. Der Verschlüsselungsschlüssel (Encryption Key) entschlüsselt diese Credentials. Das Docker-Volume speichert benutzerdefinierte Nodes und Binärdaten. Ihre .env- und docker-compose.yml-Dateien definieren die Laufzeitkonfiguration.

Komponente	Inhalt	Risiko bei Verlust	Backup-Methode
PostgreSQL-Datenbank	Workflows, verschlüsselte Credentials, Ausführungsverlauf, Benutzer	Alle Daten verloren	`pg_dump` (Custom-Format)
`N8N_ENCRYPTION_KEY`	AES-256-Schlüssel zur Credential-Entschlüsselung	Alle gespeicherten Credentials werden dauerhaft unwiederbringlich	Kopie aus `.env` oder Container-Konfiguration
Docker-Volume (`.n8n`)	Benutzerdefinierte Nodes, binäre Ausführungsdaten	Benutzerdefinierte Nodes und Datei-Uploads verloren	Alpine-tar-Container
`.env`-Datei	Datenbankpasswörter, Verschlüsselungsschlüssel, Domain-Konfiguration	Muss manuell neu erstellt werden	Dateikopie
`docker-compose.yml`	Service-Definitionen, Volume-Mappings, Image-Tags	Muss manuell neu erstellt werden	Dateikopie

Wie sichern Sie die n8n-PostgreSQL-Datenbank mit pg_dump?

Verwenden Sie pg_dump mit --format=custom, um einen komprimierten, wiederherstellbaren Dump der n8n-Datenbank zu erstellen. Das Custom-Format unterstützt selektive Wiederherstellung und parallele Verarbeitung. Führen Sie den Dump über den laufenden PostgreSQL-Container aus.

docker exec n8n-postgres \
  pg_dump -U n8n -d n8n --format=custom \
  > /home/deploy/n8n-backups/n8n-db-$(date +%Y%m%d-%H%M%S).dump

Was dieser Befehl macht: docker exec führt pg_dump innerhalb des PostgreSQL-Containers aus. -U n8n ist der Datenbankbenutzer. -d n8n ist der Datenbankname. --format=custom erzeugt einen komprimierten Binär-Dump, den pg_restore selektiv wiederherstellen kann. Die Ausgabe wird in eine Datei mit Zeitstempel auf dem Host umgeleitet.

Überprüfen Sie, ob der Dump gültig ist:

cat /home/deploy/n8n-backups/n8n-db-*.dump | docker exec -i n8n-postgres pg_restore --list | head -20

Da pg_restore sich im PostgreSQL-Container befindet, wird der Dump über eine Pipe an docker exec -i übergeben. Sie sollten eine Liste von Datenbankobjekten sehen (Tabellen, Sequenzen, Daten). Wenn Sie einen Fehler oder eine leere Ausgabe sehen, ist der Dump fehlgeschlagen.

Docker-Volume sichern

Das n8n-Daten-Volume enthält benutzerdefinierte Nodes und binäre Ausführungsdaten. Sichern Sie es mit einem temporären Alpine-Container:

docker run --rm \
  -v n8n_n8n_data:/source:ro \
  -v /home/deploy/n8n-backups:/backup \
  alpine tar czf "/backup/n8n-data-$(date +%Y%m%d-%H%M%S).tar.gz" -C /source .

Der Volume-Name n8n_n8n_data setzt sich aus dem Docker-Compose-Projektnamen (n8n, vom Verzeichnis) und dem Volume-Namen (n8n_data, aus docker-compose.yml) zusammen. Führen Sie docker volume ls aus, wenn Ihrer abweicht.

Was dieser Befehl macht: Hängt das n8n-Daten-Volume schreibgeschützt (:ro) in einen Einweg-Alpine-Container ein. Der Container erstellt ein komprimiertes Archiv des Volume-Inhalts und schreibt es in das Backup-Verzeichnis. Der Container wird nach Abschluss entfernt (--rm).

Überprüfen Sie das Archiv:

tar tzf /home/deploy/n8n-backups/n8n-data-*.tar.gz | head -10

Sie sollten Dateipfade aus dem .n8n-Verzeichnis sehen.

Konfigurationsdateien sichern

BACKUP_DIR="/home/deploy/n8n-backups"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
cp /home/deploy/n8n/.env "$BACKUP_DIR/env-$TIMESTAMP.bak"
cp /home/deploy/n8n/docker-compose.yml "$BACKUP_DIR/docker-compose-$TIMESTAMP.yml.bak"
chmod 600 "$BACKUP_DIR/env-$TIMESTAMP.bak"

Die .env-Datei enthält Ihren N8N_ENCRYPTION_KEY und das Datenbankpasswort. Beschränken Sie die Berechtigungen auf 600, damit nur der Backup-Benutzer sie lesen kann.

Warum ist der n8n-Verschlüsselungsschlüssel das wichtigste Backup?

n8n verschlüsselt jedes gespeicherte Credential (API-Schlüssel, OAuth-Tokens, Datenbankpasswörter) mit AES-256 unter Verwendung des N8N_ENCRYPTION_KEY. Wenn Sie diesen Schlüssel verlieren, wird jedes Credential in Ihrer Datenbank dauerhaft unwiederbringlich. Es gibt keinen Reset-Mechanismus. Keine Hintertür. Sie müssten jedes Credential in jedem Workflow manuell neu eingeben.

Der Schlüssel wird entweder explizit in Ihrer .env-Datei gesetzt oder von n8n beim ersten Start automatisch generiert und im Container unter /home/node/.n8n/config gespeichert.

Finden Sie Ihren Verschlüsselungsschlüssel:

Wenn Sie ihn in .env gesetzt haben:

grep N8N_ENCRYPTION_KEY /home/deploy/n8n/.env

Wenn n8n ihn automatisch generiert hat (Sie haben ihn nie explizit gesetzt):

docker exec n8n cat /home/node/.n8n/config

Suchen Sie das Feld encryptionKey in der JSON-Ausgabe.

Schlüssel sicher aufbewahren:

Kopieren Sie den Schlüsselwert in einen Passwort-Manager (Bitwarden, KeePass, 1Password).
Stellen Sie sicher, dass er in Ihrer .env-Datei als N8N_ENCRYPTION_KEY=<Ihr-Schlüssel> vorhanden ist.
Ihr Backup-Skript kopiert bereits .env, aber bewahren Sie den Schlüssel auch separat auf. Wenn Ihr Server ausfällt und Ihre Backups beschädigt sind, können Sie die Credentials trotzdem wiederherstellen, solange Sie den Schlüssel haben.

Wie automatisieren Sie n8n-Backups mit cron?

Fassen Sie den Datenbank-Dump, das Volume-Backup und die Konfigurationskopie in einem Skript zusammen. Fügen Sie eine Aufbewahrungsbereinigung und einen Health-Check-Ping hinzu, um Fehler zu erkennen.

Erstellen Sie das Backup-Skript:

nano /home/deploy/n8n/backup-n8n.sh

#!/usr/bin/env bash
set -euo pipefail

# --- Configuration ---
BACKUP_DIR="/home/deploy/n8n-backups"
N8N_DIR="/home/deploy/n8n"
COMPOSE_PROJECT="n8n"
DB_CONTAINER="n8n-postgres"  # Matches container_name in docker-compose.yml
DB_USER="n8n"
DB_NAME="n8n"
VOLUME_NAME="${COMPOSE_PROJECT}_n8n_data"  # docker compose prefixes project name
RETENTION_DAYS=7
RETENTION_WEEKS=4
HEALTHCHECK_URL=""  # Set to your healthcheck.io or uptime-kuma URL

TIMESTAMP=$(date +%Y%m%d-%H%M%S)
DAY_OF_WEEK=$(date +%u)

mkdir -p "$BACKUP_DIR/daily" "$BACKUP_DIR/weekly"

# --- PostgreSQL dump ---
echo "[$(date)] Starting PostgreSQL backup..."
docker exec "$DB_CONTAINER" \
  pg_dump -U "$DB_USER" -d "$DB_NAME" --format=custom \
  > "$BACKUP_DIR/daily/n8n-db-$TIMESTAMP.dump"

# Verify dump is not empty
if [ ! -s "$BACKUP_DIR/daily/n8n-db-$TIMESTAMP.dump" ]; then
  echo "[$(date)] ERROR: Database dump is empty!" >&2
  exit 1
fi

# --- Docker volume backup ---
echo "[$(date)] Starting volume backup..."
docker run --rm \
  -v "${VOLUME_NAME}:/source:ro" \
  -v "$BACKUP_DIR/daily:/backup" \
  alpine tar czf "/backup/n8n-data-$TIMESTAMP.tar.gz" -C /source .

# --- Config files ---
echo "[$(date)] Backing up config files..."
cp "$N8N_DIR/.env" "$BACKUP_DIR/daily/env-$TIMESTAMP.bak"
cp "$N8N_DIR/docker-compose.yml" "$BACKUP_DIR/daily/docker-compose-$TIMESTAMP.yml.bak"
chmod 600 "$BACKUP_DIR/daily/env-$TIMESTAMP.bak"

# --- Weekly copy (Sundays) ---
if [ "$DAY_OF_WEEK" -eq 7 ]; then
  echo "[$(date)] Creating weekly backup copy..."
  cp "$BACKUP_DIR/daily/n8n-db-$TIMESTAMP.dump" "$BACKUP_DIR/weekly/"
  cp "$BACKUP_DIR/daily/n8n-data-$TIMESTAMP.tar.gz" "$BACKUP_DIR/weekly/"
  cp "$BACKUP_DIR/daily/env-$TIMESTAMP.bak" "$BACKUP_DIR/weekly/"
fi

# --- Retention cleanup ---
echo "[$(date)] Cleaning old backups..."
find "$BACKUP_DIR/daily" -type f -mtime +$RETENTION_DAYS -delete
find "$BACKUP_DIR/weekly" -type f -mtime +$((RETENTION_WEEKS * 7)) -delete

# --- Health check ping ---
if [ -n "$HEALTHCHECK_URL" ]; then
  curl -fsS --retry 3 "$HEALTHCHECK_URL" > /dev/null
fi

echo "[$(date)] Backup complete."

Setzen Sie die Berechtigungen und testen Sie:

chmod 750 /home/deploy/n8n/backup-n8n.sh

/home/deploy/n8n/backup-n8n.sh

Überprüfen Sie, ob die Backup-Dateien erstellt wurden:

ls -lh /home/deploy/n8n-backups/daily/

Achten Sie auf die Dateigrößen. Ein typischer n8n-Datenbank-Dump ist zwischen 500 KB und 50 MB groß, je nach Ausführungsverlauf. Wenn der Dump 0 Bytes hat, ist etwas schiefgelaufen.

Mit cron planen

crontab -e

Fügen Sie diese Zeile hinzu, um Backups täglich um 03:00 Uhr auszuführen:

0 3 * * * /home/deploy/n8n/backup-n8n.sh >> /home/deploy/n8n-backups/backup.log 2>&1

Was dieser Befehl macht: Führt das Backup-Skript jeden Tag um 3 Uhr morgens aus. Ausgaben und Fehler werden an backup.log angehängt, um Fehler nachvollziehen zu können.

Backup-Fehler-Benachrichtigung

Die Variable HEALTHCHECK_URL im Skript unterstützt Dienste wie Healthchecks.io oder eine selbst gehostete Uptime Kuma-Instanz. Diese Dienste erwarten einen Ping in regelmäßigen Abständen. Wenn der Ping ausbleibt (weil das Skript fehlgeschlagen ist oder der Cronjob nicht lief), erhalten Sie eine Benachrichtigung.

Richten Sie einen Check mit einem 24-Stunden-Intervall und einer Toleranz von einer Stunde ein. Wenn das Backup-Skript bis 04:00 Uhr keinen Ping sendet, werden Sie benachrichtigt.

Wie kopieren Sie n8n-Backups mit rclone vom Server weg?

Backups auf demselben Server wie n8n sind keine echten Backups. Wenn die Festplatte ausfällt, verlieren Sie beides. Verwenden Sie rclone, um Backups in S3-kompatiblen Objektspeicher zu kopieren (Wasabi, Backblaze B2, MinIO oder ein beliebiger S3-Anbieter).

Installieren Sie rclone:

sudo apt install rclone

Konfigurieren Sie ein Remote. Dieses Beispiel verwendet einen beliebigen S3-kompatiblen Speicher:

rclone config

Folgen Sie den interaktiven Eingabeaufforderungen, um ein Remote namens n8n-backup zu erstellen. Wählen Sie „Amazon S3 Compliant Storage Providers" und geben Sie Ihren Endpoint, Zugriffsschlüssel und geheimen Schlüssel ein.

Überprüfen Sie, ob das Remote funktioniert:

rclone lsd n8n-backup:

Sie sollten Ihren Bucket in der Liste sehen.

Fügen Sie die Synchronisation zu Ihrem Backup-Skript hinzu. Fügen Sie dies vor der Health-Check-Ping-Zeile ein:

# --- Off-server copy ---
echo "[$(date)] Syncing to remote storage..."
rclone sync "$BACKUP_DIR" n8n-backup:your-bucket-name/n8n \
  --transfers 4 \
  --min-age 1m \
  --log-level ERROR

--min-age 1m verhindert das Hochladen von Dateien, die noch geschrieben werden. --transfers 4 führt vier parallele Uploads aus.

Wie überprüfen Sie, ob n8n-Backups gültig sind?

Ein Backup, das Sie nie getestet haben, ist ein Backup, das Sie nicht haben. Führen Sie diese Prüfungen regelmäßig durch.

Datenbank-Dump-Integrität:

cat /home/deploy/n8n-backups/daily/n8n-db-*.dump | docker exec -i n8n-postgres pg_restore --list > /dev/null 2>&1 && echo "OK" || echo "CORRUPT"

Volume-Archiv-Integrität:

tar tzf /home/deploy/n8n-backups/daily/n8n-data-*.tar.gz > /dev/null 2>&1 && echo "OK" || echo "CORRUPT"

Prüfsummen für Remote-Verifizierung:

Generieren Sie Prüfsummen nach dem Backup:

sha256sum /home/deploy/n8n-backups/daily/* > /home/deploy/n8n-backups/daily/checksums.sha256

Nach dem Herunterladen vom Remote-Speicher überprüfen Sie:

sha256sum -c checksums.sha256

Jede Zeile sollte OK anzeigen. Jede Abweichung bedeutet, dass die Datei während der Übertragung beschädigt wurde.

Wie stellen Sie n8n aus einem Backup auf einem frischen VPS wieder her?

Dies ist die Disaster-Recovery-Prozedur. Sie haben Ihren Server verloren. Sie haben einen frischen VPS und Ihre Backup-Dateien (aus dem Remote-Speicher oder einer lokalen Kopie). So bringen Sie n8n wieder zum Laufen.

1. Neuen VPS bereitstellen und Docker installieren

Richten Sie einen VPS mit Docker und Docker Compose ein. Folgen Sie unserer n8n-Docker-Compose-Installationsanleitung bis zum Docker-Installationsschritt und kommen Sie dann hierher zurück.

2. Deploy-Benutzer und Projektverzeichnis erstellen

adduser --disabled-password deploy
mkdir -p /home/deploy/n8n /home/deploy/n8n-backups
chown deploy:deploy /home/deploy/n8n /home/deploy/n8n-backups

3. Backups herunterladen

Aus Ihrem Remote-Speicher:

su - deploy
rclone copy n8n-backup:your-bucket-name/n8n/daily /home/deploy/n8n-backups/daily --progress

Oder von einem anderen Server per scp:

scp user@old-server:/home/deploy/n8n-backups/daily/* /home/deploy/n8n-backups/daily/

4. Konfigurationsdateien wiederherstellen

cp /home/deploy/n8n-backups/daily/env-*.bak /home/deploy/n8n/.env
cp /home/deploy/n8n-backups/daily/docker-compose-*.yml.bak /home/deploy/n8n/docker-compose.yml
chmod 600 /home/deploy/n8n/.env

Überprüfen Sie, ob der Verschlüsselungsschlüssel vorhanden ist:

grep N8N_ENCRYPTION_KEY /home/deploy/n8n/.env

Dieser Befehl muss eine Zeile mit Ihrem Schlüssel zurückgeben. Wenn die Ausgabe leer ist oder fehlt, holen Sie den Schlüssel aus Ihrem Passwort-Manager und fügen Sie ihn manuell hinzu. Ohne diesen Schlüssel sind Ihre Credentials verloren.

5. Nur PostgreSQL starten

cd /home/deploy/n8n
docker compose up -d postgres

Warten Sie, bis PostgreSQL initialisiert ist:

docker compose logs -f postgres

Suchen Sie nach database system is ready to accept connections.

6. Datenbank wiederherstellen

docker cp /home/deploy/n8n-backups/daily/n8n-db-*.dump n8n-postgres:/tmp/n8n.dump
docker exec n8n-postgres pg_restore -U n8n -d n8n --clean --if-exists /tmp/n8n.dump

Was dieser Befehl macht: Kopiert die Dump-Datei in den Container. Dann lädt pg_restore sie. --clean entfernt bestehende Objekte vor der Wiederherstellung. --if-exists verhindert Fehler, wenn Objekte noch nicht existieren.

Sie werden möglicherweise Warnungen über nicht existierende Objekte sehen. Das ist bei einer frischen Datenbank normal. Fehler bei Daten oder Constraints sind nicht normal.

7. Docker-Volume wiederherstellen

Docker Compose hat das Volume n8n_n8n_data bereits erstellt, als Sie PostgreSQL im vorherigen Schritt gestartet haben. Stellen Sie es wieder her:

docker run --rm \
  -v n8n_n8n_data:/target \
  -v /home/deploy/n8n-backups/daily:/backup:ro \
  alpine sh -c "tar xzf /backup/n8n-data-*.tar.gz -C /target"

8. Vollständigen Stack starten

docker compose up -d

9. Wiederherstellung überprüfen

docker compose ps

Alle Container sollten den Status running anzeigen.

Prüfen Sie die n8n-Logs:

docker compose logs -f n8n

Suchen Sie nach Editor is now accessible via: http://localhost:5678. Keine Verschlüsselungsschlüssel-Fehler.

Öffnen Sie die n8n-Weboberfläche und überprüfen Sie:

Workflows existieren und stimmen mit dem überein, was Sie vorher hatten.
Credentials funktionieren. Öffnen Sie ein beliebiges Credential und bestätigen Sie, dass die gespeicherten Werte angezeigt werden (API-Schlüssel, Passwörter). Wenn Sie leere Felder oder Entschlüsselungsfehler sehen, ist Ihr Verschlüsselungsschlüssel falsch.
Führen Sie einen Test-Workflow aus. Starten Sie einen einfachen Workflow, um die Datenbankverbindung und die Ausführungs-Engine zu bestätigen.

Testen Sie von außerhalb des Servers:

curl -s https://your-n8n-domain.com/healthz

Eine 200-Antwort bestätigt, dass n8n erreichbar ist und läuft.

Wie aktualisieren Sie n8n sicher mit Docker Compose?

Das Aktualisieren von n8n folgt vier Schritten: sichern, Release Notes prüfen, neues Image pullen und verifizieren. Überspringen Sie nie den Backup-Schritt.

1. Backup erstellen

/home/deploy/n8n/backup-n8n.sh

Das ist Pflicht. Wenn das Update etwas kaputt macht, brauchen Sie einen Wiederherstellungspunkt.

2. Release Notes auf Breaking Changes prüfen

Bevor Sie die neue Version pullen, lesen Sie die n8n Release Notes. Achten Sie auf:

Datenbankmigrationen (diese laufen automatisch beim Start, können aber Zeit brauchen)
Veraltete Nodes, die Ihre Workflows verwenden
Geänderte Umgebungsvariablen
Mindestanforderungen an die PostgreSQL-Version

3. Aktuelle Version notieren

docker compose exec n8n n8n --version

Notieren Sie sich diese. Sie brauchen sie für den Rollback.

4. Pullen und neu starten

Wenn Ihre docker-compose.yml den Tag n8nio/n8n:latest oder n8nio/n8n:stable verwendet:

cd /home/deploy/n8n
docker compose pull
docker compose down
docker compose up -d

Wenn Sie eine bestimmte Version pinnen (empfohlen für Produktion), bearbeiten Sie zuerst die docker-compose.yml:

services:
  n8n:
    image: n8nio/n8n:2.12.3  # Change to the target version

Dann:

docker compose up -d

5. Update überprüfen

docker compose exec n8n n8n --version

Bestätigen Sie, dass die Version Ihren Erwartungen entspricht.

Prüfen Sie die Logs auf Migrationsfehler:

docker compose logs --tail 50 n8n

Suchen Sie nach Migrations completed und Editor is now accessible via: http://localhost:5678.

Testen Sie den API-Health-Endpoint:

curl -s https://your-n8n-domain.com/healthz

Führen Sie einen Test-Workflow über die Oberfläche aus, um zu bestätigen, dass die Ausführung funktioniert.

Wie machen Sie ein Rollback nach einem fehlgeschlagenen n8n-Update?

Wenn das Update Workflows kaputt macht oder die Oberfläche nicht erreichbar ist, gehen Sie zur vorherigen Version zurück.

1. Fehlerhafte Instanz stoppen

cd /home/deploy/n8n
docker compose down

2. Vorherigen Image-Tag setzen

Bearbeiten Sie docker-compose.yml und ändern Sie das Image auf Ihre vorherige Version:

services:
  n8n:
    image: n8nio/n8n:2.11.2  # Your previous working version

3. Datenbank wiederherstellen, falls Migrationen gelaufen sind

Wenn n8n während des fehlgeschlagenen Updates Datenbankmigrationen durchgeführt hat, hat sich das Schema möglicherweise geändert. Stellen Sie aus Ihrem Pre-Update-Backup wieder her:

docker compose up -d postgres
docker cp /home/deploy/n8n-backups/daily/n8n-db-*.dump n8n-postgres:/tmp/n8n.dump
docker exec n8n-postgres pg_restore -U n8n -d n8n --clean --if-exists /tmp/n8n.dump

4. Alte Version starten

docker compose up -d

Überprüfen Sie:

docker compose exec n8n n8n --version
docker compose logs --tail 20 n8n

Deshalb sichern wir vor jedem Update. Ohne den Pre-Update-Dump können Sie nach einer Migration nicht sicher downgraden.

Wie migrieren Sie n8n von Version 1.x auf 2.x?

n8n 2.0 wurde im Dezember 2025 mit Breaking Changes veröffentlicht. Wenn Sie noch auf 1.x sind, migrieren Sie bald. Version 1.x erhielt nur drei Monate nach dem 2.0-Release Sicherheitsfixes, und dieses Zeitfenster ist jetzt geschlossen.

Wichtige Breaking Changes in n8n 2.0

Änderung	1.x-Verhalten	2.x-Verhalten	Erforderliche Aktion
MySQL/MariaDB-Unterstützung	Unterstützt	Vollständig entfernt	Vor dem Upgrade auf PostgreSQL migrieren
Task Runners	Optional	Standardmäßig aktiviert, separates Docker-Image	`n8nio/runners`-Image für externen Modus verwenden
Env-Variablen im Code-Node	Zugänglich	Standardmäßig blockiert	`N8N_BLOCK_ENV_ACCESS_IN_NODE=false` setzen, falls nötig
Start-Node	Funktionsfähig	Entfernt	Durch spezifische Trigger-Nodes ersetzen
Save vs. Publish	Save = Deploy	Save und Publish sind getrennte Aktionen	Team-Workflows anpassen
Python-Code-Node	Pyodide-basiert	Natives Python über Task Runners	Task Runners im externen Modus verwenden
`ExecuteCommand`- und `LocalFileTrigger`-Nodes	Aktiviert	Standardmäßig deaktiviert	Bei Bedarf explizit aktivieren
CLI-Option `--tunnel`	Verfügbar	Entfernt	Stattdessen einen Reverse Proxy verwenden
`N8N_CONFIG_FILES`	Unterstützt	Entfernt	Umgebungsvariablen direkt verwenden

Schritt 1: Migrationsbericht ausführen

Das Migrationsberichts-Tool ist ab n8n 1.121.0 verfügbar. Es identifiziert Probleme auf Workflow- und Instanz-Ebene vor dem Upgrade.

Gehen Sie in der n8n-Oberfläche zu Settings > Migration Report. Dies ist nur für globale Administratoren sichtbar.

Der Bericht hat zwei Tabs:

Workflow Issues: Listet Workflows auf, die veraltete Nodes, entfernte Features oder geänderte Verhaltensweisen verwenden.
Instance Issues: Zeigt Umgebungsvariablen und Konfigurationen an, die aktualisiert werden müssen.

Beheben Sie jedes vom Bericht identifizierte Problem, bevor Sie fortfahren.

Schritt 2: Zuerst auf die neueste 1.x-Version aktualisieren

Bevor Sie auf 2.x springen, aktualisieren Sie auf die neueste 1.x-Version. Dies stellt sicher, dass alle Zwischendatenbank-Migrationen ausgeführt werden:

docker compose pull  # With image set to n8nio/n8n:1-latest or latest 1.x tag
docker compose down && docker compose up -d

Schritt 3: Alles sichern

/home/deploy/n8n/backup-n8n.sh

Das ist Ihr Rollback-Punkt. Wenn 2.x Ihr Setup kaputt macht, können Sie dieses Backup wiederherstellen und auf 1.x bleiben.

Schritt 4: Auf 2.x aktualisieren

Bearbeiten Sie docker-compose.yml:

services:
  n8n:
    image: n8nio/n8n:stable  # Or a specific 2.x version like 2.12.3

docker compose pull
docker compose down
docker compose up -d

Schritt 5: Migration überprüfen

docker compose logs --tail 100 n8n

Suchen Sie nach abgeschlossenen Migrationen und fehlenden Fehlern.

Testen Sie Workflows, die der Migrationsbericht markiert hat. Öffnen Sie Credentials, um zu bestätigen, dass die Entschlüsselung funktioniert. Führen Sie einige Workflows end-to-end aus.

Wenn etwas kaputt ist, führen Sie ein Rollback mit der Prozedur aus dem vorherigen Abschnitt durch, unter Verwendung Ihres 1.x-Backups und des 1.x-Image-Tags.

Fehlerbehebung

pg_dump: error: connection to server failed Der PostgreSQL-Container läuft nicht. Starten Sie ihn mit docker compose up -d postgres und warten Sie, bis er bereit ist, bevor Sie Backups ausführen.

Credentials erscheinen nach der Wiederherstellung leer Ihr N8N_ENCRYPTION_KEY stimmt nicht mit dem überein, der beim Speichern der Credentials verwendet wurde. Prüfen Sie Ihre .env-Datei. Vergleichen Sie mit dem Schlüssel in Ihrem Passwort-Manager.

docker exec schlägt mit „no such container" fehl Container-Namen hängen von Ihrem Projektverzeichnisnamen und der Compose-Datei ab. Führen Sie docker ps aus, um den tatsächlichen Container-Namen zu finden. Passen Sie die Variable DB_CONTAINER im Backup-Skript an.

Backup-Skript läuft, aber der Healthcheck pingt nie Prüfen Sie, ob HEALTHCHECK_URL im Skript gesetzt ist. Testen Sie die URL manuell: curl -fsS "your-healthcheck-url". Firewall-Regeln blockieren möglicherweise ausgehende HTTPS-Verbindungen.

n8n startet nach dem Update nicht mit Migrationsfehler Prüfen Sie die Logs mit docker compose logs n8n. Wenn der Fehler eine bestimmte Migration nennt, suchen Sie im n8n Community Forum nach diesem Fehler. Führen Sie bei Bedarf ein Rollback durch.

rclone sync schlägt mit Authentifizierungsfehler fehl Führen Sie rclone config reconnect n8n-backup: aus, um die Anmeldedaten zu erneuern. Überprüfen Sie, ob Ihr Zugriffsschlüssel und Ihr Geheimschlüssel korrekt sind.

Wo sich die Logs befinden:

# n8n application logs
docker compose logs -f n8n

# PostgreSQL logs
docker compose logs -f postgres

# Backup script log
tail -f /home/deploy/n8n-backups/backup.log

# Cron execution log
grep CRON /var/log/syslog | tail -20