Une sauvegarde n8n utile ne se limite pas à copier un dossier. Il faut couvrir les workflows, les credentials chiffrés, la base de données, la clé de chiffrement, les fichiers binaires éventuels et la version de n8n. Le point critique : une sauvegarde qui s’exporte bien mais ne se restaure pas ne vaut presque rien.
Repère documentaire : documentation officielle du fonctionnement présenté.
Exporter workflows et credentials
La CLI serveur n8n permet d’exporter workflows et credentials depuis la machine où n8n est installé. Dans un déploiement Docker, la CLI peut ne pas exister sur l’hôte : il faut l’exécuter dans le conteneur ou dans une image compatible montée sur les mêmes volumes et variables d’environnement.
# Exemple documentaire à adapter au nom du conteneur
mkdir -p backup-n8n/workflows backup-n8n/credentials
docker exec n8n n8n export:workflow --all --output=/tmp/workflows.json
docker cp n8n:/tmp/workflows.json backup-n8n/workflows/workflows.json
docker exec n8n n8n export:credentials --all --output=/tmp/credentials.json
docker cp n8n:/tmp/credentials.json backup-n8n/credentials/credentials.encrypted.jsonÉvitez d’exporter les credentials déchiffrés sauf besoin exceptionnel et coffre-fort prêt. Les credentials chiffrés restent dépendants de la clé de chiffrement n8n. Cette clé doit être sauvegardée séparément, hors du même zip exposé, sinon la restauration sera impossible ou la fuite plus grave.
Base de données : cohérence avant copie
Copier un fichier SQLite actif avec cp peut produire une sauvegarde incohérente. Utilisez une méthode cohérente : arrêt contrôlé, snapshot cohérent incluant les journaux SQLite, commande SQLite .backup, dump PostgreSQL si n8n utilise Postgres, ou procédure de backup du fournisseur managé. Notez le moteur exact : SQLite, PostgreSQL, version, variables importantes et image n8n.
# SQLite documentaire, à lancer dans un contexte où sqlite3 voit le fichier
sqlite3 database.sqlite ".backup 'backup-n8n/database.sqlite'"
# PostgreSQL documentaire
pg_dump --format=custom --file=backup-n8n/n8n.dump "$DATABASE_URL"Ne pas oublier les fichiers binaires
Si n8n stocke des binary data en filesystem, S3 ou autre mode externe, inventoriez ce stockage. Les workflows peuvent référencer des fichiers ou exécutions dont le contenu n’est pas dans l’export JSON. Notez le mode configuré, le bucket, le chemin local ou le volume Docker. Sans cela, la restauration peut relancer les workflows mais perdre des pièces jointes.
Manifest, checksums et version
Ajoutez un manifest simple : date, version n8n, mode d’installation, image Docker ou digest si disponible, type de DB, liste des fichiers, taille et checksum. Exemple :
sha256sum backup-n8n/workflows/workflows.json backup-n8n/credentials/credentials.encrypted.json backup-n8n/database.sqlite > backup-n8n/SHA256SUMS.txt
docker exec n8n n8n --version > backup-n8n/N8N_VERSION.txtNe mettez pas la clé de chiffrement dans le même dossier si ce dossier part vers un stockage partagé. Stockez-la dans un gestionnaire de secrets ou un coffre séparé avec une procédure d’accès.
Restauration : éviter les relances actives
Restaurez d’abord dans une instance arrêtée ou isolée. Restaurez la base et la clé correspondante avant de démarrer. Un dump complet contient déjà workflows et credentials : ne les réimportez pas systématiquement par-dessus. Les exports séparés servent surtout à une récupération sélective. Une restauration complète peut conserver des workflows actifs. Bloquez les accès réseau sortants et entrants de la copie avant son premier démarrage, puis désactivez les workflows. Changer uniquement le port ne bloque ni les planifications ni les appels sortants. Une importation de workflows par la CLI les désactive par défaut selon la documentation actuelle ; ce comportement ne doit pas être supposé pour une restauration intégrale de base. Ensuite seulement, démarrez, vérifiez les credentials, testez un workflow non destructif, puis réactivez progressivement.
La sauvegarde minimale acceptable : export workflows, export credentials chiffrés, backup DB cohérent, clé séparée, binary data inventoriées, version notée et test de restauration documenté. Sans test de restauration, vous avez une intention de backup, pas une garantie.
Cas Docker Compose
Dans Compose, documentez le fichier docker-compose.yml, les variables N8N_ENCRYPTION_KEY, la configuration DB et les volumes. Sauvegarder seulement les exports JSON ne suffit pas si l’instance dépend d’un volume contenant la base SQLite, des fichiers binaires ou des paramètres locaux. Un restore doit pouvoir recréer le même service sans deviner les noms de volumes.
Test de restauration réaliste
Le test doit se faire sur une instance isolée : port différent, domaine interne ou réseau fermé. Importez, démarrez, ouvrez l’interface, vérifiez que les credentials sont lisibles, puis exécutez un workflow de test qui ne contacte pas de vrais clients. Notez chaque échec : variable manquante, credential illisible, nœud communautaire absent, version incompatible.
Ce qu’il ne faut pas faire
Ne restaurez pas directement par-dessus la production sans snapshot. Ne démarrez pas une copie avec les workflows actifs si elle peut recevoir les mêmes webhooks. Ne stockez pas exports, clé de chiffrement et dump DB dans un dossier public. La sauvegarde doit réduire le risque, pas créer une deuxième surface d’incident.
Fréquence et rétention
Adaptez la fréquence au rythme de changement. Une instance qui change tous les jours mérite un backup quotidien court plus un hebdomadaire conservé plus longtemps. Une instance rarement modifiée peut se contenter d’un backup après chaque changement important. Gardez plusieurs versions : si une erreur logique est sauvegardée immédiatement, le dernier backup seul ne permet pas de revenir avant l’incident.
Ajoutez une alerte simple : taille anormalement petite, checksum absent, export vide ou commande en échec. Une sauvegarde silencieuse qui échoue pendant trois mois est un classique. Le manifest doit donc être contrôlé, pas seulement écrit.
Restaurer sans surprise de credentials
Après import, ouvrez quelques credentials critiques sans les modifier et lancez un nœud de test contrôlé. Si la clé de chiffrement ne correspond pas, les credentials peuvent être illisibles même si les workflows sont présents. C’est le test qui révèle la cohérence entre export, base et clé.
Pour les bases : définition d’une API REST.
