Tout le monde sait qu’il faudrait sauvegarder. Presque personne ne le fait vraiment, et
ceux qui le font découvrent souvent, le jour où ils en ont besoin, que leur copie ne se
restaure pas. C’est un sujet où l’intention ne vaut rien : seule compte une restauration
qui fonctionne.
Cet article donne la méthode complète pour une instance
n8n auto-hébergée : ce qu’il
faut réellement copier, ce qui ne sert à rien, à quelle fréquence, où déposer les copies,
comment automatiser tout cela avec n8n lui-même, et surtout comment vérifier que ça marche
avant d’en avoir besoin. La dernière partie traite la migration vers un autre serveur, qui est
exactement la même opération vue sous un autre angle.
Ce que vous risquez vraiment de perdre
Avant de parler méthode, il faut mesurer l’enjeu, parce qu’il est presque toujours
sous-estimé. Ce qui disparaît avec une instance n8n perdue, ce ne sont pas « des
fichiers ». C’est un enchaînement de décisions que vous avez mis des mois à affiner.
Les automatisations elles-mêmes, d’abord : chaque condition, chaque délai, chaque
formulation de message a été ajustée à l’usage. Les reconstruire de mémoire donne quelque
chose qui ressemble, mais qui ne se comporte pas pareil — et vous mettrez des semaines à
retrouver les réglages fins.
Les identifiants ensuite. Chaque connexion à un service extérieur a demandé une
autorisation, parfois un aller-retour dans une console d’administration. Tout reconnecter à la
main, sur une trentaine d’automatisations, occupe une soirée entière — et il y en a toujours
deux ou trois dont plus personne ne se souvient comment elles avaient été mises en place.
L’historique enfin, qu’on croit accessoire jusqu’au jour où un client conteste quelque
chose. C’est lui qui permet de dire ce qui a été envoyé, à qui, et quand.
Le tout tient dans quelques dizaines de mégaoctets. C’est ce qui rend l’absence de
sauvegarde particulièrement absurde : le coût de la protection est ridicule au regard de
ce qu’elle protège.
Ce qu’il faut sauvegarder, et ce qui ne sert à rien
Bonne nouvelle : sur une installation en conteneur, tout ce qui compte tient dans un
seul endroit. Pas de fichiers dispersés, pas de base à exporter séparément.
Le volume de données contient les automatisations, les identifiants chiffrés, l’historique
des exécutions et la base elle-même si vous êtes resté sur la configuration par défaut.
Copiez ce dossier et vous avez copié votre installation.
Le fichier de configuration mérite d’être conservé avec, ailleurs que sur le serveur. Il ne
contient pas vos données, mais il décrit l’installation : quelle version, quels réglages,
quelle adresse publique. Avec lui et le volume, remonter une instance ailleurs prend le temps
de télécharger l’image.
En revanche, inutile de sauvegarder l’image de l’application : elle se retélécharge en
une commande. Inutile aussi de faire une copie complète du système d’exploitation à chaque
fois — c’est lourd, lent, et cela ne protège rien de plus que ce que couvrent déjà les deux
éléments ci-dessus.
Sauvegarder aussi ce qui n’est pas dans n8n
Voici l’angle mort de presque toutes les procédures. Le dossier de données couvre
l’application ; il ne couvre pas ce qui la rend joignable. Une restauration parfaite du
volume sur une machine neuve donne une instance qui fonctionne — et que personne ne peut
atteindre.
Quatre éléments vivent en dehors de n8n et méritent d’être notés quelque part, une fois
pour toutes.
La configuration du serveur mandataire. C’est elle qui gère le nom de
domaine et le certificat. Elle tient en quelques lignes, elle ne change jamais, et personne ne
la sauvegarde parce qu’elle est trop simple pour qu’on y pense. Le jour de la restauration,
c’est vingt minutes perdues à la réécrire de mémoire.
La zone du nom de domaine. L’enregistrement qui fait pointer votre
sous-domaine vers l’adresse du serveur. Vous devrez le modifier lors d’une migration :
sachez où il se règle et avec quels identifiants, avant d’en avoir besoin en urgence.
La liste des webhooks distribués. C’est le point le plus souvent oublié, et
le plus pénible à reconstituer. Chaque adresse que vous avez collée chez un prestataire — votre
boutique, votre formulaire, votre outil de facturation — devra être mise à jour si l’adresse
change. Tenez cette liste dans un simple tableau, avec le service concerné et l’endroit exact
où l’adresse a été renseignée. Cinq minutes aujourd’hui, une demi-journée économisée le jour
venu.
Les tâches programmées du système. Celle qui lance justement votre
sauvegarde, notamment. Une machine restaurée sans sa tâche de sauvegarde est une machine qui
n’est plus protégée — et rien ne vous le dira.
La clé de chiffrement : le point unique de défaillance
Voici le détail qui transforme une restauration réussie en échec, et il mérite sa propre
section parce qu’il piège absolument tout le monde une fois.
n8n chiffre vos identifiants avec une clé. Si vous ne l’avez pas définie vous-même, elle a
été générée au premier démarrage et elle vit dans le volume. Tant que vous restaurez le volume
entier, tout va bien. Mais dès que vous faites quelque chose de partiel — remonter une instance
neuve puis y réimporter seulement vos automatisations, par exemple — la clé ne suit pas. Vos
identifiants sont là, ils sont illisibles, et l’application vous dit simplement que les
identifiants ne fonctionnent plus.
Le symptôme est déroutant parce que tout le reste a l’air correct : les automatisations
sont bien là, leur structure est intacte, seules les connexions échouent.
Définissez la clé vous-même dans votre fichier de configuration, et conservez-la
ailleurs que sur le serveur — dans votre gestionnaire de mots de passe, par exemple.
C’est une ligne à écrire une fois. Sans elle, la moitié des scénarios de restauration
échouent. La manière de la déclarer est détaillée dans
le fichier compose expliqué.
Trois niveaux de protection, du plus simple au plus sûr
Ces trois niveaux ne se remplacent pas : ils couvrent des accidents différents. L’idéal
est d’en avoir deux, et le troisième si vos automatisations portent quelque chose de
critique.
L’instantané de l’hébergeur : utile, pas suffisant
C’est une photographie complète de la machine, prise en quelques minutes depuis le panneau
de votre hébergeur, restaurable tout aussi vite. C’est excellent contre la fausse manœuvre
— une mise à jour ratée, une commande de trop — et cela ne demande aucun travail.
Sa limite est fondamentale : l’instantané vit sur la même infrastructure que
le serveur qu’il protège. Un incident majeur chez l’hébergeur, un compte suspendu
pour un impayé, une erreur de facturation qui coupe le service, et vous perdez la machine et
sa photographie du même coup. C’est un filet de premier niveau, pas une sauvegarde.
La copie du volume : la vraie sauvegarde
C’est celle qui compte. Vous copiez le dossier de données vers un endroit qui n’a rien à
voir avec le serveur, et vous pouvez tout reconstruire à partir de là, chez n’importe quel
hébergeur.
Trois précautions, toutes apprises à la dure. D’abord, arrêtez le conteneur avant
de copier, ou copiez à un moment de faible activité : sauvegarder une base
pendant qu’elle écrit produit parfois un fichier corrompu, qui se copiera très bien et ne se
restaurera pas. Quelques secondes d’arrêt suffisent, en pleine nuit personne ne le remarque.
Ensuite, compressez et datez. Une archive par jour, nommée avec sa date,
vous permet de revenir à avant-hier — ce qui est exactement ce dont on a besoin quand on
s’aperçoit avec un jour de retard qu’une automatisation a été modifiée par erreur.
Enfin, la copie doit quitter la machine. Une sauvegarde rangée sur le
serveur qu’elle protège ne protège que de l’erreur humaine.
L’export des automatisations : le filet en cas de doute
n8n sait exporter chaque automatisation dans un fichier lisible, et l’ensemble d’un coup.
Ces fichiers ne contiennent pas vos identifiants — ce qui est une bonne chose pour la
sécurité — mais ils contiennent toute la logique.
C’est le niveau le plus léger et le plus portable. Il tient dans un dépôt de code, se lit,
se compare d’une version à l’autre, et permet de voir ce qui a changé dans une automatisation
entre deux dates. Beaucoup s’en servent comme d’une mémoire de leurs modifications, en plus de
la sauvegarde proprement dite.
Les quatre accidents qui arrivent réellement
On imagine la panne matérielle, le disque qui lâche. C’est en réalité le cas le plus rare,
parce que les hébergeurs sérieux ont déjà de la redondance. Voici ce qui se produit
vraiment.
La fausse manœuvre, de loin en tête. Une commande tapée dans le mauvais
dossier, une option de suppression ajoutée par habitude, un « je repars propre » qui
efface le volume avec le conteneur. C’est instantané, définitif, et cela arrive à des gens
compétents un jour de fatigue. L’instantané de l’hébergeur couvre très bien ce cas — à
condition d’en avoir un de moins de vingt-quatre heures.
La mise à jour qui tourne mal. Une montée de version qui convertit le
format des données et se comporte différemment de ce que vous attendiez. Le retour en arrière
ne suffit pas, parce que les données ont déjà été converties. Seule une copie prise
avant la mise à jour vous sort de là — c’est pourquoi elle figure en première étape de
toute procédure de montée de version.
Le compte suspendu. Celui auquel personne ne pense. Une carte bancaire
expirée, un impayé qui passe inaperçu parce que la facture partait dans une boîte que vous ne
relevez plus, un litige avec l’hébergeur. Le serveur est coupé, et les instantanés avec, parce
qu’ils vivent sur la même infrastructure. C’est précisément le scénario contre lequel une copie
déposée ailleurs est la seule protection.
La modification silencieuse. Quelqu’un — vous, un collaborateur — modifie
une automatisation, et le problème n’apparaît que trois semaines plus tard, quand un client
signale qu’il n’a jamais reçu quelque chose. Là, ni l’instantané de la nuit ni la copie
d’hier ne servent : il faut une archive antérieure au changement. C’est l’argument en
faveur d’une rétention sur plusieurs mois, et de l’export des automatisations dans un dépôt
qui garde l’historique des versions.
À quelle fréquence, et combien de copies garder
La bonne fréquence se déduit d’une seule question : combien de travail acceptez-vous
de refaire ? Si vous modifiez vos automatisations une fois par mois, une sauvegarde
hebdomadaire est largement suffisante. Si vous y touchez tous les jours, il faut une copie
quotidienne.
Attention à ne pas raisonner uniquement sur vos modifications : l’historique des
exécutions, lui, s’écrit en permanence. Si cet historique a une valeur pour vous — parce qu’il
sert de preuve — la fréquence doit suivre l’activité, pas les modifications.
| Votre situation | Fréquence utile | Ce que vous acceptez de perdre |
|---|---|---|
| Vous modifiez vos automatisations une fois par mois | Hebdomadaire | Au pire une semaine de réglages fins. |
| Vous y touchez chaque semaine | Quotidienne | Une journée de travail. |
| Votre historique sert de preuve | Quotidienne, minimum | Une journée de traces — c’est la contrainte la plus forte, et elle ne dépend pas de vos modifications. |
| Vous préparez une montée de version | Juste avant, en plus du reste | Rien : c’est la seule sauvegarde qui vous permettra de revenir en arrière. |
Sur le nombre de copies à conserver, la règle simple qui fonctionne : sept quotidiennes,
quatre hebdomadaires, trois mensuelles. Cela pèse quelques centaines de mégaoctets et couvre à
peu près tous les cas, y compris celui où l’on découvre un problème avec deux mois de retard.
Où déposer les copies
Le principe tient en une phrase : ailleurs, et pas chez le même acteur.
Un espace de stockage objet chez un autre hébergeur, un service de stockage en ligne, un
serveur de sauvegarde dédié, ou même un disque chez vous synchronisé chaque nuit — tout
convient, à condition que la panne du serveur ne puisse pas emporter la copie.
Deux points de vigilance. Le premier est réglementaire : vos sauvegardes contiennent
des données personnelles — les adresses de vos clients, le contenu de vos messages. Elles
doivent être traitées avec les mêmes précautions que l’instance elle-même, ce qui veut dire un
hébergement dans l’Union européenne et un accès restreint. Une archive de sauvegarde oubliée
dans un dossier partagé est une fuite de données qui attend.
Le second est le chiffrement : chiffrez l’archive avant de l’envoyer. C’est une option
de plus sur la commande de compression, et cela change tout si la copie se retrouve un jour
quelque part où elle n’aurait pas dû être.
Automatiser la sauvegarde avec n8n lui-même
Il y a une élégance certaine à faire garder l’outil par lui-même, et c’est parfaitement
faisable : une automatisation programmée chaque nuit, qui exporte les workflows, dépose
l’archive sur votre stockage distant, et vous envoie un message si quelque chose s’est mal
passé.
Une réserve, et elle est importante : n8n ne peut pas sauvegarder correctement
la base pendant qu’il l’utilise. L’automatisation interne convient très bien pour
l’export des workflows et pour la surveillance ; la copie du volume, elle, doit être
lancée depuis le serveur, en dehors de l’application, avec un arrêt momentané du conteneur.
Une tâche programmée du système fait cela très bien.
La combinaison qui fonctionne le mieux : une tâche système qui arrête, copie, relance
et envoie ; et une automatisation n8n qui vérifie chaque matin que l’archive de la nuit
est bien arrivée, et qui vous alerte sinon. Cette deuxième partie est celle que tout le monde
oublie, et c’est pourtant elle qui évite le scénario classique : une sauvegarde en panne
depuis six semaines dont personne ne s’est aperçu.
Restaurer : la procédure
Restaurer, c’est refaire le chemin dans l’autre sens, et cela prend une vingtaine de
minutes. L’ordre compte.
- Arrêtez le conteneur s’il tourne encore. Restaurer par-dessus une
application en fonctionnement ne donne jamais rien de bon. - Mettez de côté le dossier de données actuel plutôt que de l’écraser.
Renommez-le. Vous serez content de l’avoir si la restauration révèle que vous vous êtes trompé
d’archive. - Décompressez l’archive à l’emplacement attendu, et vérifiez que les droits
du dossier sont corrects — c’est l’oubli le plus fréquent, et il donne un refus de permission
au démarrage. - Vérifiez que la clé de chiffrement de votre fichier de configuration est
bien celle qui correspond à cette sauvegarde. - Relancez, puis ouvrez l’interface et regardez si vos automatisations sont
là. - Testez une connexion à un service extérieur. C’est le seul moyen de
savoir si les identifiants ont bien été déchiffrés. - Réactivez les automatisations une par une, pas toutes d’un coup. Si l’une
d’elles avait été désactivée pour une bonne raison, vous vous en souviendrez à ce
moment-là.
Un point souvent oublié : si vous restaurez sur une machine différente, l’adresse de
vos webhooks change. Les services extérieurs qui appelaient l’ancienne adresse continueront de
le faire dans le vide. Faites la liste avant, mettez-les à jour après.
Combien de temps vous serez à l’arrêt, réellement
Deux questions se cachent derrière « est-ce que je suis bien protégé », et les
confondre mène à des dispositifs mal calibrés. Elles se posent en français très simple.
Première question : combien de travail suis-je prêt à refaire ?
La réponse détermine la fréquence des copies. Si votre dernière sauvegarde date de la nuit
dernière, vous perdez au maximum une journée de modifications et d’historique.
Seconde question : combien de temps mes automatisations peuvent-elles rester
arrêtées ? La réponse détermine votre niveau de préparation, ce qui est tout
autre chose. Une sauvegarde parfaite ne sert à rien si remonter l’instance vous demande une
journée de tâtonnements.
Concrètement, pour une instance n8n standard : louer une machine prend cinq minutes,
installer Docker en prend cinq autres, restaurer l’archive et relancer une dizaine, remettre
le nom de domaine en place et attendre la propagation entre quinze minutes et deux heures. Une
personne préparée est de retour en une heure environ. Une personne qui découvre la procédure
en pleine panne y passe la journée.
C’est toute la valeur du test décrit ci-dessous : il ne vérifie pas seulement que
l’archive est bonne, il vous fait répéter la manœuvre à froid. La deuxième fois, vous savez
quoi faire.
Un mot sur les automatisations qui n’ont pas tourné pendant l’arrêt : les tâches
programmées sont simplement sautées, elles ne se rattrapent pas. Les webhooks appelés pendant
la coupure sont perdus, sauf si le service émetteur réessaie — certains le font, la plupart
non. Si une automatisation critique ne supporte pas de manquer un déclenchement, prévoyez un
tableau de contrôle qui vous permette de rattraper à la main ce qui a été manqué.
Le test qui transforme une intention en sauvegarde
C’est la section la plus importante de cet article, et celle que presque personne
n’applique. Une sauvegarde jamais restaurée n’est pas une sauvegarde : c’est une
intention.
Le test se fait une fois, prend une vingtaine de minutes, et coûte quelques centimes. Louez
une machine à l’heure, montez une instance vide, restaurez-y votre dernière archive, ouvrez
l’interface, vérifiez que vos automatisations sont présentes et qu’une connexion fonctionne.
Puis détruisez la machine.
Ce test révèle presque toujours quelque chose. Dans l’ordre de fréquence : la clé de
chiffrement que personne n’avait pensé à noter ; une archive qui ne contenait pas ce
qu’on croyait, parce que le chemin de sauvegarde pointait sur le mauvais dossier ; une
sauvegarde interrompue depuis des semaines sans que rien ne l’ait signalé ; et des droits
de fichiers qui empêchent l’application de démarrer.
Chacun de ces problèmes est trivial à corriger un jour ordinaire. Chacun est un désastre le
jour où vous découvrez son existence en pleine restauration d’urgence.
Migrer vers un autre serveur
Une migration n’est rien d’autre qu’une restauration volontaire, faite sans urgence. C’est
d’ailleurs l’excellente raison de la traiter comme un test de sauvegarde grandeur nature.
La règle d’or est de monter la nouvelle instance à côté de l’ancienne,
jamais à la place. Les deux tournent en parallèle le temps de la vérification ; seule
l’ancienne reste branchée sur le nom de domaine. Vous pouvez donc tout tester sans que
personne ne s’en aperçoive, et abandonner en cours de route si quelque chose cloche.
La bascule proprement dite consiste à faire pointer le nom de domaine vers la nouvelle
machine, une fois que vous avez vérifié. Prévoyez que le changement mette un peu de temps à se
propager, et gardez l’ancienne machine allumée une semaine : un retour en arrière gratuit
vaut mieux qu’une nuit blanche.
Ce qui ne se transfère pas tout seul, et qu’il faut traiter à la main : les adresses de
webhooks chez vos prestataires extérieurs, et les éventuelles autorisations d’accès qui
mentionnent l’adresse de l’ancienne machine. Faites la liste avant de basculer.
Le choix de la nouvelle machine, lui, se fait avec les mêmes critères que le premier
jour : nous les avons détaillés dans quel VPS choisir pour
n8n.
Les erreurs de restauration les plus fréquentes
| Ce que vous constatez après restauration | La cause, presque toujours |
|---|---|
| Les automatisations sont là, mais aucune connexion ne fonctionne | La clé de chiffrement ne correspond pas à cette sauvegarde. C’est de loin le cas le plus fréquent. |
| « permission denied » au démarrage | Les droits du dossier restauré. L’application ne tourne pas en administrateur : le dossier doit lui appartenir. |
| L’archive se décompresse mais l’instance démarre vide | La sauvegarde ne contenait pas ce que vous croyiez — chemin erroné, ou copie faite sur le mauvais dossier. À vérifier lors du test annuel. |
| La base refuse de s’ouvrir | L’archive a été prise pendant que l’application écrivait. Reprenez la sauvegarde de la veille et arrêtez le conteneur la prochaine fois. |
| Les webhooks ne reçoivent plus rien | Vous avez restauré sur une autre machine : l’adresse publique a changé et les services extérieurs appellent toujours l’ancienne. |
| Des exécutions échouent depuis la restauration | Une montée de version au passage. Comparez la version de l’archive et celle du fichier de configuration. |
Un réflexe qui couvre la moitié de ce tableau : lisez les journaux du conteneur au
démarrage. La cause y est presque toujours écrite en clair, et on passe une heure à chercher
ce qui était affiché depuis le début.
FAQ — vos questions fréquentes
L’instantané de mon hébergeur ne suffit-il pas ?
Il couvre la fausse manœuvre, pas la perte du compte ni l’incident majeur chez l’hébergeur,
puisqu’il vit sur la même infrastructure. Gardez-le — il est pratique et rapide — mais
ajoutez une copie qui part ailleurs. Les deux ne protègent pas des mêmes accidents.
Combien pèse une sauvegarde ?
Quelques dizaines de mégaoctets dans la plupart des cas, une fois compressée. C’est
l’historique des exécutions qui fait la différence : si vous avez activé son élagage
automatique, votre archive reste petite indéfiniment. Sinon, elle grossit sans limite.
Faut-il arrêter n8n pour sauvegarder ?
C’est nettement plus sûr, et l’arrêt dure quelques secondes. Copier une base pendant qu’elle
écrit produit parfois une archive corrompue — qui se copiera parfaitement et ne se restaurera
pas. Programmez la sauvegarde à une heure creuse et le problème ne se pose plus.
Puis-je restaurer sur une version différente de n8n ?
Vers une version plus récente, oui, généralement sans difficulté : l’application
convertit ce qu’il faut au démarrage. Vers une version plus ancienne, c’est risqué : si le
format des données a évolué entre-temps, la conversion ne se fait pas en sens inverse. Notez la
version qui correspond à chaque archive.
Mes identifiants sont-ils dans la sauvegarde ?
Oui, chiffrés, dans le volume. C’est exactement pour cette raison qu’il faut chiffrer
l’archive et la déposer dans un endroit à accès restreint. Les fichiers d’export des
automatisations, eux, ne les contiennent pas.
À quelle fréquence tester la restauration ?
Une fois au montage, c’est indispensable. Ensuite, une fois par an suffit, et à chaque
changement important de votre installation — montée de version majeure, changement
d’hébergeur, passage à une autre base de données.
Faut-il sauvegarder l’historique des exécutions ?
Cela dépend entièrement de l’usage que vous en faites. S’il ne sert qu’au débogage, une
perte n’a aucune conséquence et vous pouvez conserver une rétention courte. S’il sert de preuve
de ce qui a été envoyé à vos clients, c’est la donnée la plus sensible de votre instance, et
c’est elle qui doit dicter votre fréquence de sauvegarde.
Et si je perds la clé de chiffrement ?
Les identifiants enregistrés deviennent irrécupérables : c’est le principe même du
chiffrement. Vos automatisations, elles, restent intactes — il faudra simplement reconnecter
chaque service à la main. C’est long, mais ce n’est pas la fin du monde. Raison de plus pour
noter cette clé aujourd’hui plutôt que demain.
En résumé
Un dossier à copier, une clé à noter, une copie qui part ailleurs, et une restauration
testée une fois : c’est tout ce que demande la protection d’une instance n8n, et cela
tient en une heure de mise en place. Ajoutez une alerte qui vous prévient quand la sauvegarde
de la nuit n’est pas arrivée — c’est ce qui distingue une protection réelle d’une
protection supposée.
Pour la suite : le fichier de configuration où déclarer la clé de chiffrement et
l’élagage de l’historique est décrit dans n8n avec Docker, le
fichier compose expliqué, et le choix de la machine dans
quel VPS choisir pour n8n.
Le Blueprint de l'automatisation no-code (37 pages) offert, puis un e-mail par semaine : une erreur qui coûte cher, un outil au banc d'essai, ou un cas réel décortiqué. Gratuit, désinscription en 1 clic.