Nous sommes confrontés à un problème de disparition de workflow n8n le 15/7/2026 à 15h30 IST
Décrivez le problème/erreur/question
Nous sommes confrontés à un problème de disparition de workflow n8n le 15/7/2026 à 15h30 IST
nous devons trouver la cause racine du problème. Pourquoi le workflow n8n disparaît. Après restauration de la base de données, tout semble bon
Quel est le message d’erreur (le cas échéant)?
Veuillez partager votre workflow
(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le workflow.)
Partagez la sortie renvoyée par le dernier nœud
Informations sur votre configuration n8n
- version de n8n:
- Base de données (par défaut: SQLite):
- paramètre EXECUTIONS_PROCESS de n8n (par défaut: own, main):
- Exécution de n8n via (Docker, npm, n8n cloud, application de bureau):
- Système d’exploitation:
Salut @Raghavendra908 Bienvenue !
Sur un n8n auto-hébergé, ce genre de disparition massive n’est presque jamais n8n qui supprime les workflows, c’est la base de données qui revient à un état antérieur. En supposant le SQLite par défaut, le déclencheur habituel est un redémarrage de conteneur, une recréation, ou une migration d’hôte/VPS autour de ce moment où le fichier WAL SQLite (database.sqlite-wal) n’a pas été contrôlé ou n’a pas été conservé avec la base de données principale, donc tout ce qui a été écrit depuis le dernier contrôle est parti. Cela correspond à votre timestamp 3h30 PM IST et à la restauration de la base de données qui ramène tout.
Pour confirmer la cause racine, vérifiez les logs du conteneur n8n et de l’hôte autour du 15/7 3h30 PM IST pour un redémarrage, un kill OOM, ou des erreurs SQLite, et vérifiez que database.sqlite, database.sqlite-wal, et database.sqlite-shm se trouvent tous sur le même volume persistant. L’écart dans la colonne updatedAt de la table workflow_entity s’alignera avec le dernier bon contrôle.
Pour la production, passez de SQLite à Postgres et exécutez de vrais sauvegardes au niveau du serveur (pg_dump sur une cron), puisque SQLite est sujet à exactement cela lors des redémarrages et migrations.
Le diagnostic d’Anshul est parfait, et il vaut la peine de le souligner pour quiconque découvrirait ce fil plus tard : ce mode de défaillance (SQLite annulant silencieusement les modifications et revenant à un point de contrôle antérieur après un redémarrage/OOM/migration d’hôte) est structurel à l’exécution de n8n sur sa base de données par défaut, ce n’est pas quelque chose que vous avez mal configuré. Le fichier WAL et le fichier .sqlite principal doivent survivre ensemble sur exactement le même volume avec un point de contrôle propre, et un redémarrage/redéploiement de conteneur est précisément le moment où les choses sont les plus susceptibles de mal tourner.
Passer à Postgres est la bonne solution. Une mise en garde qui vaut la peine de connaître avant de le faire, puisqu’elle piège les gens presque aussi souvent que la migration de base de données elle-même : N8N_ENCRYPTION_KEY doit être verrouillé et ne jamais être régénéré entre les déploiements. S’il change (facile à faire par accident si vous ne le persistez pas explicitement), chaque identifiant stocké devient silencieusement illisible - vous corrigez donc le problème de perte de données et vous frappez immédiatement un problème « pourquoi n8n ne peut-il plus déchiffrer mes identifiants » à la place.
Divulgation complète puisque je mentionne une façon spécifique de le faire : je maintiens un modèle Railway en un clic qui configure déjà cela (n8n sur Postgres 17 sur son propre volume, clé de chiffrement verrouillée via un secret généré pour qu’elle ne tourne jamais dessous vous, données binaires écrites sur Postgres au lieu du disque local du conteneur) - une commission s’applique si vous déployez via celui-ci : Deploy & Host n8n with Postgres | Railway . Si vous créez votre propre docker-compose à la place, le point de verrouillage de la clé de chiffrement ci-dessus est la seule chose qui vaut la peine d’être bien faite, quel que soit l’endroit où vous l’hébergez.