Sauvegarder et mettre à jour n8n en production (Docker Compose + PostgreSQL)
Guide des opérations au quotidien pour n8n auto-hébergé : sauvegardes PostgreSQL automatisées, protection de la clé de chiffrement, copies hors serveur avec rclone, reprise après sinistre depuis un VPS vierge, mises à jour Docker Compose sécurisées, rollback et migration 1.x vers 2.x.
Vous avez installé n8n sur votre VPS avec Docker Compose et PostgreSQL. C'était le jour un. Le jour deux, c'est le maintenir en vie : sauvegardes automatisées, restaurations testées et mises à jour sans risque.
Ce guide couvre tout ce qu'il faut pour protéger une instance n8n en production. Nous allons construire un script de sauvegarde, l'automatiser avec cron, copier les sauvegardes hors serveur, dérouler une reprise après sinistre sur un VPS vierge et mettre à jour n8n en toute sécurité avec possibilité de rollback. Nous abordons aussi la migration de 1.x vers 2.x.
Ce guide suppose que vous avez suivi notre guide d'installation n8n avec Docker Compose pour déployer n8n. Votre stack utilise Docker Compose avec PostgreSQL, un utilisateur deploy non root et un reverse proxy.
Quelles données n8n stocke-t-il et pourquoi les sauvegarder ?
n8n stocke cinq composants qu'il faut sauvegarder ensemble. Si un seul manque, la restauration peut être partielle ou impossible. La base PostgreSQL contient vos workflows, les credentials (chiffrés), l'historique d'exécution et les comptes utilisateurs. La clé de chiffrement (encryption key) permet de déchiffrer ces credentials. Le volume Docker stocke les nœuds personnalisés et les données binaires. Vos fichiers .env et docker-compose.yml définissent la configuration d'exécution.
| Composant | Contenu | Risque en cas de perte | Méthode de sauvegarde |
|---|---|---|---|
| Base PostgreSQL | Workflows, credentials chiffrés, historique d'exécution, utilisateurs | Toutes les données perdues | pg_dump (format custom) |
N8N_ENCRYPTION_KEY |
Clé AES-256 pour le déchiffrement des credentials | Tous les credentials deviennent définitivement irrécupérables | Copie depuis .env ou config du conteneur |
Volume Docker (.n8n) |
Nœuds personnalisés, données binaires d'exécution | Nœuds personnalisés et fichiers uploadés perdus | Conteneur Alpine avec tar |
Fichier .env |
Mots de passe base de données, clé de chiffrement, configuration domaine | À recréer manuellement | Copie de fichier |
docker-compose.yml |
Définitions des services, mappages de volumes, tags d'images | À recréer manuellement | Copie de fichier |
Comment sauvegarder la base PostgreSQL de n8n avec pg_dump ?
Utilisez pg_dump avec --format=custom pour créer un dump compressé et restaurable de la base n8n. Le format custom permet la restauration sélective et le traitement parallèle. Lancez le dump via le conteneur PostgreSQL en cours d'exécution.
docker exec n8n-postgres \
pg_dump -U n8n -d n8n --format=custom \
> /home/deploy/n8n-backups/n8n-db-$(date +%Y%m%d-%H%M%S).dump
Ce que fait cette commande : docker exec exécute pg_dump à l'intérieur du conteneur PostgreSQL. -U n8n est l'utilisateur de la base. -d n8n est le nom de la base. --format=custom produit un dump binaire compressé que pg_restore peut restaurer de manière sélective. La sortie est redirigée vers un fichier horodaté sur l'hôte.
Vérifiez que le dump est valide :
cat /home/deploy/n8n-backups/n8n-db-*.dump | docker exec -i n8n-postgres pg_restore --list | head -20
Puisque pg_restore se trouve dans le conteneur PostgreSQL, le dump est envoyé via pipe à docker exec -i. Vous devriez voir une liste d'objets de base de données (tables, séquences, données). Si vous voyez une erreur ou une sortie vide, le dump a échoué.
Sauvegarder le volume Docker
Le volume de données n8n contient les nœuds personnalisés et les données binaires d'exécution. Sauvegardez-le avec un conteneur Alpine temporaire :
docker run --rm \
-v n8n_n8n_data:/source:ro \
-v /home/deploy/n8n-backups:/backup \
alpine tar czf "/backup/n8n-data-$(date +%Y%m%d-%H%M%S).tar.gz" -C /source .
Le nom du volume n8n_n8n_data est composé du nom de projet Docker Compose (n8n, d'après le répertoire) plus le nom du volume (n8n_data, d'après docker-compose.yml). Lancez docker volume ls si le vôtre diffère.
Ce que fait cette commande : Monte le volume de données n8n en lecture seule (:ro) dans un conteneur Alpine jetable. Le conteneur crée une archive compressée du contenu du volume et l'écrit dans le répertoire de sauvegarde. Le conteneur est supprimé après exécution (--rm).
Vérifiez l'archive :
tar tzf /home/deploy/n8n-backups/n8n-data-*.tar.gz | head -10
Vous devriez voir des chemins de fichiers du répertoire .n8n.
Sauvegarder les fichiers de configuration
BACKUP_DIR="/home/deploy/n8n-backups"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
cp /home/deploy/n8n/.env "$BACKUP_DIR/env-$TIMESTAMP.bak"
cp /home/deploy/n8n/docker-compose.yml "$BACKUP_DIR/docker-compose-$TIMESTAMP.yml.bak"
chmod 600 "$BACKUP_DIR/env-$TIMESTAMP.bak"
Le fichier .env contient votre N8N_ENCRYPTION_KEY et le mot de passe de la base. Restreignez les permissions à 600 pour que seul l'utilisateur de sauvegarde puisse le lire.
Pourquoi la clé de chiffrement n8n est-elle la sauvegarde la plus importante ?
n8n chiffre chaque credential sauvegardé (clés API, tokens OAuth, mots de passe de bases de données) avec AES-256 en utilisant la N8N_ENCRYPTION_KEY. Si vous perdez cette clé, chaque credential dans votre base devient définitivement irrécupérable. Il n'existe aucun mécanisme de réinitialisation. Aucune porte dérobée. Vous devriez ressaisir manuellement chaque credential dans chaque workflow.
La clé est soit définie explicitement dans votre fichier .env, soit auto-générée par n8n au premier démarrage et stockée dans le conteneur à /home/node/.n8n/config.
Trouvez votre clé de chiffrement :
Si vous l'avez définie dans .env :
grep N8N_ENCRYPTION_KEY /home/deploy/n8n/.env
Si n8n l'a auto-générée (vous ne l'avez jamais définie explicitement) :
docker exec n8n cat /home/node/.n8n/config
Cherchez le champ encryptionKey dans la sortie JSON.
Stockez la clé en lieu sûr :
- Copiez la valeur de la clé dans un gestionnaire de mots de passe (Bitwarden, KeePass, 1Password).
- Vérifiez qu'elle est présente dans votre fichier
.envsous la formeN8N_ENCRYPTION_KEY=<votre-clé>. - Votre script de sauvegarde copie déjà
.env, mais stockez la clé séparément aussi. Si votre serveur brûle et que vos sauvegardes sont corrompues, vous pouvez toujours recréer les credentials si vous avez la clé.
Comment automatiser les sauvegardes n8n avec cron ?
Combinez le dump de la base, la sauvegarde du volume et la copie de configuration dans un seul script. Ajoutez le nettoyage par rétention et un ping de health check pour détecter les échecs.
Créez le script de sauvegarde :
nano /home/deploy/n8n/backup-n8n.sh
#!/usr/bin/env bash
set -euo pipefail
# --- Configuration ---
BACKUP_DIR="/home/deploy/n8n-backups"
N8N_DIR="/home/deploy/n8n"
COMPOSE_PROJECT="n8n"
DB_CONTAINER="n8n-postgres" # Matches container_name in docker-compose.yml
DB_USER="n8n"
DB_NAME="n8n"
VOLUME_NAME="${COMPOSE_PROJECT}_n8n_data" # docker compose prefixes project name
RETENTION_DAYS=7
RETENTION_WEEKS=4
HEALTHCHECK_URL="" # Set to your healthcheck.io or uptime-kuma URL
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
DAY_OF_WEEK=$(date +%u)
mkdir -p "$BACKUP_DIR/daily" "$BACKUP_DIR/weekly"
# --- PostgreSQL dump ---
echo "[$(date)] Starting PostgreSQL backup..."
docker exec "$DB_CONTAINER" \
pg_dump -U "$DB_USER" -d "$DB_NAME" --format=custom \
> "$BACKUP_DIR/daily/n8n-db-$TIMESTAMP.dump"
# Verify dump is not empty
if [ ! -s "$BACKUP_DIR/daily/n8n-db-$TIMESTAMP.dump" ]; then
echo "[$(date)] ERROR: Database dump is empty!" >&2
exit 1
fi
# --- Docker volume backup ---
echo "[$(date)] Starting volume backup..."
docker run --rm \
-v "${VOLUME_NAME}:/source:ro" \
-v "$BACKUP_DIR/daily:/backup" \
alpine tar czf "/backup/n8n-data-$TIMESTAMP.tar.gz" -C /source .
# --- Config files ---
echo "[$(date)] Backing up config files..."
cp "$N8N_DIR/.env" "$BACKUP_DIR/daily/env-$TIMESTAMP.bak"
cp "$N8N_DIR/docker-compose.yml" "$BACKUP_DIR/daily/docker-compose-$TIMESTAMP.yml.bak"
chmod 600 "$BACKUP_DIR/daily/env-$TIMESTAMP.bak"
# --- Weekly copy (Sundays) ---
if [ "$DAY_OF_WEEK" -eq 7 ]; then
echo "[$(date)] Creating weekly backup copy..."
cp "$BACKUP_DIR/daily/n8n-db-$TIMESTAMP.dump" "$BACKUP_DIR/weekly/"
cp "$BACKUP_DIR/daily/n8n-data-$TIMESTAMP.tar.gz" "$BACKUP_DIR/weekly/"
cp "$BACKUP_DIR/daily/env-$TIMESTAMP.bak" "$BACKUP_DIR/weekly/"
fi
# --- Retention cleanup ---
echo "[$(date)] Cleaning old backups..."
find "$BACKUP_DIR/daily" -type f -mtime +$RETENTION_DAYS -delete
find "$BACKUP_DIR/weekly" -type f -mtime +$((RETENTION_WEEKS * 7)) -delete
# --- Health check ping ---
if [ -n "$HEALTHCHECK_URL" ]; then
curl -fsS --retry 3 "$HEALTHCHECK_URL" > /dev/null
fi
echo "[$(date)] Backup complete."
Définissez les permissions et testez :
chmod 750 /home/deploy/n8n/backup-n8n.sh
/home/deploy/n8n/backup-n8n.sh
Vérifiez que les fichiers de sauvegarde ont été créés :
ls -lh /home/deploy/n8n-backups/daily/
Regardez les tailles de fichiers. Un dump de base n8n fait typiquement entre 500 Ko et 50 Mo selon l'historique d'exécution. Si le dump fait 0 octet, quelque chose a échoué.
Planifier avec cron
crontab -e
Ajoutez cette ligne pour lancer les sauvegardes tous les jours à 03h00 :
0 3 * * * /home/deploy/n8n/backup-n8n.sh >> /home/deploy/n8n-backups/backup.log 2>&1
Ce que fait cette commande : Lance le script de sauvegarde à 3h du matin chaque jour. Les sorties et erreurs sont ajoutées à backup.log pour faciliter le diagnostic en cas de problème.
Alertes en cas d'échec de sauvegarde
La variable HEALTHCHECK_URL dans le script fonctionne avec des services comme Healthchecks.io ou une instance Uptime Kuma auto-hébergée. Ces services attendent un ping à intervalle régulier. Si le ping s'arrête (parce que le script a échoué ou que le cron ne s'est pas lancé), vous recevez une alerte.
Configurez un check avec une période de 24 heures et une tolérance d'une heure. Si le script de sauvegarde n'envoie pas de ping avant 04h00, vous êtes notifié.
Comment copier les sauvegardes n8n hors serveur avec rclone ?
Des sauvegardes sur le même serveur que n8n ne sont pas de vraies sauvegardes. Si le disque lâche, vous perdez les deux. Utilisez rclone pour copier les sauvegardes vers un stockage objet compatible S3 (Wasabi, Backblaze B2, MinIO ou tout fournisseur S3).
Installez rclone :
sudo apt install rclone
Configurez un remote. Cet exemple utilise n'importe quel stockage compatible S3 :
rclone config
Suivez les invites interactives pour créer un remote nommé n8n-backup. Choisissez « Amazon S3 Compliant Storage Providers » et entrez votre endpoint, clé d'accès et clé secrète.
Vérifiez que le remote fonctionne :
rclone lsd n8n-backup:
Vous devriez voir votre bucket dans la liste.
Ajoutez la synchronisation à votre script de sauvegarde. Insérez ceci avant la ligne de ping du health check :
# --- Off-server copy ---
echo "[$(date)] Syncing to remote storage..."
rclone sync "$BACKUP_DIR" n8n-backup:your-bucket-name/n8n \
--transfers 4 \
--min-age 1m \
--log-level ERROR
--min-age 1m évite d'uploader des fichiers encore en cours d'écriture. --transfers 4 lance quatre uploads en parallèle.
Comment vérifier que les sauvegardes n8n sont valides ?
Une sauvegarde que vous n'avez jamais testée est une sauvegarde que vous n'avez pas. Lancez ces vérifications régulièrement.
Intégrité du dump de base :
cat /home/deploy/n8n-backups/daily/n8n-db-*.dump | docker exec -i n8n-postgres pg_restore --list > /dev/null 2>&1 && echo "OK" || echo "CORRUPT"
Intégrité de l'archive du volume :
tar tzf /home/deploy/n8n-backups/daily/n8n-data-*.tar.gz > /dev/null 2>&1 && echo "OK" || echo "CORRUPT"
Sommes de contrôle pour vérification à distance :
Générez les sommes de contrôle après la sauvegarde :
sha256sum /home/deploy/n8n-backups/daily/* > /home/deploy/n8n-backups/daily/checksums.sha256
Après le téléchargement depuis le stockage distant, vérifiez :
sha256sum -c checksums.sha256
Chaque ligne devrait afficher OK. Toute différence signifie que le fichier a été corrompu pendant le transfert.
Comment restaurer n8n à partir d'une sauvegarde sur un VPS vierge ?
Voici la procédure de reprise après sinistre. Vous avez perdu votre serveur. Vous avez un VPS vierge et vos fichiers de sauvegarde (depuis le stockage distant ou une copie locale). Voici comment remettre n8n en route.
1. Provisionner un nouveau VPS et installer Docker
Configurez un VPS avec Docker et Docker Compose. Suivez notre guide d'installation n8n avec Docker Compose jusqu'à l'étape d'installation de Docker, puis revenez ici.
2. Créer l'utilisateur deploy et le répertoire du projet
adduser --disabled-password deploy
mkdir -p /home/deploy/n8n /home/deploy/n8n-backups
chown deploy:deploy /home/deploy/n8n /home/deploy/n8n-backups
3. Télécharger vos sauvegardes
Depuis votre stockage distant :
su - deploy
rclone copy n8n-backup:your-bucket-name/n8n/daily /home/deploy/n8n-backups/daily --progress
Ou depuis un autre serveur via scp :
scp user@old-server:/home/deploy/n8n-backups/daily/* /home/deploy/n8n-backups/daily/
4. Restaurer les fichiers de configuration
cp /home/deploy/n8n-backups/daily/env-*.bak /home/deploy/n8n/.env
cp /home/deploy/n8n-backups/daily/docker-compose-*.yml.bak /home/deploy/n8n/docker-compose.yml
chmod 600 /home/deploy/n8n/.env
Vérifiez que la clé de chiffrement est présente :
grep N8N_ENCRYPTION_KEY /home/deploy/n8n/.env
Cette commande doit retourner une ligne avec votre clé. Si c'est vide ou absent, récupérez la clé depuis votre gestionnaire de mots de passe et ajoutez-la manuellement. Sans cette clé, vos credentials sont perdus.
5. Démarrer PostgreSQL seul
cd /home/deploy/n8n
docker compose up -d postgres
Attendez que PostgreSQL s'initialise :
docker compose logs -f postgres
Cherchez database system is ready to accept connections.
6. Restaurer la base de données
docker cp /home/deploy/n8n-backups/daily/n8n-db-*.dump n8n-postgres:/tmp/n8n.dump
docker exec n8n-postgres pg_restore -U n8n -d n8n --clean --if-exists /tmp/n8n.dump
Ce que fait cette commande : Copie le fichier dump dans le conteneur, puis pg_restore le charge. --clean supprime les objets existants avant la restauration. --if-exists évite les erreurs si les objets n'existent pas encore.
Vous verrez peut-être des avertissements sur des objets inexistants. C'est normal sur une base vierge. Des erreurs sur les données ou les contraintes ne sont pas normales.
7. Restaurer le volume Docker
Docker Compose a déjà créé le volume n8n_n8n_data quand vous avez démarré PostgreSQL à l'étape précédente. Restaurez dedans :
docker run --rm \
-v n8n_n8n_data:/target \
-v /home/deploy/n8n-backups/daily:/backup:ro \
alpine sh -c "tar xzf /backup/n8n-data-*.tar.gz -C /target"
8. Démarrer la stack complète
docker compose up -d
9. Vérifier la restauration
docker compose ps
Tous les conteneurs devraient afficher le statut running.
Vérifiez les logs n8n :
docker compose logs -f n8n
Cherchez Editor is now accessible via: http://localhost:5678. Aucune erreur de clé de chiffrement.
Ouvrez l'interface web n8n et vérifiez :
- Les workflows existent et correspondent à ce que vous aviez avant.
- Les credentials fonctionnent. Ouvrez n'importe quel credential et confirmez qu'il affiche les valeurs stockées (clés API, mots de passe). Si vous voyez des champs vides ou des erreurs de déchiffrement, votre clé de chiffrement est incorrecte.
- Lancez un workflow de test. Exécutez un workflow simple pour confirmer que la connectivité à la base et le moteur d'exécution fonctionnent.
Testez depuis l'extérieur du serveur :
curl -s https://your-n8n-domain.com/healthz
Une réponse 200 confirme que n8n est accessible et opérationnel.
Comment mettre à jour n8n en toute sécurité avec Docker Compose ?
La mise à jour de n8n suit quatre étapes : sauvegarder, vérifier les notes de version, récupérer la nouvelle image et vérifier. Ne sautez jamais l'étape de sauvegarde.
1. Lancer une sauvegarde
/home/deploy/n8n/backup-n8n.sh
C'est obligatoire. Si la mise à jour casse quelque chose, vous avez besoin d'un point de restauration.
2. Vérifier les notes de version pour les breaking changes
Avant de récupérer la nouvelle version, lisez les notes de version n8n. Recherchez :
- Les migrations de base de données (elles s'exécutent automatiquement au démarrage mais peuvent prendre du temps)
- Les nœuds dépréciés que vos workflows utilisent
- Les variables d'environnement modifiées
- Les versions minimales requises de PostgreSQL
3. Noter votre version actuelle
docker compose exec n8n n8n --version
Notez-la. Vous en aurez besoin pour le rollback.
4. Récupérer et redémarrer
Si votre docker-compose.yml utilise le tag n8nio/n8n:latest ou n8nio/n8n:stable :
cd /home/deploy/n8n
docker compose pull
docker compose down
docker compose up -d
Si vous utilisez une version spécifique (recommandé en production), modifiez docker-compose.yml d'abord :
services:
n8n:
image: n8nio/n8n:2.12.3 # Change to the target version
Puis :
docker compose up -d
5. Vérifier la mise à jour
docker compose exec n8n n8n --version
Confirmez que la version correspond à ce que vous attendiez.
Vérifiez les logs pour les erreurs de migration :
docker compose logs --tail 50 n8n
Cherchez Migrations completed et Editor is now accessible via: http://localhost:5678.
Testez l'endpoint de santé de l'API :
curl -s https://your-n8n-domain.com/healthz
Lancez un workflow de test via l'interface pour confirmer que l'exécution fonctionne.
Comment effectuer un rollback après une mise à jour n8n échouée ?
Si la mise à jour casse des workflows ou que l'interface est inaccessible, revenez à la version précédente.
1. Arrêter l'instance en erreur
cd /home/deploy/n8n
docker compose down
2. Définir le tag de l'image précédente
Modifiez docker-compose.yml et changez l'image pour votre version précédente :
services:
n8n:
image: n8nio/n8n:2.11.2 # Your previous working version
3. Restaurer la base si des migrations ont été exécutées
Si n8n a exécuté des migrations de base pendant la mise à jour échouée, le schéma a pu changer. Restaurez depuis votre sauvegarde pré-mise à jour :
docker compose up -d postgres
docker cp /home/deploy/n8n-backups/daily/n8n-db-*.dump n8n-postgres:/tmp/n8n.dump
docker exec n8n-postgres pg_restore -U n8n -d n8n --clean --if-exists /tmp/n8n.dump
4. Démarrer l'ancienne version
docker compose up -d
Vérifiez :
docker compose exec n8n n8n --version
docker compose logs --tail 20 n8n
C'est pour cela que nous sauvegardons avant chaque mise à jour. Sans le dump pré-mise à jour, vous ne pouvez pas downgrader en toute sécurité après une migration.
Comment migrer n8n de la version 1.x vers 2.x ?
n8n 2.0 est sorti en décembre 2025 avec des breaking changes. Si vous êtes encore sur 1.x, migrez rapidement. La version 1.x a reçu des correctifs de sécurité pendant trois mois après la sortie de 2.0, et cette fenêtre est désormais fermée.
Breaking changes principaux dans n8n 2.0
| Changement | Comportement 1.x | Comportement 2.x | Action requise |
|---|---|---|---|
| Support MySQL/MariaDB | Supporté | Abandonné | Migrez vers PostgreSQL avant la mise à jour |
| Task runners | Optionnel | Activé par défaut, image Docker séparée | Utilisez l'image n8nio/runners pour le mode externe |
| Variables d'env dans Code node | Accessibles | Bloquées par défaut | Définissez N8N_BLOCK_ENV_ACCESS_IN_NODE=false si nécessaire |
| Start node | Fonctionnel | Supprimé | Remplacez par des nœuds trigger spécifiques |
| Save vs. Publish | Save = deploy | Save et Publish sont des actions séparées | Mettez à jour les workflows d'équipe |
| Python Code node | Basé sur Pyodide | Python natif via task runners | Utilisez les task runners en mode externe |
Nœuds ExecuteCommand et LocalFileTrigger |
Activés | Désactivés par défaut | Activez-les explicitement si nécessaire |
Option CLI --tunnel |
Disponible | Supprimée | Utilisez un reverse proxy à la place |
N8N_CONFIG_FILES |
Supporté | Supprimé | Utilisez directement les variables d'environnement |
Étape 1 : Lancer le rapport de migration
L'outil de rapport de migration est disponible à partir de n8n 1.121.0. Il identifie les problèmes au niveau des workflows et de l'instance avant la mise à jour.
Dans l'interface n8n, allez dans Settings > Migration Report. Ce menu n'est visible que pour les administrateurs globaux.
Le rapport comporte deux onglets :
- Workflow Issues : Liste les workflows utilisant des nœuds dépréciés, des fonctionnalités supprimées ou des comportements modifiés.
- Instance Issues : Signale les variables d'environnement et la configuration à mettre à jour.
Corrigez chaque problème identifié par le rapport avant de continuer.
Étape 2 : Mettre à jour vers la dernière version 1.x d'abord
Avant de passer à 2.x, mettez à jour vers la dernière version 1.x. Cela garantit que toutes les migrations de base intermédiaires s'exécutent :
docker compose pull # With image set to n8nio/n8n:1-latest or latest 1.x tag
docker compose down && docker compose up -d
Étape 3 : Tout sauvegarder
/home/deploy/n8n/backup-n8n.sh
C'est votre point de rollback. Si 2.x casse votre configuration, vous pouvez restaurer cette sauvegarde et rester sur 1.x.
Étape 4 : Mettre à jour vers 2.x
Modifiez docker-compose.yml :
services:
n8n:
image: n8nio/n8n:stable # Or a specific 2.x version like 2.12.3
docker compose pull
docker compose down
docker compose up -d
Étape 5 : Vérifier la migration
docker compose logs --tail 100 n8n
Cherchez les migrations terminées et l'absence d'erreurs.
Testez les workflows signalés par le rapport de migration. Ouvrez les credentials pour confirmer que le déchiffrement fonctionne. Lancez quelques workflows de bout en bout.
Si quelque chose est cassé, effectuez un rollback avec la procédure de la section précédente en utilisant votre sauvegarde 1.x et le tag d'image 1.x.
Dépannage
pg_dump: error: connection to server failed
Le conteneur PostgreSQL ne tourne pas. Démarrez-le avec docker compose up -d postgres et attendez qu'il soit prêt avant de lancer les sauvegardes.
Les credentials apparaissent vides après restauration
Votre N8N_ENCRYPTION_KEY ne correspond pas à celle utilisée lors de la sauvegarde des credentials. Vérifiez votre fichier .env. Comparez-la avec la clé dans votre gestionnaire de mots de passe.
docker exec échoue avec « no such container »
Les noms de conteneurs dépendent du nom de votre répertoire de projet et du fichier compose. Lancez docker ps pour trouver le nom réel du conteneur. Ajustez la variable DB_CONTAINER dans le script de sauvegarde.
Le script de sauvegarde tourne mais le healthcheck ne ping jamais
Vérifiez que HEALTHCHECK_URL est défini dans le script. Testez l'URL manuellement : curl -fsS "your-healthcheck-url". Les règles de pare-feu bloquent peut-être le HTTPS sortant.
n8n ne démarre pas après une mise à jour avec une erreur de migration
Vérifiez les logs avec docker compose logs n8n. Si l'erreur mentionne une migration spécifique, cherchez cette erreur sur le forum communautaire n8n. Effectuez un rollback si nécessaire.
rclone sync échoue avec une erreur d'authentification
Lancez rclone config reconnect n8n-backup: pour rafraîchir les identifiants. Vérifiez que votre clé d'accès et votre secret sont corrects.
Où se trouvent les logs :
# n8n application logs
docker compose logs -f n8n
# PostgreSQL logs
docker compose logs -f postgres
# Backup script log
tail -f /home/deploy/n8n-backups/backup.log
# Cron execution log
grep CRON /var/log/syslog | tail -20
Copyright 2026 Virtua.Cloud. Tous droits réservés. Ce contenu est une création originale de l'équipe Virtua.Cloud. Toute reproduction, republication ou redistribution sans autorisation écrite est interdite.
Prêt à essayer ?
Déployez votre serveur en quelques secondes. Linux, Windows ou FreeBSD.
Voir les offres VPS