Backup e aggiornamento di n8n in produzione (Docker Compose + PostgreSQL)
Guida alle operazioni quotidiane per n8n self-hosted: backup PostgreSQL automatizzati, protezione della chiave di crittografia, copie off-server con rclone, disaster recovery da un VPS nuovo, aggiornamenti sicuri con Docker Compose, rollback e migrazione da 1.x a 2.x.
Hai installato n8n sul tuo VPS con Docker Compose e PostgreSQL. Quello era il giorno uno. Il giorno due serve a mantenerlo in vita: backup automatizzati, ripristini testati e aggiornamenti sicuri.
Questa guida copre tutto il necessario per proteggere un'istanza n8n in produzione. Costruiremo uno script di backup, lo automatizzeremo con cron, copieremo i backup fuori dal server, eseguiremo un disaster recovery su un VPS nuovo e aggiorneremo n8n in sicurezza con supporto al rollback. Trattiamo anche la migrazione da 1.x a 2.x.
Questa guida presuppone che tu abbia seguito la nostra guida all'installazione di n8n con Docker Compose per configurare n8n. Il tuo stack usa Docker Compose con PostgreSQL, un utente deploy non root e un reverse proxy.
Quali dati memorizza n8n e perché vanno salvati?
n8n memorizza cinque componenti che vanno salvati insieme. Se ne manca anche uno solo, il ripristino può essere parziale o impossibile. Il database PostgreSQL contiene i tuoi workflow, le credenziali (cifrate), la cronologia delle esecuzioni e gli account utente. La chiave di crittografia (encryption key) decifra quelle credenziali. Il volume Docker memorizza i nodi personalizzati e i dati binari. I file .env e docker-compose.yml definiscono la configurazione di runtime.
| Componente | Contenuto | Rischio in caso di perdita | Metodo di backup |
|---|---|---|---|
| Database PostgreSQL | Workflow, credenziali cifrate, cronologia esecuzioni, utenti | Tutti i dati persi | pg_dump (formato custom) |
N8N_ENCRYPTION_KEY |
Chiave AES-256 per la decifratura delle credenziali | Tutte le credenziali salvate diventano permanentemente irrecuperabili | Copia da .env o configurazione del container |
Volume Docker (.n8n) |
Nodi personalizzati, dati binari di esecuzione | Nodi personalizzati e file caricati persi | Container Alpine con tar |
File .env |
Password del database, chiave di crittografia, configurazione dominio | Da ricreare manualmente | Copia del file |
docker-compose.yml |
Definizioni dei servizi, mapping dei volumi, tag delle immagini | Da ricreare manualmente | Copia del file |
Come si esegue il backup del database PostgreSQL di n8n con pg_dump?
Usa pg_dump con --format=custom per creare un dump compresso e ripristinabile del database n8n. Il formato custom supporta il ripristino selettivo e l'elaborazione parallela. Esegui il dump attraverso il container PostgreSQL in esecuzione.
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
Cosa fa questo comando: docker exec esegue pg_dump all'interno del container PostgreSQL. -U n8n è l'utente del database. -d n8n è il nome del database. --format=custom produce un dump binario compresso che pg_restore può ripristinare selettivamente. L'output viene reindirizzato a un file con timestamp sull'host.
Verifica che il dump sia valido:
cat /home/deploy/n8n-backups/n8n-db-*.dump | docker exec -i n8n-postgres pg_restore --list | head -20
Poiché pg_restore si trova nel container PostgreSQL, il dump viene inviato tramite pipe a docker exec -i. Dovresti vedere un elenco di oggetti del database (tabelle, sequenze, dati). Se vedi un errore o un output vuoto, il dump è fallito.
Backup del volume Docker
Il volume dati di n8n contiene i nodi personalizzati e i dati binari di esecuzione. Salvalo con un container Alpine temporaneo:
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 .
Il nome del volume n8n_n8n_data è composto dal nome del progetto Docker Compose (n8n, dalla directory) più il nome del volume (n8n_data, da docker-compose.yml). Esegui docker volume ls se il tuo è diverso.
Cosa fa questo comando: Monta il volume dati di n8n in sola lettura (:ro) in un container Alpine usa e getta. Il container crea un archivio compresso del contenuto del volume e lo scrive nella directory di backup. Il container viene rimosso al termine (--rm).
Verifica l'archivio:
tar tzf /home/deploy/n8n-backups/n8n-data-*.tar.gz | head -10
Dovresti vedere i percorsi dei file dalla directory .n8n.
Backup dei file di configurazione
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"
Il file .env contiene il tuo N8N_ENCRYPTION_KEY e la password del database. Limita i permessi a 600 in modo che solo l'utente di backup possa leggerlo.
Perché la chiave di crittografia di n8n è il backup più importante?
n8n cifra ogni credenziale salvata (chiavi API, token OAuth, password di database) con AES-256 usando la N8N_ENCRYPTION_KEY. Se perdi questa chiave, ogni credenziale nel tuo database diventa permanentemente irrecuperabile. Non esiste un meccanismo di reset. Nessuna backdoor. Dovresti reinserire manualmente ogni credenziale in ogni workflow.
La chiave è impostata esplicitamente nel file .env oppure generata automaticamente da n8n al primo avvio e memorizzata nel container in /home/node/.n8n/config.
Trova la tua chiave di crittografia:
Se l'hai impostata in .env:
grep N8N_ENCRYPTION_KEY /home/deploy/n8n/.env
Se n8n l'ha generata automaticamente (non l'hai mai impostata esplicitamente):
docker exec n8n cat /home/node/.n8n/config
Cerca il campo encryptionKey nell'output JSON.
Conserva la chiave in modo sicuro:
- Copia il valore della chiave in un gestore di password (Bitwarden, KeePass, 1Password).
- Assicurati che sia presente nel file
.envcomeN8N_ENCRYPTION_KEY=<la-tua-chiave>. - Lo script di backup copia già
.env, ma conserva la chiave anche separatamente. Se il server va distrutto e i backup sono corrotti, puoi comunque ricreare le credenziali se hai la chiave.
Come si automatizzano i backup di n8n con cron?
Combina il dump del database, il backup del volume e la copia della configurazione in un unico script. Aggiungi la pulizia per retention e un ping di health check per rilevare i fallimenti.
Crea lo script di backup:
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."
Imposta i permessi e testa:
chmod 750 /home/deploy/n8n/backup-n8n.sh
/home/deploy/n8n/backup-n8n.sh
Verifica che i file di backup siano stati creati:
ls -lh /home/deploy/n8n-backups/daily/
Controlla le dimensioni dei file. Un dump tipico del database n8n pesa tra 500 KB e 50 MB a seconda della cronologia delle esecuzioni. Se il dump è di 0 byte, qualcosa è andato storto.
Pianificare con cron
crontab -e
Aggiungi questa riga per eseguire i backup ogni giorno alle 03:00:
0 3 * * * /home/deploy/n8n/backup-n8n.sh >> /home/deploy/n8n-backups/backup.log 2>&1
Cosa fa questo comando: Esegue lo script di backup alle 3 di notte ogni giorno. Output ed errori vengono aggiunti a backup.log per facilitare la risoluzione dei problemi.
Avvisi in caso di fallimento del backup
La variabile HEALTHCHECK_URL nello script supporta servizi come Healthchecks.io o un'istanza self-hosted di Uptime Kuma. Questi servizi si aspettano un ping a intervalli regolari. Se il ping si interrompe (perché lo script è fallito o il cron non si è eseguito), ricevi un avviso.
Configura un check con un periodo di 24 ore e una tolleranza di un'ora. Se lo script di backup non invia il ping entro le 04:00, ricevi una notifica.
Come si copiano i backup di n8n fuori dal server con rclone?
I backup sullo stesso server di n8n non sono veri backup. Se il disco si guasta, li perdi entrambi. Usa rclone per copiare i backup su object storage compatibile S3 (Wasabi, Backblaze B2, MinIO o qualsiasi provider S3).
Installa rclone:
sudo apt install rclone
Configura un remote. Questo esempio usa qualsiasi storage compatibile S3:
rclone config
Segui i prompt interattivi per creare un remote chiamato n8n-backup. Scegli "Amazon S3 Compliant Storage Providers" e inserisci il tuo endpoint, la chiave di accesso e la chiave segreta.
Verifica che il remote funzioni:
rclone lsd n8n-backup:
Dovresti vedere il tuo bucket nella lista.
Aggiungi la sincronizzazione allo script di backup. Inserisci questo prima della riga del ping di 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 evita di caricare file ancora in fase di scrittura. --transfers 4 esegue quattro upload in parallelo.
Come si verifica che i backup di n8n siano validi?
Un backup che non hai mai testato è un backup che non hai. Esegui questi controlli periodicamente.
Integrità del dump del database:
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"
Integrità dell'archivio del volume:
tar tzf /home/deploy/n8n-backups/daily/n8n-data-*.tar.gz > /dev/null 2>&1 && echo "OK" || echo "CORRUPT"
Checksum per la verifica remota:
Genera i checksum dopo il backup:
sha256sum /home/deploy/n8n-backups/daily/* > /home/deploy/n8n-backups/daily/checksums.sha256
Dopo il download dallo storage remoto, verifica:
sha256sum -c checksums.sha256
Ogni riga dovrebbe riportare OK. Qualsiasi discrepanza indica che il file si è corrotto durante il trasferimento.
Come si ripristina n8n da un backup su un VPS nuovo?
Questa è la procedura di disaster recovery. Hai perso il server. Hai un VPS nuovo e i tuoi file di backup (dallo storage remoto o da una copia locale). Ecco come rimettere in funzione n8n.
1. Provisioning di un nuovo VPS e installazione di Docker
Configura un VPS con Docker e Docker Compose. Segui la nostra guida all'installazione di n8n con Docker Compose fino al passaggio di installazione di Docker, poi torna qui.
2. Creare l'utente deploy e la directory del progetto
adduser --disabled-password deploy
mkdir -p /home/deploy/n8n /home/deploy/n8n-backups
chown deploy:deploy /home/deploy/n8n /home/deploy/n8n-backups
3. Scaricare i backup
Dallo storage remoto:
su - deploy
rclone copy n8n-backup:your-bucket-name/n8n/daily /home/deploy/n8n-backups/daily --progress
O da un altro server via scp:
scp user@old-server:/home/deploy/n8n-backups/daily/* /home/deploy/n8n-backups/daily/
4. Ripristinare i file di configurazione
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
Verifica che la chiave di crittografia sia presente:
grep N8N_ENCRYPTION_KEY /home/deploy/n8n/.env
Questo comando deve restituire una riga con la tua chiave. Se è vuoto o mancante, recupera la chiave dal gestore di password e aggiungila manualmente. Senza questa chiave, le credenziali sono perse.
5. Avviare solo PostgreSQL
cd /home/deploy/n8n
docker compose up -d postgres
Attendi l'inizializzazione di PostgreSQL:
docker compose logs -f postgres
Cerca database system is ready to accept connections.
6. Ripristinare il database
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
Cosa fa questo comando: Copia il file dump nel container, poi pg_restore lo carica. --clean rimuove gli oggetti esistenti prima del ripristino. --if-exists previene errori se gli oggetti non esistono ancora.
Potresti vedere alcuni avvisi su oggetti inesistenti. È normale su un database nuovo. Errori su dati o vincoli non sono normali.
7. Ripristinare il volume Docker
Docker Compose ha già creato il volume n8n_n8n_data quando hai avviato PostgreSQL nel passaggio precedente. Ripristina al suo interno:
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. Avviare lo stack completo
docker compose up -d
9. Verificare il ripristino
docker compose ps
Tutti i container dovrebbero mostrare lo stato running.
Controlla i log di n8n:
docker compose logs -f n8n
Cerca Editor is now accessible via: http://localhost:5678. Nessun errore sulla chiave di crittografia.
Apri l'interfaccia web di n8n e verifica:
- I workflow esistono e corrispondono a quelli che avevi prima.
- Le credenziali funzionano. Apri una credenziale qualsiasi e conferma che mostra i valori memorizzati (chiavi API, password). Se vedi campi vuoti o errori di decifratura, la chiave di crittografia è errata.
- Esegui un workflow di test. Lancia un workflow semplice per confermare che la connessione al database e il motore di esecuzione funzionano.
Testa dall'esterno del server:
curl -s https://your-n8n-domain.com/healthz
Una risposta 200 conferma che n8n è raggiungibile e in esecuzione.
Come si aggiorna n8n in sicurezza con Docker Compose?
L'aggiornamento di n8n segue quattro passaggi: backup, controllo delle note di rilascio, pull della nuova immagine e verifica. Non saltare mai il passaggio di backup.
1. Eseguire un backup
/home/deploy/n8n/backup-n8n.sh
È obbligatorio. Se l'aggiornamento rompe qualcosa, serve un punto di ripristino.
2. Controllare le note di rilascio per i breaking changes
Prima di scaricare la nuova versione, leggi le note di rilascio di n8n. Cerca:
- Migrazioni del database (si eseguono automaticamente all'avvio ma possono richiedere tempo)
- Nodi deprecati usati dai tuoi workflow
- Variabili d'ambiente modificate
- Requisiti minimi di versione PostgreSQL
3. Annotare la versione attuale
docker compose exec n8n n8n --version
Annotala. Ti serve per il rollback.
4. Pull e riavvio
Se il tuo docker-compose.yml usa il tag n8nio/n8n:latest o n8nio/n8n:stable:
cd /home/deploy/n8n
docker compose pull
docker compose down
docker compose up -d
Se fissi una versione specifica (raccomandato in produzione), modifica prima docker-compose.yml:
services:
n8n:
image: n8nio/n8n:2.12.3 # Change to the target version
Poi:
docker compose up -d
5. Verificare l'aggiornamento
docker compose exec n8n n8n --version
Conferma che la versione corrisponde a quella attesa.
Controlla i log per errori di migrazione:
docker compose logs --tail 50 n8n
Cerca Migrations completed e Editor is now accessible via: http://localhost:5678.
Testa l'endpoint di salute dell'API:
curl -s https://your-n8n-domain.com/healthz
Esegui un workflow di test tramite l'interfaccia per confermare che l'esecuzione funziona.
Come si esegue il rollback dopo un aggiornamento n8n fallito?
Se l'aggiornamento rompe i workflow o l'interfaccia non è raggiungibile, torna alla versione precedente.
1. Fermare l'istanza guasta
cd /home/deploy/n8n
docker compose down
2. Impostare il tag dell'immagine precedente
Modifica docker-compose.yml e cambia l'immagine alla versione precedente:
services:
n8n:
image: n8nio/n8n:2.11.2 # Your previous working version
3. Ripristinare il database se le migrazioni sono state eseguite
Se n8n ha eseguito migrazioni del database durante l'aggiornamento fallito, lo schema potrebbe essere cambiato. Ripristina dal backup pre-aggiornamento:
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. Avviare la vecchia versione
docker compose up -d
Verifica:
docker compose exec n8n n8n --version
docker compose logs --tail 20 n8n
Ecco perché facciamo il backup prima di ogni aggiornamento. Senza il dump pre-aggiornamento, non puoi fare downgrade in sicurezza dopo una migrazione.
Come si migra n8n dalla versione 1.x alla 2.x?
n8n 2.0 è uscito a dicembre 2025 con breaking changes. Se sei ancora su 1.x, migra presto. La versione 1.x ha ricevuto solo fix di sicurezza per tre mesi dopo il rilascio di 2.0, e quella finestra si è chiusa.
Breaking changes principali in n8n 2.0
| Modifica | Comportamento 1.x | Comportamento 2.x | Azione richiesta |
|---|---|---|---|
| Supporto MySQL/MariaDB | Supportato | Rimosso completamente | Migrare a PostgreSQL prima dell'aggiornamento |
| Task runners | Opzionale | Attivato di default, immagine Docker separata | Usare l'immagine n8nio/runners per la modalità esterna |
| Variabili d'ambiente nel Code node | Accessibili | Bloccate di default | Impostare N8N_BLOCK_ENV_ACCESS_IN_NODE=false se necessario |
| Start node | Funzionante | Rimosso | Sostituire con nodi trigger specifici |
| Save vs. Publish | Save = deploy | Save e Publish sono azioni separate | Aggiornare i workflow del team |
| Python Code node | Basato su Pyodide | Python nativo via task runners | Usare task runners in modalità esterna |
Nodi ExecuteCommand e LocalFileTrigger |
Attivati | Disattivati di default | Attivare esplicitamente se necessario |
Opzione CLI --tunnel |
Disponibile | Rimossa | Usare un reverse proxy al suo posto |
N8N_CONFIG_FILES |
Supportato | Rimosso | Usare direttamente le variabili d'ambiente |
Passo 1: Eseguire il report di migrazione
Lo strumento di report di migrazione è disponibile da n8n 1.121.0. Identifica problemi a livello di workflow e istanza prima dell'aggiornamento.
Nell'interfaccia di n8n, vai su Settings > Migration Report. È visibile solo per gli amministratori globali.
Il report ha due schede:
- Workflow Issues: Elenca i workflow che usano nodi deprecati, funzionalità rimosse o comportamenti modificati.
- Instance Issues: Segnala variabili d'ambiente e configurazione da aggiornare.
Risolvi ogni problema identificato dal report prima di procedere.
Passo 2: Aggiornare prima all'ultima versione 1.x
Prima di passare a 2.x, aggiorna all'ultima versione 1.x. Questo assicura che tutte le migrazioni intermedie del database vengano eseguite:
docker compose pull # With image set to n8nio/n8n:1-latest or latest 1.x tag
docker compose down && docker compose up -d
Passo 3: Fare il backup di tutto
/home/deploy/n8n/backup-n8n.sh
Questo è il tuo punto di rollback. Se 2.x rompe la configurazione, puoi ripristinare questo backup e restare su 1.x.
Passo 4: Aggiornare a 2.x
Modifica 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
Passo 5: Verificare la migrazione
docker compose logs --tail 100 n8n
Cerca migrazioni completate e assenza di errori.
Testa i workflow segnalati dal report di migrazione. Apri le credenziali per confermare che la decifratura funziona. Esegui alcuni workflow da inizio a fine.
Se qualcosa non funziona, esegui il rollback con la procedura della sezione precedente usando il backup 1.x e il tag dell'immagine 1.x.
Risoluzione dei problemi
pg_dump: error: connection to server failed
Il container PostgreSQL non è in esecuzione. Avvialo con docker compose up -d postgres e attendi che sia pronto prima di eseguire i backup.
Le credenziali appaiono vuote dopo il ripristino
La tua N8N_ENCRYPTION_KEY non corrisponde a quella usata quando le credenziali sono state salvate. Controlla il file .env. Confrontala con la chiave nel gestore di password.
docker exec fallisce con "no such container"
I nomi dei container dipendono dal nome della directory del progetto e dal file compose. Esegui docker ps per trovare il nome reale del container. Modifica la variabile DB_CONTAINER nello script di backup.
Lo script di backup viene eseguito ma l'healthcheck non fa mai ping
Verifica che HEALTHCHECK_URL sia impostato nello script. Testa l'URL manualmente: curl -fsS "your-healthcheck-url". Le regole del firewall potrebbero bloccare le connessioni HTTPS in uscita.
n8n non si avvia dopo l'aggiornamento con errore di migrazione
Controlla i log con docker compose logs n8n. Se l'errore menziona una migrazione specifica, cerca quell'errore nel forum della community n8n. Esegui il rollback se necessario.
rclone sync fallisce con errore di autenticazione
Esegui rclone config reconnect n8n-backup: per aggiornare le credenziali. Verifica che la chiave di accesso e il segreto siano corretti.
Dove si trovano i log:
# 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. Tutti i diritti riservati. Questo contenuto è un'opera originale del team Virtua.Cloud. La riproduzione, ripubblicazione o redistribuzione senza autorizzazione scritta è vietata.
Pronto a provare?
Distribuisci il tuo server in pochi secondi. Linux, Windows o FreeBSD.
Vedi piani VPS