Salut les gars, j’avais cet abonnement Hetzner où j’auto-hébergeais mon n8n mais j’ai eu des problèmes pour le payer. Malheureusement, Hetzner a résilié mon abonnement et j’ai perdu toutes mes automations n8n (elles sont seulement sur mon ordinateur). Je veux savoir si je peux suspendre ou exclure ces données parce que, bien sûr, je veux récupérer mes automations avec toutes mes variables d’environnement, mes APIs et toutes mes données que j’utilise déjà, et je ne veux pas de conflits.
Décrivez le problème/l’erreur/la question
J’avais cet abonnement Hetzner où j’auto-hébergeais mon n8n mais j’ai eu des problèmes pour le payer. Malheureusement, Hetzner a résilié mon abonnement et j’ai perdu toutes mes automations n8n (elles sont seulement sur mon ordinateur). Je veux savoir si je peux suspendre ou exclure ces données parce que, bien sûr, je veux récupérer mes automations avec toutes mes variables d’environnement, mes APIs et toutes mes données que j’utilise déjà, et je ne veux pas de conflits.
Quel est le message d’erreur (le cas échéant) ?
Veuillez partager votre flux de travail
(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 flux de travail.)
Pour éviter les conflits lors de la restauration de vos automations, commencez par extraire toute configuration restante de votre machine locale (par exemple, le répertoire n8n/, docker-compose.yml, et le fichier .env qui contient les clés API, les URL de base et autres secrets). Si vous disposez d’une sauvegarde récente de la base de données n8n (SQLite, PostgreSQL ou MongoDB) ou de workflows JSON exportés (/home/user/.n8n/workflows/), conservez ces fichiers en sécurité ; ils contiennent les paramètres de nœud exacts, les déclencheurs et les identifiants que vous avez utilisés. Ensuite, sur un nouveau droplet Hetzner (ou tout autre hébergeur), montez les mêmes chemins de volume ou réutilisez les mêmes valeurs .env, et importez le workflow JSON via l’interface utilisateur n8n (Settings → Import) ou la CLI (n8n import:workflows). Cette approche vous permet de « suspendre » la perte de données en conservant une copie locale, et elle garantit que les automations restaurées utiliseront les mêmes variables d’environnement et secrets API sans incohérences.
Pour éviter que les annulations futures ne suppriment votre travail, effectuez des sauvegardes régulières. Cela vous évitera beaucoup de problèmes.
Rien ne fonctionne plus. Depuis qu’Hetzner a annulé le serveur, votre instance n8n auto-hébergée a disparu et tous les workflows sont déjà arrêtés. Il n’y a plus rien à mettre en pause sur l’ancien serveur.
Salut @jonkalyt Bienvenue !
Avant de commencer un remplacement, confirmez avec Hetzner si l’ancien serveur a été supprimé ou seulement suspendu. S’il existe toujours, gardez-le éteint pour que les deux copies ne puissent pas s’exécuter ensemble plus tard.
Les fichiers JSON de workflow contiennent les noms et identifiants des identifiants sauvegardés, non les clés API ou mots de passe sauvegardés. Ils ne sauvegardent pas non plus vos variables d’environnement. La restauration des identifiants chiffrés nécessite la sauvegarde de la base de données ou une exportation d’identifiants séparée, plus la clé de chiffrement d’origine. Si vous n’avez que le JSON de workflow, vous devrez recréer les identifiants et les paramètres d’environnement.
Quand vous dites que les automatisations sont sur votre ordinateur, voulez-vous dire des fichiers JSON de workflow téléchargés, ou une sauvegarde du dossier de données n8n / de la base de données du serveur ? Cela détermine ce que vous pouvez récupérer.
Hé @jonkalyt, une chose qu’il vaut la peine de chercher avant de tout reconstruire. Si tu n’as jamais défini N8N_ENCRYPTION_KEY toi-même, n8n en a généré une au premier lancement et l’a sauvegardée dans le dossier ~/.n8n. Sans ce fichier, les identifiants chiffrés dans une sauvegarde de base de données ne peuvent pas du tout être déchiffrés, c’est donc la première chose à chercher dans tout ce que tu as copié de ce serveur.
Désolé d’apprendre les problèmes de serveur ! La bonne nouvelle, c’est que puisque votre serveur Hetzner est annulé et hors ligne, vos workflows sont déjà effectivement « en pause » car l’instance n’est plus en cours d’exécution pour les exécuter.
Quand vous serez prêt à mettre en place un nouvel environnement autohébergé, vous ne devriez pas rencontrer de conflits si vous gérez la restauration avec soin :
1. Si vous importez à partir de fichiers JSON locaux : Quand vous importez des fichiers de workflow de votre ordinateur dans une nouvelle instance n8n, ils sont importés comme inactifs (en pause) par défaut. Vous pouvez importer tous les fichiers en toute sécurité, prendre votre temps pour configurer vos variables d’environnement et reconnecter vos identifiants API, puis activer manuellement les workflows un par un quand vous êtes prêt.
2. Si vous restaurez une sauvegarde complète de la base de données : Si vous avez une sauvegarde de base de données (comme un dump SQLite) et votre N8N_ENCRYPTION_KEY, les workflows seront restaurés dans l’état actif/inactif dans lequel ils se trouvaient quand le serveur s’est arrêté. Pour éviter qu’ils déclenchent des actions immédiatement au démarrage, vous pouvez utiliser la commande CLI de n8n juste après le démarrage de votre nouvelle instance pour tout mettre en pause : n8n update:workflow --all --active=false
Pour l’instant, gardez simplement ces fichiers locaux en sécurité. Vous pourrez tout migrer en douceur quand vous configurerez votre nouvel hôte.
Merci mec !! Ouais, je vais seulement importer des fichiers JSON locaux, donc finalement j’aurai besoin d’une sauvegarde complète de la base de données et d’une n8n_encryption_key pour cette nouvelle instance, c’est ça ? Bon à savoir, je suis nouveau dans tout ça, mais je vais certainement faire attention à cela dans mon prochain travail. Merci !
La clé de chiffrement n’a d’importance que pour les identifiants stockés dans une base de données, et le JSON de workflow n’en contient aucun. Les workflows exportés incluent les noms et IDs des identifiants, jamais les secrets eux-mêmes, donc il n’y a rien dans ces fichiers en attente de déchiffrement. Importez-les dans la nouvelle instance, entrez chaque identifiant une seule fois manuellement, et sélectionnez-le sur le nœud.
Cela vaut la peine de le faire sur la nouvelle instance cependant : définissez vous-même N8N_ENCRYPTION_KEY dans votre fichier compose au lieu de laisser n8n en générer un dans \~/.n8n. Sauvegardez-le aux côtés d’une sauvegarde de base de données et la prochaine fois une restauration restaurera réellement.