Backup di n8n self-hosted: cosa salvare, come, e come provare il ripristino

Cosa serve salvare per ripristinare n8n?

Per ripristinare un'istanza n8n self-hosted servono tre cose: il database (SQLite o Postgres), la chiave di cifratura N8N_ENCRYPTION_KEY e la cartella dati /home/node/.n8n con i file binari e la configurazione. Il database senza la chiave restituisce workflow leggibili ma credenziali illeggibili. La chiave senza database non serve a niente. E un backup vale solo se lo hai ripristinato almeno una volta su una macchina pulita.

Cosa c'è nella cartella dati di n8n?

Con l'installazione Docker standard il volume n8n_data è montato su /home/node/.n8n. Dentro trovi tutto quello che n8n scrive per conto suo:

Percorso	Contenuto	Serve nel backup?
config	File JSON con la encryptionKey generata al primo avvio, se non l'hai fissata via variabile d'ambiente	Sì, è il pezzo critico
database.sqlite (più -wal e -shm)	Workflow, credenziali cifrate, utenti, esecuzioni, se usi SQLite	Sì
binaryData/	File passati dai workflow (allegati, PDF, immagini) in modalità filesystem, quella predefinita dalla 2.0	Sì, se i workflow trattano file
nodes/	Nodi community installati	Sì, altrimenti i workflow che li usano non partono
log, crash journal, chiavi SSH del source control	Diagnostica e integrazione Git	Utile, non indispensabile

Se usi Postgres esterno, il database non sta nel volume: la documentazione ufficiale consiglia comunque di continuare a montare /home/node/.n8n, perché la chiave, i log e i dati binari restano lì.

Perché la chiave di cifratura non si può rigenerare?

n8n cifra ogni credenziale prima di scriverla nel database, usando N8N_ENCRYPTION_KEY. Se la fissi tu nel file .env del Compose, la chiave sta lì; se non la fissi, n8n ne genera una casuale al primo avvio e la salva in /home/node/.n8n/config. Dalla versione 2.0 quel file deve avere permessi 0600, altrimenti n8n si rifiuta di partire.

Il punto è questo: i workflow si possono ricostruire, un'esecuzione persa si può rifare, un server si può reinstallare. La chiave no. Se ripristini un database su un'istanza con una chiave diversa, n8n si avvia, mostra i workflow e poi fallisce con un errore di decifratura su ogni credenziale.

Regola pratica: la chiave va in un password manager e va verificata leggendola dall'istanza in esercizio:

docker compose exec n8n sh -c 'cat /home/node/.n8n/config'
docker compose exec n8n printenv N8N_ENCRYPTION_KEY | wc -c

Il secondo comando stampa solo la lunghezza: se restituisce 1, la variabile non è impostata e la chiave vive soltanto nel file config.

Come esportare workflow e credenziali con la CLI?

n8n ha una CLI interna che lavora direttamente sul database. Dentro Docker si invoca con docker compose exec -u node n8n n8n .... Il flag --backup equivale a --all --pretty --separate: un file JSON per ogni workflow, leggibile e versionabile in Git.

docker compose exec -u node n8n mkdir -p /home/node/.n8n/backup
docker compose exec -u node n8n \
  n8n export:workflow --backup --output=/home/node/.n8n/backup/workflows/
docker compose exec -u node n8n \
  n8n export:credentials --backup --output=/home/node/.n8n/backup/credentials/
docker cp "$(docker compose ps -q n8n)":/home/node/.n8n/backup "./backups/n8n-$(date +%F)"

Le credenziali esportate così restano cifrate con la chiave dell'istanza: puoi reimportarle solo dove esiste la stessa N8N_ENCRYPTION_KEY. Con --decrypted invece n8n scrive i segreti in chiaro. Serve in un solo caso, la migrazione verso un'istanza con chiave diversa, e il file va trattato come una password: cifrato a riposo, cancellato dopo l'uso.

L'import fa il percorso inverso e disattiva per default tutti i workflow importati, così un ripristino non fa partire crontab e webhook prima che tu li abbia controllati:

docker compose exec -u node n8n n8n import:credentials --separate --input=/home/node/.n8n/backup/credentials/
docker compose exec -u node n8n n8n import:workflow --separate --input=/home/node/.n8n/backup/workflows/

Questo export è logico: non contiene esecuzioni, utenti, variabili né impostazioni dell'istanza. Per quello serve il dump del database.

Come fare il dump del database?

Con Postgres il dump si fa dal container del database, in formato custom, che si ripristina in modo selettivo con pg_restore:

docker compose exec -T postgres \
  pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc > "n8n-$(date +%F).dump"

Il ripristino, su un database vuoto della stessa versione major di Postgres:

docker compose exec -T postgres \
  pg_restore -U "$POSTGRES_USER" -d "$POSTGRES_DB" --clean --if-exists --no-owner < n8n-2026-09-01.dump

Con SQLite non esiste un dump a caldo affidabile: dalla 2.0 n8n usa il driver in modalità WAL, quindi il database è composto da tre file. Ferma il container, copia il volume, riavvia. Il fermo dura pochi secondi:

docker compose stop n8n
docker run --rm -v n8n_data:/data:ro -v "$PWD/backups":/backup alpine \
  tar czf "/backup/n8n_data-$(date +%F).tgz" -C /data .
docker compose start n8n

Lo stesso comando tar salva anche config, binaryData/ e nodes/, quindi con Postgres lo esegui comunque, senza fermare nulla, per avere la cartella dati completa.

Il backup del server: snapshot, restic o borg?

Il backup dell'istanza n8n e il backup del server sono due livelli diversi, e servono entrambi:

Livello	Cosa copre	Cosa non copre	Costo indicativo
Backup automatico del provider (Hetzner: 20% del prezzo del server)	Immagine intera del disco, ripristino in pochi minuti	Granularità: o tutto o niente, copie a rotazione sullo stesso provider	1-2 euro/mese
Export CLI + dump Postgres	Workflow, credenziali, database in forma leggibile	Sistema operativo, Docker, configurazioni del server	0 euro
restic o borg verso storage separato	Cartella dati e dump, deduplicati, cifrati, con storico	Il ripristino del server resta manuale	1-5 euro/mese

La combinazione che consigliamo è la stessa dell'analisi sul costo reale di n8n self-hosted: snapshot del provider per il disaster recovery rapido, più backup incrementale giornaliero dei dati n8n verso uno storage in un'altra sede (una Storage Box, un bucket S3 in Europa). restic in tre comandi:

export RESTIC_REPOSITORY="sftp:[email protected]:/n8n"
restic init
restic backup ./backups
restic forget --keep-daily 30 --keep-weekly 8 --prune
restic check

restic check va lanciato ogni volta: un repository corrotto scoperto il giorno del ripristino è un backup che non esiste.

Quanto tenere e come ruotare?

Trenta giorni di copie giornaliere sono il minimo. Il motivo non è la quantità di dati, che per n8n resta piccola, ma il tempo di scoperta: una credenziale cancellata per errore o un workflow sovrascritto emergono spesso settimane dopo. Le policy --keep-daily 30 --keep-weekly 8 coprono due mesi con poche decine di MB.

Per tenere il database leggero, n8n cancella da solo le esecuzioni vecchie: EXECUTIONS_DATA_PRUNE è attivo per default con EXECUTIONS_DATA_MAX_AGE a 336 ore, cioè 14 giorni, e un tetto di 10.000 esecuzioni.

I server girano quasi sempre in UTC: un cron alle 03:00 sul server parte alle 5 del mattino in Italia d'estate. Scegli una finestra che non coincida con i workflow pianificati più pesanti.

Come provare il ripristino su una VM pulita?

Il test di ripristino è la parte che tutti rimandano e che decide se il resto è servito a qualcosa. Su una VM temporanea con Docker:

1. Copia compose.yml e .env dal server di produzione, con la stessa immagine bloccata alla stessa versione (per esempio n8nio/n8n:2.37.7) e la stessa N8N_ENCRYPTION_KEY.
2. Avvia solo Postgres e ripristina il dump con il comando pg_restore visto sopra. Con SQLite, scompatta il tar nel volume prima di avviare n8n.
3. Avvia n8n e verifica versione e stato:

docker compose up -d
docker compose exec n8n n8n --version
curl -s http://localhost:5678/healthz
docker compose logs n8n --since 5m | grep -iE "encrypt|migration|error"

4. Entra con un utente esistente, apri una credenziale e usa il test di connessione: è la prova che la chiave è quella giusta.
5. Esegui a mano un workflow che usa quella credenziale e uno che tratta un file binario.
6. Distruggi la VM.

Se il punto 4 fallisce con un errore di decifratura, hai il database ma non la chiave giusta: correggi oggi, non il giorno dell'incidente. Ripeti il test ogni tre mesi e prima di ogni aggiornamento major, come descritto nella guida su come aggiornare n8n in produzione.

Checklist del backup di n8n

• N8N_ENCRYPTION_KEY salvata in un password manager, separata dai backup
• Export CLI di workflow e credenziali ogni giorno, in file separati
• Dump Postgres ogni giorno, oppure copia a freddo del volume con SQLite
• Copia del volume n8n_data (config, binaryData, nodes)
• Backup incrementale con restic o borg verso storage in un'altra sede
• Rotazione: almeno 30 giorni, con restic check a ogni giro
• Snapshot o backup automatico del provider attivo
• Test di ripristino su VM pulita eseguito e datato
• Chi riceve l'alert se il backup notturno fallisce

E il server?

Tutto quello che hai letto copre l'istanza n8n: database, chiave, dati, workflow. Non copre il sistema operativo, Docker, il firewall, i certificati, gli aggiornamenti di sicurezza, i log del reverse proxy. Se il server viene compromesso o il disco si riempie, il backup di n8n è perfetto e il servizio è comunque fermo.

Chi non vuole occuparsene può affidare la gestione del server Linux a un servizio esterno, tenendo n8n dove preferisce: con backup del server verificati, aggiornamenti e monitoraggio a carico di chi gestisce la macchina, da 99 EUR al mese per server. Il perimetro è netto: n8n.it segue l'istanza n8n, i workflow e le integrazioni; managedvps.it segue il server sotto. Se vuoi una verifica del tuo piano di backup o non sai da dove partire, contattaci.