Sauvegarder et mettre à jour un n8n auto-hébergé : ce que font vraiment les exports

Sauvegarder et mettre à jour un n8n auto-hébergé : ce que font vraiment les exports

Les commandes --backup de n8n exportent des workflows et des identifiants. Ce n'est pas une sauvegarde de l'instance.

La réponse courte. D'après la documentation officielle de n8n consultée le 7 novembre 2026, n8n export:workflow --backup et n8n export:credentials --backup produisent un fichier JSON par workflow et par identifiant, rien d'autre. Les utilisateurs, l'historique d'exécution, les variables et la clé de chiffrement n'y sont pas. Une sauvegarde complète, c'est le dossier .n8n (le volume n8n_data sous Docker), plus la base PostgreSQL si vous l'utilisez, plus la configuration de déploiement. Sans la clé de chiffrement, les identifiants restaurés ne sont pas déchiffrables.

Cet article suit la documentation de n8n, de Docker et de PostgreSQL, dit ce qui y est écrit, et signale ce que nous n'avons pas exécuté nous-mêmes.

Transparence. BOVO Digital est une agence basée au Bénin et utilise n8n. Cet article ne repose sur aucune donnée, aucun client et aucun prix de BOVO Digital : uniquement sur les pages publiques citées en bas, relues le 7 novembre 2026. Aucune des commandes ci-dessous n'a été exécutée par nous pour cet article : elles sont recopiées ou adaptées de la documentation. Testez-les d'abord sur une instance jetable, pas sur votre production.

Ce que font les deux commandes --backup

La page des commandes CLI de n8n (consultée le 7 novembre 2026) décrit le drapeau : --backup « sets --all --pretty --separate ». Autrement dit : tous les éléments, en JSON lisible, un fichier par élément. On peut préciser le dossier avec --output.

n8n export:workflow --backup --output=backups/workflows/
n8n export:credentials --backup --output=backups/credentials/

La page Back up and restore (consultée le 7 novembre 2026) apporte trois précisions.

• Un dossier de sortie par commande. import:credentials --separate échoue actuellement si le dossier contient aussi des fichiers de workflows. La documentation renvoie à un problème connu dans le dépôt GitHub de n8n.
• Sous Docker, un dossier backups/ créé dans le conteneur n'est pas conservé. Seul le dossier .n8n est dans un volume. Il faut monter un dossier de l'hôte, ou copier les fichiers hors du conteneur avant de le recréer.
• Ce que l'export ne contient pas : les utilisateurs et leurs rôles, l'historique des exécutions et les journaux, les variables, les paramètres de l'instance, dont la clé de chiffrement.

La conséquence pratique est dite en toutes lettres dans la documentation : un export CLI suffit pour déplacer des workflows entre instances, pas pour récupérer une instance entière. Après un import sur une instance neuve, l'écran de création du propriétaire réapparaît, et la première personne qui le remplit devient propriétaire.

À l'import, les identifiants d'origine sont conservés : un élément de même ID sur l'instance cible est écrasé. Les workflows importés sont désactivés par défaut.

Ce que contient le volume n8n_data

Dans l'exemple Docker Compose de n8n (consulté le 7 novembre 2026), le volume n8n_data est monté sur /home/node/.n8n et sert à enregistrer « its SQLite database file and encryption key » : le fichier de base SQLite et la clé de chiffrement. L'exemple monte aussi un volume pour Traefik (certificats TLS) et un dossier local-files, qui ne font pas partie de ce qu'il faut sauvegarder pour n8n lui-même.

La page de sauvegarde détaille le dossier .n8n (~/.n8n par défaut) :

• le fichier config, qui stocke la clé de chiffrement des identifiants ;
• avec SQLite, le fichier de base lui-même : utilisateurs, paramètres, exécutions, workflows, identifiants chiffrés ;
• les données binaires et d'exécution, si elles sont en mode de stockage filesystem.

Si vous utilisez du stockage externe (S3, Azure Blob Storage), un chemin personnalisé, ou des nœuds personnalisés chargés via N8N_CUSTOM_EXTENSIONS, la documentation demande de les sauvegarder aussi.

Pourquoi la clé de chiffrement compte

La page Set a custom encryption key (consultée le 7 novembre 2026) explique que n8n génère une clé aléatoire au premier lancement, l'enregistre dans le dossier ~/.n8n, et s'en sert pour chiffrer les identifiants avant de les écrire dans la base. On peut imposer sa propre clé avec la variable d'environnement N8N_ENCRYPTION_KEY, si elle n'est pas déjà dans le fichier de paramètres.

La page de sauvegarde en tire la conséquence : sans la clé du fichier config, ou sans une N8N_ENCRYPTION_KEY personnalisée, « a restored database or encrypted credential export can't be decrypted » (une base restaurée ou un export d'identifiants chiffré ne peut pas être déchiffré). Nous en déduisons qu'une base sauvegardée sans sa clé conserve vos workflows mais perd l'usage de vos identifiants : il faudrait les ressaisir un par un. La documentation ne décrit aucun moyen de retrouver une clé perdue.

Deux issues sont documentées pour restaurer des identifiants sur une autre instance :

1. utiliser la même clé : restaurer le fichier config dans .n8n, ou définir la même N8N_ENCRYPTION_KEY ;
2. exporter avec --decrypted, qui écrit les identifiants en clair.

n8n export:credentials --all --decrypted --output=backups/decrypted.json

La documentation avertit que ce fichier contient toutes les données des identifiants en clair : à garder avec le même soin que les identifiants eux-mêmes, et à supprimer une fois la restauration terminée.

Ce que nous recommandons, sans que ce soit écrit tel quel dans la doc : définir N8N_ENCRYPTION_KEY vous-même dès l'installation, et conserver une copie de la valeur dans un gestionnaire de mots de passe, séparée des sauvegardes de données. Une sauvegarde qui contient à la fois la base et la clé donne accès à tous les identifiants à quiconque la détient.

SQLite ou PostgreSQL : ce que cela change pour la sauvegarde

La page Choose n8n's database (consultée le 7 novembre 2026) indique que les installations auto-hébergées utilisent SQLite par défaut, et que PostgreSQL se configure avec des variables d'environnement, dont DB_TYPE=postgresdb. Au 7 novembre 2026, la page cite les versions 17 et 18 de PostgreSQL comme prises en charge, plus la 16 « pour compatibilité », et précise que cette plage change chaque année. Relisez-la avant de choisir une version.

Pour PostgreSQL, la documentation de n8n demande de la sauvegarder avec les outils propres à la base de données. La documentation de PostgreSQL (consultée le 7 novembre 2026) décrit pg_dump, qui produit un fichier de commandes SQL, et précise que ses sauvegardes sont cohérentes (un instantané de la base au début de l'exécution) sans bloquer les autres opérations. La restauration d'un fichier texte se fait avec psql, dans une base créée au préalable.

pg_dump nom_de_la_base > sauvegarde.sql

Nous n'avons pas relu la page de référence complète de pg_dump ni testé de dump contre une instance n8n : consultez-la pour les options de connexion et de format.

Sur le choix lui-même, la documentation lue ne donne aucun seuil (nombre de workflows, d'exécutions) au-delà duquel SQLite deviendrait déconseillé. Nous ne pouvons donc pas vous en donner un.

Une sauvegarde complète, étape par étape

Avec Docker Compose et SQLite, d'après la page de sauvegarde de n8n.

1. Arrêter n8n. La documentation demande d'arrêter n8n avant de copier le dossier .n8n quand la base est SQLite, car copier le fichier pendant qu'il est écrit peut donner une copie incohérente. La documentation de n8n donne docker compose stop pour arrêter les conteneurs.
2. Copier le contenu du volume n8n_data. La documentation de n8n ne donne pas de commande pour cela. Docker décrit, dans Back up, restore, or migrate data volumes, un modèle : lancer un conteneur temporaire qui monte le volume du conteneur concerné avec --volumes-from, monte un dossier de l'hôte, et fabrique une archive tar. Adaptation à n8n, non exécutée par nous :

docker run --rm --volumes-from NOM_DU_CONTENEUR_N8N -v "$(pwd)":/backup ubuntu \
  tar cvf /backup/n8n_data.tar /home/node/.n8n

NOM_DU_CONTENEUR_N8N est un nom à remplacer : vérifiez-le avec docker ps -a. Le chemin /home/node/.n8n est celui du montage indiqué par n8n. 3. Sauvegarder la base PostgreSQL, si vous l'utilisez (voir plus haut). 4. Sauvegarder la configuration de déploiement : le fichier compose.yaml, le fichier .env, les variables de connexion à la base, N8N_ENCRYPTION_KEY si vous la définissez, et les réglages de stockage externe. La documentation précise que sans elles, une instance restaurée ne peut ni joindre sa base ni déchiffrer ses données. 5. Exporter aussi les workflows en JSON (export:workflow --backup). Ce n'est pas indispensable à une restauration complète, mais c'est un filet de sécurité lisible et versionnable. 6. Copier le tout hors du serveur. Une sauvegarde qui ne vit que sur la machine qu'elle protège ne protège pas d'une panne de cette machine. 7. Redémarrer n8n avec docker compose up -d.

Mettre à jour avec Docker Compose

La page Install with Docker (consultée le 7 novembre 2026) donne la procédure, depuis le dossier qui contient le fichier Compose :

cd </chemin/vers/le/dossier/compose>
docker compose pull
docker compose down
docker compose up -d

La page Update n8n ajoute des conseils : mettre à jour souvent pour éviter les sauts de plusieurs versions (au moins une fois par mois), lire les notes de version pour les changements incompatibles, tester d'abord sur une instance de test, et, selon la page de sauvegarde, faire une sauvegarde complète avant.

Deux points de vigilance.

• down sans -v. Selon la documentation de Docker (consultée le 7 novembre 2026), docker compose down retire par défaut les conteneurs et les réseaux ; l'option -v (--volumes) retire aussi les volumes nommés déclarés dans le fichier Compose. n8n_data est un volume nommé de ce type. N'ajoutez pas -v à la procédure de mise à jour.
• Version de l'image. La page Docker de n8n montre comment tirer la version « stable » ou une version précise (n8nio/n8n:<version>). L'exemple Compose de n8n utilise l'image n8nio/n8n sans numéro de version. Fixer une version précise est un choix de notre part, pas une exigence de la documentation : cela permet de revenir à la version précédente avec une sauvegarde, mais cela demande de changer le numéro à chaque mise à jour.

Tester la restauration

Une sauvegarde qu'on n'a jamais restaurée est une hypothèse. La documentation décrit deux cas.

Restauration complète (page de sauvegarde) : arrêter n8n ; restaurer le dossier .n8n à son emplacement d'origine, avec les dossiers de nœuds personnalisés ; restaurer la base PostgreSQL le cas échéant ; remettre la configuration de déploiement (variables de base, N8N_ENCRYPTION_KEY, stockage externe) ; démarrer n8n.

Restauration de workflows et d'identifiants : sur une instance neuve, terminer d'abord la création du propriétaire (les commandes d'import ont besoin d'un utilisateur existant), puis importer.

n8n import:workflow --separate --input=backups/workflows/
n8n import:credentials --separate --input=backups/credentials/

Si l'instance a plusieurs utilisateurs ou projets, --userId ou --projectId servent à attribuer les identifiants importés. Les workflows sont importés désactivés : il faut les réactiver dans l'interface.

Notre proposition de test, non décrite comme telle par n8n : restaurez sur une machine ou un serveur séparé, jamais sur la production, avec les mêmes variables de déploiement. Ouvrez un workflow qui utilise un identifiant et exécutez-le avec des données sans conséquence. Si l'identifiant fonctionne, la clé a bien suivi. Notez la durée totale : c'est votre délai de reprise réel.

Checklist

• N8N_ENCRYPTION_KEY définie par vous, copie conservée hors du serveur et hors des sauvegardes de données.
• Le dossier .n8n (volume n8n_data) sauvegardé, n8n arrêté pendant la copie si SQLite.
• Base PostgreSQL sauvegardée avec ses propres outils, si utilisée.
• compose.yaml, .env et variables de base sauvegardés.
• Stockage externe et dossiers de nœuds personnalisés inclus, s'ils existent.
• Export JSON des workflows en plus, dans un dossier distinct de celui des identifiants.
• Sauvegardes copiées hors de la machine.
• Notes de version lues avant chaque mise à jour.
• Mise à jour : pull, down (sans -v), up -d.
• Restauration testée sur une machine séparée, durée notée.
• Ce test refait après tout changement d'architecture.

Ce que cet article n'est pas

Ce n'est pas un guide d'exploitation complet. Nous n'avons exécuté aucune des commandes citées, et la documentation de n8n évolue : la page de sauvegarde signale déjà un problème connu sur l'import des identifiants. Relisez les pages avant d'agir sur une instance qui compte.

Ce que nous ne savons pas

• Les exigences minimales en processeur, mémoire et disque pour n8n : nous ne les avons trouvées dans aucune des pages lues. Nous n'avançons aucun chiffre.
• À partir de quel volume de données SQLite devient un mauvais choix : la documentation lue ne le dit pas.
• La commande exacte pour copier le volume n8n_data d'une installation donnée : celle ci-dessus est une adaptation du modèle de Docker, non testée par nous.
• Le comportement d'une restauration entre deux versions éloignées de n8n : les pages lues ne le traitent pas. Restaurer sur la même version que celle de la sauvegarde est la précaution la plus simple, mais ce n'est pas une règle écrite.
• La fréquence de sauvegarde adaptée à votre usage : la documentation n'en donne pas.
• Nous n'avons pas relu la page de référence complète de pg_dump, ni les pages de n8n sur la rotation des clés de chiffrement ou le mode file d'attente.

Pour aller plus loin

• n8n auto-hébergé : guide pour un VPS : ce que demande l'hébergement d'une instance.
• Self-host n8n avec Docker : un tutoriel d'installation Docker.
• n8n pour une agence : ce que la licence permet et interdit : l'hébergement et la licence.
• Choisir une agence n8n en 2026 : les questions à poser sur la propriété des workflows et des accès.

Sources consultées le 7 novembre 2026

• Back up and restore (docs.n8n.io)
• CLI commands for n8n (docs.n8n.io)
• Set a custom encryption key (docs.n8n.io)
• Docker Compose, installation serveur (docs.n8n.io)
• Install with Docker, section Updating (docs.n8n.io)
• Update n8n (docs.n8n.io)
• Choose n8n's database (docs.n8n.io)
• Back up, restore, or migrate data volumes (docs.docker.com)
• docker compose down (docs.docker.com)
• SQL Dump (postgresql.org)

Si vous voulez de l'aide pour installer, sauvegarder ou superviser une instance n8n : l'offre automatisation n8n de BOVO Digital.