n8n in productie back-uppen en updaten (Docker Compose + PostgreSQL)
Een day-two handleiding voor zelfgehoste n8n: geautomatiseerde PostgreSQL-back-ups, bescherming van de encryptiesleutel, off-server kopieën met rclone, disaster recovery vanaf een nieuwe VPS, veilige Docker Compose-updates, rollback en het migratiepad van 1.x naar 2.x.
Je hebt n8n draaiend op je VPS met Docker Compose en PostgreSQL. Dat was dag één. Dag twee draait om het draaiend houden: geautomatiseerde back-ups, geteste herstelprocedures en veilige updates.
Deze handleiding behandelt alles wat je nodig hebt om een n8n-productie-instantie te beschermen. We bouwen een back-upscript, automatiseren het met cron, kopiëren back-ups van de server af, doorlopen een disaster recovery op een nieuwe VPS en updaten n8n veilig met rollback-ondersteuning. We behandelen ook het migratiepad van 1.x naar 2.x.
Deze handleiding gaat ervan uit dat je onze n8n Docker Compose-installatiehandleiding hebt gevolgd om n8n op te zetten. Je stack draait op Docker Compose met PostgreSQL, een niet-root deploy-gebruiker en een reverse proxy.
Welke data slaat n8n op die back-ups nodig heeft?
n8n slaat vijf componenten op die je samen moet back-uppen. Als er ook maar één ontbreekt, kan het herstel gedeeltelijk of onmogelijk zijn. De PostgreSQL-database bevat je workflows, credentials (versleuteld), uitvoeringsgeschiedenis en gebruikersaccounts. De encryptiesleutel (encryption key) ontsleutelt die credentials. Het Docker-volume slaat aangepaste nodes en binaire data op. Je .env- en docker-compose.yml-bestanden definiëren de runtimeconfiguratie.
| Component | Inhoud | Risico bij verlies | Back-upmethode |
|---|---|---|---|
| PostgreSQL-database | Workflows, versleutelde credentials, uitvoeringsgeschiedenis, gebruikers | Alle data verloren | pg_dump (custom-formaat) |
N8N_ENCRYPTION_KEY |
AES-256-sleutel voor credential-ontsleuteling | Alle opgeslagen credentials worden permanent onherstelbaar | Kopiëren uit .env of containerconfiguratie |
Docker-volume (.n8n) |
Aangepaste nodes, binaire uitvoeringsdata | Aangepaste nodes en geüploade bestanden verloren | Alpine tar-container |
.env-bestand |
Databasewachtwoorden, encryptiesleutel, domeinconfiguratie | Moet handmatig opnieuw aangemaakt worden | Bestandskopie |
docker-compose.yml |
Servicedefinities, volume-mappings, image-tags | Moet handmatig opnieuw aangemaakt worden | Bestandskopie |
Hoe maak je een back-up van de n8n PostgreSQL-database met pg_dump?
Gebruik pg_dump met --format=custom om een gecomprimeerde, herstelbare dump van de n8n-database te maken. Het custom-formaat ondersteunt selectief herstel en parallelle verwerking. Voer de dump uit via de draaiende PostgreSQL-container.
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
Wat dit commando doet: docker exec voert pg_dump uit binnen de PostgreSQL-container. -U n8n is de databasegebruiker. -d n8n is de databasenaam. --format=custom produceert een gecomprimeerde binaire dump die pg_restore selectief kan herstellen. De output wordt omgeleid naar een bestand met tijdstempel op de host.
Controleer of de dump geldig is:
cat /home/deploy/n8n-backups/n8n-db-*.dump | docker exec -i n8n-postgres pg_restore --list | head -20
Omdat pg_restore in de PostgreSQL-container zit, wordt de dump via een pipe naar docker exec -i gestuurd. Je zou een lijst van databaseobjecten moeten zien (tabellen, sequenties, data). Als je een fout of lege output ziet, is de dump mislukt.
Docker-volume back-uppen
Het n8n-datavolume bevat aangepaste nodes en binaire uitvoeringsdata. Maak er een back-up van met een tijdelijke Alpine-container:
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 .
De volumenaam n8n_n8n_data bestaat uit de Docker Compose-projectnaam (n8n, van de directory) plus de volumenaam (n8n_data, uit docker-compose.yml). Voer docker volume ls uit als de jouwe afwijkt.
Wat dit commando doet: Koppelt het n8n-datavolume als alleen-lezen (:ro) in een wegwerp-Alpine-container. De container maakt een gecomprimeerd archief van de volume-inhoud en schrijft het naar de back-updirectory. De container wordt na voltooiing verwijderd (--rm).
Controleer het archief:
tar tzf /home/deploy/n8n-backups/n8n-data-*.tar.gz | head -10
Je zou bestandspaden uit de .n8n-directory moeten zien.
Configuratiebestanden back-uppen
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"
Het .env-bestand bevat je N8N_ENCRYPTION_KEY en het databasewachtwoord. Beperk de rechten tot 600 zodat alleen de back-upgebruiker het kan lezen.
Waarom is de n8n-encryptiesleutel de belangrijkste back-up?
n8n versleutelt elke opgeslagen credential (API-sleutels, OAuth-tokens, databasewachtwoorden) met AES-256 met behulp van de N8N_ENCRYPTION_KEY. Als je deze sleutel verliest, wordt elke credential in je database permanent onherstelbaar. Er is geen resetmechanisme. Geen achterdeur. Je zou elke credential in elke workflow handmatig opnieuw moeten invoeren.
De sleutel wordt expliciet ingesteld in je .env-bestand of automatisch gegenereerd door n8n bij de eerste start en opgeslagen in de container op /home/node/.n8n/config.
Vind je encryptiesleutel:
Als je hem in .env hebt ingesteld:
grep N8N_ENCRYPTION_KEY /home/deploy/n8n/.env
Als n8n hem automatisch heeft gegenereerd (je hebt hem nooit expliciet ingesteld):
docker exec n8n cat /home/node/.n8n/config
Zoek het veld encryptionKey in de JSON-output.
Bewaar de sleutel veilig:
- Kopieer de sleutelwaarde naar een wachtwoordbeheerder (Bitwarden, KeePass, 1Password).
- Zorg dat hij in je
.env-bestand staat alsN8N_ENCRYPTION_KEY=<je-sleutel>. - Je back-upscript kopieert al
.env, maar bewaar de sleutel ook apart. Als je server uitvalt en je back-ups beschadigd zijn, kun je nog steeds credentials herstellen als je de sleutel hebt.
Hoe automatiseer je n8n-back-ups met cron?
Combineer de databasedump, de volume-back-up en de configuratiekopie in één script. Voeg retentieopschoning en een health check-ping toe om fouten op te vangen.
Maak het back-upscript aan:
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."
Stel de rechten in en test:
chmod 750 /home/deploy/n8n/backup-n8n.sh
/home/deploy/n8n/backup-n8n.sh
Controleer of de back-upbestanden zijn aangemaakt:
ls -lh /home/deploy/n8n-backups/daily/
Let op de bestandsgroottes. Een typische n8n-databasedump is 500 KB tot 50 MB, afhankelijk van de uitvoeringsgeschiedenis. Als de dump 0 bytes is, is er iets misgegaan.
Plannen met cron
crontab -e
Voeg deze regel toe om back-ups dagelijks om 03:00 uit te voeren:
0 3 * * * /home/deploy/n8n/backup-n8n.sh >> /home/deploy/n8n-backups/backup.log 2>&1
Wat dit commando doet: Voert het back-upscript elke dag om 3 uur 's nachts uit. Output en fouten worden aan backup.log toegevoegd zodat je problemen kunt diagnosticeren.
Waarschuwingen bij mislukte back-ups
De variabele HEALTHCHECK_URL in het script ondersteunt services zoals Healthchecks.io of een zelfgehoste Uptime Kuma-instantie. Deze services verwachten een ping op regelmatige intervallen. Als de ping stopt (omdat het script is mislukt of de cron niet heeft gedraaid), ontvang je een waarschuwing.
Stel een check in met een periode van 24 uur en een tolerantie van één uur. Als het back-upscript vóór 04:00 geen ping stuurt, word je gewaarschuwd.
Hoe kopieer je n8n-back-ups van de server af met rclone?
Back-ups op dezelfde server als n8n zijn geen echte back-ups. Als de schijf uitvalt, verlies je beide. Gebruik rclone om back-ups naar S3-compatibele objectopslag te kopiëren (Wasabi, Backblaze B2, MinIO of een willekeurige S3-provider).
Installeer rclone:
sudo apt install rclone
Configureer een remote. Dit voorbeeld gebruikt willekeurige S3-compatibele opslag:
rclone config
Volg de interactieve prompts om een remote genaamd n8n-backup aan te maken. Kies "Amazon S3 Compliant Storage Providers" en voer je endpoint, toegangssleutel en geheime sleutel in.
Controleer of de remote werkt:
rclone lsd n8n-backup:
Je zou je bucket in de lijst moeten zien.
Voeg de synchronisatie toe aan je back-upscript. Voeg dit in vóór de health check-pingregel:
# --- 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 voorkomt het uploaden van bestanden die nog worden geschreven. --transfers 4 voert vier parallelle uploads uit.
Hoe controleer je of n8n-back-ups geldig zijn?
Een back-up die je nooit hebt getest, is een back-up die je niet hebt. Voer deze controles periodiek uit.
Integriteit van de databasedump:
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"
Integriteit van het volume-archief:
tar tzf /home/deploy/n8n-backups/daily/n8n-data-*.tar.gz > /dev/null 2>&1 && echo "OK" || echo "CORRUPT"
Checksums voor remote verificatie:
Genereer checksums na de back-up:
sha256sum /home/deploy/n8n-backups/daily/* > /home/deploy/n8n-backups/daily/checksums.sha256
Na het downloaden van de remote opslag, controleer:
sha256sum -c checksums.sha256
Elke regel zou OK moeten tonen. Elke afwijking betekent dat het bestand beschadigd is geraakt tijdens de overdracht.
Hoe herstel je n8n vanuit een back-up op een nieuwe VPS?
Dit is de disaster recovery-procedure. Je hebt je server verloren. Je hebt een nieuwe VPS en je back-upbestanden (van remote opslag of een lokale kopie). Zo krijg je n8n weer draaiend.
1. Een nieuwe VPS inrichten en Docker installeren
Richt een VPS in met Docker en Docker Compose. Volg onze n8n Docker Compose-installatiehandleiding tot de Docker-installatiestap en kom dan hier terug.
2. De deploy-gebruiker en projectdirectory aanmaken
adduser --disabled-password deploy
mkdir -p /home/deploy/n8n /home/deploy/n8n-backups
chown deploy:deploy /home/deploy/n8n /home/deploy/n8n-backups
3. Je back-ups downloaden
Van je remote opslag:
su - deploy
rclone copy n8n-backup:your-bucket-name/n8n/daily /home/deploy/n8n-backups/daily --progress
Of van een andere server via scp:
scp user@old-server:/home/deploy/n8n-backups/daily/* /home/deploy/n8n-backups/daily/
4. Configuratiebestanden herstellen
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
Controleer of de encryptiesleutel aanwezig is:
grep N8N_ENCRYPTION_KEY /home/deploy/n8n/.env
Dit commando moet een regel met je sleutel teruggeven. Als het leeg is of ontbreekt, haal de sleutel uit je wachtwoordbeheerder en voeg hem handmatig toe. Zonder deze sleutel zijn je credentials verloren.
5. Alleen PostgreSQL starten
cd /home/deploy/n8n
docker compose up -d postgres
Wacht tot PostgreSQL is geïnitialiseerd:
docker compose logs -f postgres
Zoek naar database system is ready to accept connections.
6. De database herstellen
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
Wat dit commando doet: Kopieert het dumpbestand naar de container, waarna pg_restore het laadt. --clean verwijdert bestaande objecten vóór het herstel. --if-exists voorkomt fouten als objecten nog niet bestaan.
Je kunt waarschuwingen zien over niet-bestaande objecten. Dat is normaal bij een nieuwe database. Fouten over data of constraints zijn niet normaal.
7. Het Docker-volume herstellen
Docker Compose heeft het volume n8n_n8n_data al aangemaakt toen je PostgreSQL in de vorige stap startte. Herstel erin:
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. De volledige stack starten
docker compose up -d
9. Het herstel controleren
docker compose ps
Alle containers zouden de status running moeten tonen.
Controleer de n8n-logs:
docker compose logs -f n8n
Zoek naar Editor is now accessible via: http://localhost:5678. Geen encryptiesleutelfouten.
Open de n8n-webinterface en controleer:
- Workflows bestaan en komen overeen met wat je eerder had.
- Credentials werken. Open een willekeurige credential en bevestig dat de opgeslagen waarden worden getoond (API-sleutels, wachtwoorden). Als je lege velden of ontsleutelingsfouten ziet, klopt je encryptiesleutel niet.
- Voer een testworkflow uit. Start een eenvoudige workflow om te bevestigen dat de databaseverbinding en de uitvoeringsengine werken.
Test van buiten de server:
curl -s https://your-n8n-domain.com/healthz
Een 200-respons bevestigt dat n8n bereikbaar is en draait.
Hoe update je n8n veilig met Docker Compose?
Het updaten van n8n volgt vier stappen: back-uppen, release notes controleren, nieuwe image pullen en verifiëren. Sla de back-upstap nooit over.
1. Een back-up maken
/home/deploy/n8n/backup-n8n.sh
Dit is verplicht. Als de update iets kapotmaakt, heb je een herstelpunt nodig.
2. Release notes controleren op breaking changes
Lees vóór het pullen van de nieuwe versie de n8n release notes. Let op:
- Databasemigraties (deze draaien automatisch bij het opstarten maar kunnen tijd kosten)
- Verouderde nodes die je workflows gebruiken
- Gewijzigde omgevingsvariabelen
- Minimale PostgreSQL-versievereisten
3. Je huidige versie noteren
docker compose exec n8n n8n --version
Noteer dit. Je hebt het nodig voor een rollback.
4. Pullen en herstarten
Als je docker-compose.yml de tag n8nio/n8n:latest of n8nio/n8n:stable gebruikt:
cd /home/deploy/n8n
docker compose pull
docker compose down
docker compose up -d
Als je een specifieke versie pint (aanbevolen voor productie), bewerk dan eerst docker-compose.yml:
services:
n8n:
image: n8nio/n8n:2.12.3 # Change to the target version
Vervolgens:
docker compose up -d
5. De update controleren
docker compose exec n8n n8n --version
Bevestig dat de versie overeenkomt met wat je verwachtte.
Controleer de logs op migratiefouten:
docker compose logs --tail 50 n8n
Zoek naar Migrations completed en Editor is now accessible via: http://localhost:5678.
Test het API-health-endpoint:
curl -s https://your-n8n-domain.com/healthz
Voer een testworkflow uit via de interface om te bevestigen dat de uitvoering werkt.
Hoe doe je een rollback na een mislukte n8n-update?
Als de update workflows kapotmaakt of de interface niet bereikbaar is, ga terug naar de vorige versie.
1. De kapotte instantie stoppen
cd /home/deploy/n8n
docker compose down
2. De vorige image-tag instellen
Bewerk docker-compose.yml en wijzig de image naar je vorige versie:
services:
n8n:
image: n8nio/n8n:2.11.2 # Your previous working version
3. De database herstellen als migraties zijn uitgevoerd
Als n8n databasemigraties heeft uitgevoerd tijdens de mislukte update, kan het schema zijn gewijzigd. Herstel vanuit je pre-update back-up:
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. De oude versie starten
docker compose up -d
Controleer:
docker compose exec n8n n8n --version
docker compose logs --tail 20 n8n
Daarom back-uppen we vóór elke update. Zonder de pre-update dump kun je na een migratie niet veilig downgraden.
Hoe migreer je n8n van versie 1.x naar 2.x?
n8n 2.0 is uitgebracht in december 2025 met breaking changes. Als je nog op 1.x zit, migreer dan snel. Versie 1.x ontving alleen beveiligingsfixes gedurende drie maanden na de 2.0-release, en dat venster is nu gesloten.
Belangrijke breaking changes in n8n 2.0
| Wijziging | 1.x-gedrag | 2.x-gedrag | Vereiste actie |
|---|---|---|---|
| MySQL/MariaDB-ondersteuning | Ondersteund | Volledig verwijderd | Migreer naar PostgreSQL vóór de upgrade |
| Task runners | Optioneel | Standaard ingeschakeld, apart Docker-image | Gebruik n8nio/runners-image voor externe modus |
| Omgevingsvariabelen in Code node | Toegankelijk | Standaard geblokkeerd | Stel N8N_BLOCK_ENV_ACCESS_IN_NODE=false in indien nodig |
| Start node | Functioneel | Verwijderd | Vervang door specifieke triggernodes |
| Save vs. Publish | Save = deploy | Save en Publish zijn aparte acties | Werk teamworkflows bij |
| Python Code node | Op Pyodide gebaseerd | Natief Python via task runners | Gebruik task runners in externe modus |
ExecuteCommand- en LocalFileTrigger-nodes |
Ingeschakeld | Standaard uitgeschakeld | Schakel expliciet in indien nodig |
CLI-optie --tunnel |
Beschikbaar | Verwijderd | Gebruik in plaats daarvan een reverse proxy |
N8N_CONFIG_FILES |
Ondersteund | Verwijderd | Gebruik omgevingsvariabelen rechtstreeks |
Stap 1: Het migratierapport uitvoeren
De migratierapporthulpmiddel is beschikbaar vanaf n8n 1.121.0. Het identificeert problemen op workflow- en instantieniveau vóór de upgrade.
Ga in de n8n-interface naar Settings > Migration Report. Dit is alleen zichtbaar voor globale beheerders.
Het rapport heeft twee tabbladen:
- Workflow Issues: Toont workflows die verouderde nodes, verwijderde functies of gewijzigd gedrag gebruiken.
- Instance Issues: Signaleert omgevingsvariabelen en configuratie die bijgewerkt moeten worden.
Los elk probleem op dat het rapport identificeert voordat je verdergaat.
Stap 2: Eerst updaten naar de nieuwste 1.x
Voordat je naar 2.x springt, update naar de nieuwste 1.x-versie. Dit zorgt ervoor dat alle tussenliggende databasemigraties worden uitgevoerd:
docker compose pull # With image set to n8nio/n8n:1-latest or latest 1.x tag
docker compose down && docker compose up -d
Stap 3: Alles back-uppen
/home/deploy/n8n/backup-n8n.sh
Dit is je rollbackpunt. Als 2.x je setup kapotmaakt, kun je deze back-up herstellen en op 1.x blijven.
Stap 4: Updaten naar 2.x
Bewerk 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
Stap 5: De migratie controleren
docker compose logs --tail 100 n8n
Zoek naar voltooide migraties en geen fouten.
Test workflows die het migratierapport heeft gemarkeerd. Open credentials om te bevestigen dat ontsleuteling werkt. Voer een paar workflows end-to-end uit.
Als er iets kapot is, voer een rollback uit met de procedure uit de vorige sectie met je 1.x-back-up en de 1.x-image-tag.
Probleemoplossing
pg_dump: error: connection to server failed
De PostgreSQL-container draait niet. Start hem met docker compose up -d postgres en wacht tot hij gereed is voordat je back-ups uitvoert.
Credentials verschijnen leeg na herstel
Je N8N_ENCRYPTION_KEY komt niet overeen met degene die werd gebruikt bij het opslaan van de credentials. Controleer je .env-bestand. Vergelijk met de sleutel in je wachtwoordbeheerder.
docker exec faalt met "no such container"
Containernamen hangen af van je projectdirectorynaam en het compose-bestand. Voer docker ps uit om de werkelijke containernaam te vinden. Pas de variabele DB_CONTAINER in het back-upscript aan.
Back-upscript draait maar de healthcheck pingt nooit
Controleer of HEALTHCHECK_URL is ingesteld in het script. Test de URL handmatig: curl -fsS "your-healthcheck-url". Firewallregels blokkeren mogelijk uitgaand HTTPS.
n8n start niet na update met migratiefout
Controleer de logs met docker compose logs n8n. Als de fout een specifieke migratie noemt, zoek die fout op het n8n communityforum. Voer indien nodig een rollback uit.
rclone sync faalt met authenticatiefout
Voer rclone config reconnect n8n-backup: uit om de inloggegevens te vernieuwen. Controleer of je toegangssleutel en geheime sleutel correct zijn.
Waar de logs staan:
# 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. Alle rechten voorbehouden. Deze inhoud is een origineel werk van het Virtua.Cloud-team. Reproductie, herpublicatie of herdistributie zonder schriftelijke toestemming is verboden.
Klaar om het zelf te proberen?
Deploy uw eigen server in seconden. Linux, Windows of FreeBSD.
Bekijk VPS-aanbod