Backup automatisé et restauration testée.

Pourquoi 90% des backups n8n sont inutiles.

On voit régulièrement chez nos clients la même erreur : un backup n8n configuré il y a 6 mois, qui tourne tous les jours, et que personne n'a jamais essayé de restaurer. Le jour où le serveur crashe, on découvre que le script ne sauvegardait que la base PostgreSQL, pas le fichier .env, et donc que la N8N_ENCRYPTION_KEY est perdue avec le serveur. Tous les credentials deviennent illisibles. Le backup est techniquement valide mais pratiquement inutilisable.

La règle d'or : un backup non testé n'est pas un backup, c'est un espoir. Ce chapitre vous montre comment construire une vraie stratégie de sauvegarde, et comment la valider.

La stratégie 3-2-1 appliquée à n8n.

Standard de l'industrie depuis les années 2000, applicable directement à votre stack n8n :

• 3 copies de vos données : 1 production (sur le VPS) + 2 sauvegardes
• 2 supports différents : disque du VPS + stockage objet S3-compatible
• 1 copie offsite : hors du VPS, idéalement chez un autre fournisseur

Concrètement, ça donne pour n8n :

Les 5 éléments à sauvegarder absolument.

Beaucoup de tutos n8n parlent de "sauvegarder la base". C'est insuffisant. Voici ce qu'il faut sauvegarder par ordre de criticité :

1. N8N_ENCRYPTION_KEY (le fichier .env) : sans elle, tous vos credentials sont illisibles. À sauvegarder dans un endroit séparé du serveur (gestionnaire de mots de passe), pas seulement dans les backups quotidiens.
2. Base PostgreSQL : workflows, credentials chiffrés, historique d'exécution, comptes utilisateurs. Le plus gros volume.
3. Volume n8n_storage : custom nodes installés, données binaires temporaires, configuration utilisateur.
4. Fichiers de config : docker-compose.yml, Caddyfile, init-data.sh. Faciles à reconstituer mais pénibles à recoder de mémoire.
5. Exports JSON des workflows : portable, lisible, archivable. Bonus pour traçabilité et migration future.

Choisir votre stockage offsite.

Pour respecter la règle 3-2-1, le backup doit partir hors du VPS. Voici les options recommandées pour une PME française :

Pour des backups n8n typiques (1 à 5 Go par sauvegarde, conservés 90 jours), le coût mensuel reste sous 1 € avec Backblaze ou Scaleway. C'est négligeable comparé aux risques évités.

Pour ce cours, on prend Scaleway Object Storage Paris (souveraineté maximale française). La procédure est identique avec n'importe quel S3-compatible.

Configurer rclone pour Scaleway Object Storage.

rclone est l'outil de référence pour synchroniser des fichiers vers du stockage objet. Installez-le :

sudo apt install -y rclone

Configurez rclone interactivement :

rclone config

# Choix successifs :
# n) New remote
# name : scaleway-paris
# Storage : 5 (Amazon S3 compliant)
# provider : Scaleway
# env_auth : false
# access_key_id : VOTRE_ACCESS_KEY_SCALEWAY
# secret_access_key : VOTRE_SECRET_KEY
# region : fr-par
# endpoint : s3.fr-par.scw.cloud
# acl : private
# y) Yes this is OK

Vous obtenez vos credentials Scaleway depuis console.scaleway.com → IAM → API keys. Créez d'abord un bucket : Object Storage → Buckets → "n8n-backups-monentreprise" région Paris.

Test :

rclone lsd scaleway-paris:
# Doit lister votre bucket

Installer age pour le chiffrement.

age est un outil moderne de chiffrement (alternative simple à GPG) créé par les ingénieurs de Google et Filippo Valsorda. Beaucoup plus simple à utiliser que GPG, audit de sécurité validé.

sudo apt install -y age

# Generer une paire de cles (sur votre poste local de preference)
age-keygen -o ~/.age/n8n-backup-key.txt
# Affiche la cle publique : age1xxxx...
# Conservez le fichier de cle PRIVEE en lieu sur (gestionnaire de mots de passe)

La clé publique age1xxxx... chiffre les backups, la clé privée les déchiffre. Sauvegardez la clé privée dans Bitwarden/1Password : sans elle, vos backups chiffrés sont inutiles.

Le script de backup automatisé.

On crée maintenant le script bash qui orchestre tout. Créez le fichier :

sudo nano /usr/local/bin/n8n-backup.sh

Collez ce contenu (adaptez le bucket name et la clé publique age) :

#!/bin/bash
set -euo pipefail

# Configuration
BACKUP_DIR=/var/backups/n8n
N8N_DIR=/opt/n8n
DATE=$(date +%Y%m%d_%H%M%S)
AGE_RECIPIENT="age1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"  # votre cle publique
RCLONE_REMOTE="scaleway-paris:n8n-backups-monentreprise"
RETENTION_DAYS_LOCAL=14
RETENTION_DAYS_REMOTE=90

mkdir -p "$BACKUP_DIR"
cd "$N8N_DIR"

echo "=== Backup n8n démarré : $DATE ==="

# 1. Charger .env pour avoir les credentials Postgres
source "$N8N_DIR/.env"

# 2. Dump PostgreSQL au format custom (compresse natif)
echo "[1/4] Dump PostgreSQL..."
docker compose exec -T postgres pg_dump \
  -U "$POSTGRES_USER" \
  -d "$POSTGRES_DB" \
  --format=custom --compress=9 \
  > "$BACKUP_DIR/db_${DATE}.dump"

# 3. Archive du volume n8n_storage
echo "[2/4] Archive volume n8n..."
docker run --rm \
  -v n8n_n8n_storage:/data:ro \
  -v "$BACKUP_DIR":/backup \
  alpine tar czf "/backup/volume_${DATE}.tar.gz" -C /data .

# 4. Archive de la config
echo "[3/4] Archive config..."
tar czf "$BACKUP_DIR/config_${DATE}.tar.gz" \
  -C "$N8N_DIR" \
  docker-compose.yml init-data.sh .env

# 5. Bundle global chiffre avec age
echo "[4/4] Chiffrement et upload offsite..."
tar cf - -C "$BACKUP_DIR" \
    "db_${DATE}.dump" \
    "volume_${DATE}.tar.gz" \
    "config_${DATE}.tar.gz" \
  | age -r "$AGE_RECIPIENT" \
  > "$BACKUP_DIR/n8n_full_${DATE}.tar.age"

# 6. Upload offsite (Scaleway Paris)
rclone copy "$BACKUP_DIR/n8n_full_${DATE}.tar.age" "$RCLONE_REMOTE/" \
  --progress

# 7. Cleanup local : garder 14 jours
find "$BACKUP_DIR" -name "*.dump" -mtime +$RETENTION_DAYS_LOCAL -delete
find "$BACKUP_DIR" -name "*.tar.gz" -mtime +$RETENTION_DAYS_LOCAL -delete
find "$BACKUP_DIR" -name "*.tar.age" -mtime +$RETENTION_DAYS_LOCAL -delete

# 8. Cleanup remote : garder 90 jours
rclone delete "$RCLONE_REMOTE/" --min-age ${RETENTION_DAYS_REMOTE}d

# 9. Notification (optionnelle, via webhook n8n ou email)
SIZE=$(du -sh "$BACKUP_DIR/n8n_full_${DATE}.tar.age" | cut -f1)
echo "=== Backup terminé : $DATE ($SIZE) ==="

Rendez le script exécutable :

sudo chmod +x /usr/local/bin/n8n-backup.sh
sudo chown root:root /usr/local/bin/n8n-backup.sh

Tester le script en mode manuel.

Avant de planifier, testez le script à la main :

sudo /usr/local/bin/n8n-backup.sh

# Vous devriez voir les 4 etapes s'enchainer
# Verifiez le bucket Scaleway via la console web : votre fichier doit y apparaitre

Si tout fonctionne, planifiez l'exécution quotidienne via cron :

sudo crontab -e

# Ajouter cette ligne (backup tous les jours a 3h du matin)
0 3 * * * /usr/local/bin/n8n-backup.sh >> /var/log/n8n-backup.log 2>&1

Procédure de restauration : bare-metal recovery.

C'est ici que tout se joue. Voici la procédure complète pour restaurer n8n sur un nouveau VPS, à blanc, en simulant la perte totale du serveur d'origine.

Préparation : nouveau VPS.

Provisionnez un nouveau VPS Hostinger KVM 1 (procédure du chapitre 2). Installez Docker + Docker Compose (procédure du chapitre 3, mais arrêtez-vous avant le démarrage de la stack n8n).

1. Récupérer le backup chiffré.

cd /tmp
rclone copy scaleway-paris:n8n-backups-monentreprise/n8n_full_LATEST.tar.age .

2. Déchiffrer.

# Recuperer la cle privee age depuis votre gestionnaire de mots de passe
nano ~/.age/n8n-backup-key.txt
# Y coller la cle privee

# Dechiffrer
age --decrypt -i ~/.age/n8n-backup-key.txt n8n_full_LATEST.tar.age > backup.tar
tar xf backup.tar

3. Restaurer la config.

sudo mkdir -p /opt/n8n
cd /opt/n8n
tar xzf /tmp/config_LATEST.tar.gz
ls -la
# Vous devez voir : docker-compose.yml, init-data.sh, .env

4. Restaurer le volume n8n.

# Creer les volumes vides
docker volume create n8n_n8n_storage
docker volume create n8n_db_storage

# Restaurer le contenu du volume
docker run --rm \
  -v n8n_n8n_storage:/data \
  -v /tmp:/backup \
  alpine tar xzf /backup/volume_LATEST.tar.gz -C /data

5. Restaurer PostgreSQL.

# Demarrer Postgres seul
docker compose up -d postgres
sleep 30  # attendre l'init

# Restore
docker compose exec -T postgres pg_restore \
  -U $POSTGRES_USER -d $POSTGRES_DB \
  --clean --if-exists \
  /tmp/db_LATEST.dump

# Demarrer n8n
docker compose up -d n8n

6. Bascule DNS et vérifications.

Mettez à jour votre enregistrement DNS pour faire pointer votre sous-domaine vers la nouvelle IP. La propagation prend 5 min à 1h selon le TTL.

Connectez-vous à n8n. Vérifications critiques :

• ✅ Login avec votre compte owner
• ✅ 2FA fonctionne (codes TOTP)
• ✅ Liste des workflows complète
• ✅ Ouvrir un workflow et vérifier que les credentials affichent les bons noms (pas vides)
• ✅ Test critique : exécuter manuellement un workflow utilisant un credential. S'il se connecte à l'API externe avec succès, votre N8N_ENCRYPTION_KEY est bien restaurée et les credentials sont déchiffrés correctement.

Cadence des tests de restauration.

Recommandation pro : tester la restauration tous les 3 mois. Programmez-le dans votre calendrier au même titre qu'une réunion. Sans ce test régulier, vous ne saurez jamais si vos backups sont vraiment exploitables.

Le test ne nécessite pas de "vraie" restauration en prod : provisionnez un VPS Hostinger temporaire (3 € pour 1 jour), restaurez, vérifiez, supprimez. 30 minutes, 3 €, et vous dormez tranquille.

Récapitulatif backup : votre checklist.

• ✅ rclone configuré vers Scaleway Paris (ou alternative UE)
• ✅ age installé, paire de clés générée, clé privée sauvegardée hors serveur
• ✅ Script /usr/local/bin/n8n-backup.sh créé et testé manuellement
• ✅ Cron quotidien à 3h du matin configuré
• ✅ Premier backup vérifié dans le bucket Scaleway
• ✅ Test de restauration complet réalisé sur un VPS temporaire
• ✅ Cadence trimestrielle de test programmée dans votre agenda
• ✅ N8N_ENCRYPTION_KEY toujours sauvegardée dans 3 endroits indépendants

Vos backups sont maintenant industriels et testés. Le chapitre 6 attaque la migration depuis n8n cloud, si vous y aviez des workflows existants.