Migration von n8n zu Traefik 3.3 und Postgres 16: technischer Leitfaden

Sichere n8n-Migration: Upgrade von Traefik auf 3.3 und Postgres auf 16 ohne Datenverlust

Die Migration von n8n von veralteten Versionen von Traefik und Postgres zu einem modernen Stack erfordert die Behebung kritischer Kompatibilitätsprobleme. Dieser Artikel bietet eine technische Anleitung zum Erhalt von Daten und Anmeldeinformationen beim Upgrade von Traefik 1.x und Postgres 11 auf die neuesten Versionen.

Vorbereitung: Backup und Verschlüsselungsschlüssel

Der entscheidende Schritt der Migration ist der ordnungsgemäße Export der Daten und die Sicherung des Verschlüsselungsschlüssels. Ohne diesen werden die Anmeldeinformationen nach dem Transfer unzugänglich. Für n8n ist das entscheidend: Das System verwendet symmetrische Verschlüsselung, um Tokens und Passwörter zu speichern.

Führen Sie diese beiden obligatorischen Aktionen durch:

• Erstellen Sie ein Datenbank-Dump im custom-Format für eine ordnungsgemäße Wiederherstellung:

docker exec -t postgres_db pg_dump -U root -d n8n -Fc > /tmp/n8n_backup.dump
docker cp postgres_db:/tmp/n8n_backup.dump ./n8n_backup.dump

• Extrahieren Sie den aktuellen Verschlüsselungsschlüssel aus der Konfiguration. Die Quelle kann an zwei Stellen sein:

- Variable N8N_ENCRYPTION_KEY in docker-compose.yml

- Parameter encryptionKey in Datei ~/.n8n/config

Das Ignorieren dieses Schritts führt zu einem Needs first setup-Fehler nach dem Start. Das System erkennt die Datenbank, kann aber die gespeicherten Anmeldeinformationen nicht entschlüsseln.

Bereitstellung des Stacks: Fallstricke bei Traefik 3.3

Beim Bereitstellen von Traefik 3.3 tritt ein kritisches Inkompatibilitätsproblem mit der Docker API auf. Der Router verwendet standardmäßig eine veraltete API-Version (1.24), während moderne Docker-Daemons Version 1.41 oder höher erfordern. Dies führt zu 404-Fehlern beim Versuch, Container zu entdecken.

Lösung — erzwingen Sie die API-Version in Umgebungsvariablen:

environment:
  - DOCKER_API_VERSION=1.41

Diese Änderung ermöglicht es Traefik, korrekt mit dem Docker Engine zu interagieren. Ohne sie kann der Router die n8n- und Postgres-Container nicht sehen, was die automatische Routenkonfiguration über den Docker Provider unmöglich macht.

Beachten Sie die Netzwerkisolierung: Alle Dienste müssen im selben benutzerdefinierten Netzwerk (n8n_net) sein. Dies gewährleistet stabile Interaktion zwischen den Containern ohne Routing-Konflikte. Beispiel für eine korrekte Konfiguration:

networks:
  n8n_net:
    name: n8n_net

services:
  traefik:
    networks:
      - n8n_net
  n8n:
    networks:
      - n8n_net
  postgres_db:
    networks:
      - n8n_net

Wiederherstellung der Datenbank in Postgres 16: Behebung von Berechtigungsproblemen

Postgres 16 führt Änderungen in der Standard-Sicherheitspolicy ein. Das public-Schema hat nun eingeschränkte Berechtigungen, was zu einem permission denied for schema public-Fehler beim Start von n8n führt.

Nach der Wiederherstellung des Dumps ausführen:

docker cp n8n_backup.dump postgres_db:/tmp/
docker exec -i postgres_db pg_restore -U root -d n8n -1 /tmp/n8n_backup.dump

Dann dem Datenbankbesitzer volle Berechtigungen auf das Schema erteilen:

docker exec -it postgres_db psql -U root -d n8n -c "GRANT ALL ON SCHEMA public TO root;"

Dies ist notwendig, da n8n das public-Schema aktiv zur Speicherung von Metadaten verwendet. Das Überspringen dieses Schritts verursacht wiederholte Abstürze des n8n-Containers.

Behebung der Anmeldeinformationen: Vermeidung des „Needs first setup“-Fehlers

Auch wenn N8N_ENCRYPTION_KEY korrekt über Umgebungsvariablen übergeben wird, ignoriert n8n es möglicherweise. Der Grund ist ein Konflikt zwischen der Umgebungsvariable und der lokalen Konfigurationsdatei. Beim ersten Start generiert das System eine neue ~/.n8n/config-Datei, die den Schlüssel aus den Variablen überschreibt.

Lösung:

• Löschen Sie die Konfigurationsdatei im Container:

docker exec -it n8n rm /home/node/.n8n/config

• Starten Sie den Dienst neu:

docker compose restart n8n

Dies zwingt n8n, den Schlüssel aus den Umgebungsvariablen anstelle der lokalen Datei zu verwenden. Stellen Sie sicher, dass die ursprüngliche N8N_ENCRYPTION_KEY-Variable in docker-compose.yml angegeben ist.

Zusätzliche Nuancen: Hintergrundprozesse und SQLite

Während der Migration können Probleme mit Hintergrundaufgaben auftreten, die SQLite verwenden (z. B. Telegram-Parser basierend auf Telethon). Nach dem Transfer sehen Sie sqlite3.OperationalError: database is locked.

Ursache — verbleibende Journaling-Dateien (.session-journal, .session-wal), die die Datenbank sperren. Lösung:

• Installieren Sie das psmisc-Hilfsprogramm:

apt install psmisc -y

• Erzwingen Sie das Beenden der Prozesse, die die Sperre halten:

fuser -k -v /root/parser_folder/session_name.session

• Löschen Sie temporäre Dateien:

rm -f /root/parser_folder/session_name.session-journal
rm -f /root/parser_folder/session_name.session-wal

• Starten Sie den Dienst neu:

systemctl restart service_name.service

Wichtig: Das Löschen der Journals beeinflusst die Hauptsitzungsdatei nicht. Die Telegram-Autorisierung bleibt erhalten.

Wichtige Punkte

• Verschlüsselungsschlüssel ist obligatorisch — ohne den ursprünglichen N8N_ENCRYPTION_KEY werden alle Anmeldeinformationen unzugänglich.
• Traefik erfordert explizite API-Spezifikation — der Parameter DOCKER_API_VERSION=1.41 ist entscheidend für die Container-Erkennung.
• Postgres 16 schränkt Berechtigungen ein — manuell GRANT ALL ON SCHEMA public ausführen.
• Lokale n8n-Konfigurationskonflikte — Löschen von ~/.n8n/config behebt das Verschlüsselungsschlüssel-Problem.
• SQLite-Sperren erfordern Bereinigung — Entfernen der .journal- und .wal-Dateien stellt Hintergrundprozesse wieder her.

Nach Abschluss aller Schritte startet n8n mit allen Workflows, Webhooks und Anmeldeinformationen erhalten. Migrationen zwischen Hauptsoftwareversionen bergen immer Risiken, aber das Befolgen dieser Verfahren minimiert Ausfallzeiten und Datenverlust.

— Editorial Team