n8n self-hosted : sauvegarder et restaurer sa base PostgreSQL sans perdre ses credentials

Un backup git de vos workflows JSON protège votre logique métier. Il ne protège ni l'historique de vos exécutions, ni — surtout — les credentials chiffrés (clés API OpenAI, tokens OAuth, mots de passe Supabase) qui vivent dans la base PostgreSQL de votre instance n8n self-hosted. Le jour où ce disque lâche sans sauvegarde de la base, vous ne perdez pas que des données : vous perdez l'accès à tous vos comptes connectés, et il faut ressaisir chaque credential à la main. Une étude de référence menée chez Google sur une population de plus de 100 000 disques durs en production a mesuré des taux de panne annuels qui grimpent nettement au-delà de la première année d'usage, avec une forte variabilité selon l'âge du matériel (Pinheiro, Weber & Barroso, 2007 — Google Scholar) — un rappel utile que la question n'est pas si un disque tombera en panne, mais quand, et que la sauvegarde n'est pas une option pour une instance en production.

Ce qu'il faut sauvegarder (et ce que le git ne couvre pas)

Une instance n8n self-hosted repose sur trois éléments distincts :

• Les définitions de workflows — le JSON de chaque automatisation. C'est ce que couvre notre guide sur versionner ses workflows n8n avec git : un n8n export:workflow régulier, committé dans un dépôt.
• L'historique des exécutions — utile pour le débogage et, si vous suivez notre guide sur la piste d'audit RGPD avec Supabase, potentiellement exigé pour des raisons de conformité.
• Les credentials chiffrés — stockés dans la base, mais déchiffrables uniquement avec la variable N8N_ENCRYPTION_KEY propre à votre instance.

Ces trois éléments vivent dans la base PostgreSQL (ou SQLite en développement, jamais recommandé en production). Le git protège le premier ; seule une sauvegarde de la base protège les deux autres.

La clé de chiffrement : l'élément le plus critique, souvent le plus négligé

N8N_ENCRYPTION_KEY est générée une seule fois, au premier démarrage de l'instance, et sert à chiffrer chaque credential enregistré. Sans elle, un dump PostgreSQL restauré redonne bien vos workflows et votre historique — mais chaque clé API, chaque token OAuth devient une bouillie de caractères illisible. Il n'existe aucun moyen de la retrouver après coup si elle n'a pas été sauvegardée séparément.

Bonne pratique : stockez cette clé dans un gestionnaire de mots de passe d'équipe (pas dans le même dépôt git que vos workflows, pas dans le même bucket que vos dumps SQL). C'est un secret au même titre que les credentials qu'elle protège — le même principe que celui détaillé dans notre guide pour sécuriser les credentials API dans n8n s'applique ici à la clé elle-même.

Automatiser le dump PostgreSQL avec un workflow n8n

Plutôt qu'un simple cron système, utiliser n8n pour sauvegarder n8n a un avantage concret : le même workflow peut dumper la base, l'uploader vers un stockage objet distant, purger les backups trop anciens, et vous alerter en cas d'échec — le tout visible dans l'onglet Exécutions.

Montage type, déclenché par un Schedule Trigger (voir notre guide sur les expressions cron et fuseaux horaires pour bien régler l'heure de nuit à faible trafic) :

1. Schedule Trigger — tous les jours à 3h locale.
2. Execute Command — lance pg_dump en format personnalisé (compressé, restaurable sélectivement) :

   pg_dump -U n8n_user -d n8n -F c -f /backups/n8n_$(date +%F).dump
   

3. Read/Write Files from Disk — lit le fichier généré en donnée binaire.
4. S3 (ou Google Drive) — upload du binaire vers un bucket distant, hors de la machine hébergeant n8n. Une sauvegarde qui reste sur le même serveur que la base qu'elle protège ne protège de rien en cas de panne disque ou de suppression accidentelle de la VM.
5. Execute Command (nettoyage) — supprime du bucket les dumps de plus de 14 à 30 jours, selon votre politique de rétention.
6. Error Trigger relié à ce workflow — une alerte Slack ou email si l'un de ces nodes échoue, sur le principe décrit dans notre guide sur la gestion des erreurs avec Error Workflow. Un backup qui échoue silencieusement pendant des semaines est pire qu'une absence de backup assumée : il donne un faux sentiment de sécurité.

Tester la restauration, pas seulement la sauvegarde

Un dump jamais restauré n'est qu'une hypothèse de backup. La restauration se fait, à l'identique, sur une instance de test :

pg_restore -U n8n_user -d n8n_test --clean /backups/n8n_2026-07-20.dump

en réutilisant la même N8N_ENCRYPTION_KEY que l'instance d'origine. Planifiez ce test au moins une fois par trimestre : c'est le seul moyen de savoir si vos dumps sont réellement exploitables avant d'en avoir besoin en urgence — le jour d'un vrai incident n'est pas le bon moment pour découvrir un format cassé ou une variable manquante.

Cas particulier : données externes (Supabase, pgvector)

Si vous exploitez le Pack Assistant RAG, les embeddings et documents vectorisés vivent dans votre propre projet Supabase — une base distincte de celle de n8n, avec ses propres mécanismes de sauvegarde à activer côté Supabase. Ne confondez pas les deux : sauvegarder la base n8n ne sauvegarde pas votre base vectorielle, et inversement. Chaque composant de votre pile a besoin de sa propre stratégie de continuité.

Pièges fréquents

• Sauvegarder sur le même disque que la base : en cas de panne matérielle, backup et original disparaissent ensemble. Le stockage distant n'est pas négociable.
• Oublier la clé de chiffrement : le dump le plus récent du monde ne sert à rien si les credentials qu'il contient sont irrécupérables.
• Ne jamais tester la restauration : un backup non vérifié est un backup dont vous ne connaissez pas réellement la fiabilité.
• Confondre export git des workflows et sauvegarde de la base : les deux répondent à des besoins différents et se complètent, ils ne se substituent pas l'un à l'autre.

Pour aller plus loin

Cette rigueur opérationnelle rejoint directement l'esprit du Pack Conformité & Audit (149 €) : ses workflows de piste d'audit et de rapports automatisés reposent sur le même principe — un cron fiable, une alerte en cas d'échec, une donnée qu'on peut prouver ne pas avoir perdue. Si votre instance n8n fait déjà tourner des automatisations de tri d'emails ou un assistant RAG en production, le Bundle FlowKit Complet (269 €) regroupe les trois packs sur cette même exigence de continuité de service.