Docker-volumes back-uppen en herstellen op een VPS

12 min leestijd·Matthieu·cronrclones3mysqlpostgresqlbackupdocker-composedocker|

Drie back-upstrategieën voor Docker-volumes op een VPS: tar-snapshots, database-native dumps en geautomatiseerde versleutelde back-ups met offen/docker-volume-backup. Inclusief cron-planning, off-site kopieën naar S3 met rclone en een volledige hersteltest op een nieuwe server.

Benoemde Docker-volumes bevatten je productiedata: databases, uploads, configuratiestatus. De containers zijn wegwerpbaar. De volumes niet. Als een schijf uitvalt of een migratie misgaat, zijn het de volumes die je terug nodig hebt.

Deze handleiding behandelt drie back-upstrategieën, automatiseert ze met cron, verstuurt kopieën van de server af met rclone, en bewijst vervolgens dat het herstel werkt door alles opnieuw op te bouwen op een verse VPS. Als je je herstel nooit hebt getest, heb je geen back-ups.

Wat je leert:

  • Tar-gebaseerde volume-snapshots (simpel, universeel)
  • Database-native dumps met pg_dump en mysqldump (consistent, geen downtime)
  • Geautomatiseerde versleutelde back-ups met offen/docker-volume-backup (gepland, S3-klaar)
  • Cron-automatisering met retentiebeleid
  • Off-site kopieën naar S3-compatibele opslag via rclone
  • Volledig disaster recovery herstel op een verse VPS

Vereisten

Je hebt een VPS nodig met Debian 12 of Ubuntu 24.04 waarop Docker en Docker Compose v2 zijn geïnstalleerd. Deze handleiding gaat ervan uit dat je een draaiende Compose-stack hebt met minstens één benoemd volume. Als je dat eerst moet opzetten, zie onze handleiding over Docker Compose met meerdere services op een VPS.

Controleer je installatie:

docker --version
# Docker version 28.x or newer
docker compose version
# Docker Compose version v2.x or newer

Bekijk je bestaande volumes:

docker volume ls

De uitvoer toont elk benoemd volume op het systeem. Identificeer welke belangrijke data bevatten. Gebruik docker system df -v om te zien hoeveel ruimte elk volume inneemt. Dit helpt bij het inschatten van back-upgroottes en opslagbehoeften.

Maak een back-updirectory aan met beperkte rechten:

mkdir -p /opt/backups/docker
chmod 700 /opt/backups/docker

Alleen root kan deze directory lezen. Back-ups bevatten vaak databasecredentials, sessietokens of gebruikersdata.

Hoe maak ik een back-up van Docker-volumes op een VPS?

Er zijn drie strategieën, elk met andere afwegingen. Kies op basis van wat je volumes bevatten en hoeveel downtime je kunt tolereren.

Methode Downtime Dataconsistentie Automatisering Versleuteling Geschikt voor
Tar-snapshot Kort (container gestopt) Bestandssysteemniveau Handmatig of cron-script Nee (voeg GPG apart toe) Statische bestanden, uploads, config
Database-dump Geen Transactieconsistent Handmatig of cron-script Nee (voeg GPG apart toe) PostgreSQL, MySQL, MariaDB
offen/docker-volume-backup Optioneel (configureerbaar) Bestandssysteemniveau Ingebouwde scheduler Ingebouwde GPG Elk volume, hands-off operatie

Hoe maak ik een tar-back-up van een Docker-volume?

Stop de container die het volume gebruikt, start een tijdelijke Alpine-container om de volume-inhoud te tarren, en herstart daarna. Dit duurt seconden voor de meeste volumes en werkt met elk datatype.

1. Stop de container die naar het volume schrijft:

# Replace "app" with your service name from docker-compose.yml
docker compose stop app

Het stoppen van de schrijver voorkomt gedeeltelijke schrijfacties tijdens het archiveren. Voor read-only volumes of statische bestanden kun je deze stap overslaan.

2. Maak het tar-archief:

docker run --rm \
  -v myapp_data:/source:ro \
  -v /opt/backups/docker:/backup \
  alpine tar czf /backup/myapp_data-$(date +%Y%m%d-%H%M%S).tar.gz -C /source .

Wat dit doet: start een wegwerp-Alpine-container, mount je volume als read-only op /source, mount de back-updirectory op /backup, en maakt een gzip-gecomprimeerd tar-archief. De --rm flag verwijdert de container als hij klaar is. De :ro flag voorkomt dat het back-upproces per ongeluk naar je data schrijft.

3. Herstart de container:

docker compose start app

4. Controleer het archief:

ls -lh /opt/backups/docker/myapp_data-*.tar.gz

De output toont het archief moeten zien met een redelijke bestandsgrootte. Een volume van 500 MB comprimeert doorgaans tot 60-120 MB, afhankelijk van het datatype.

Bekijk de archiefinhoud om te bevestigen dat de bestanden aanwezig zijn:

tar tzf /opt/backups/docker/myapp_data-20260319-120000.tar.gz | head -20

Let goed op: de paden moeten beginnen met ./ (geen voorafgaande directorynaam). Dit komt doordat we -C /source . gebruikten in het tar-commando. Dit is belangrijk bij het herstellen.

Hoe maak ik een back-up van een PostgreSQL-database in Docker?

Gebruik pg_dump binnen de draaiende container. Dit produceert een transactieconsistente dump zonder de database te stoppen. Het custom-formaat (-Fc) comprimeert de uitvoer en ondersteunt selectief herstel.

docker compose exec -T postgres pg_dump \
  -U "$POSTGRES_USER" \
  -Fc \
  --no-owner \
  --no-acl \
  mydb > /opt/backups/docker/mydb-$(date +%Y%m%d-%H%M%S).dump

Wat dit doet: exec -T voert het commando uit in de draaiende postgres-container zonder een TTY toe te wijzen (vereist voor het pipen van uitvoer). -Fc selecteert het custom-formaat, dat gecomprimeerd is en pg_restore ondersteunt. --no-owner en --no-acl maken de dump overdraagbaar tussen verschillende databasegebruikers.

De variabele $POSTGRES_USER moet uit je omgevingsbestand komen, niet hardcoded zijn. Als je Compose-stack een env-bestand gebruikt:

source /opt/myapp/.env
docker compose exec -T postgres pg_dump \
  -U "$POSTGRES_USER" \
  -Fc \
  --no-owner \
  --no-acl \
  "$POSTGRES_DB" > /opt/backups/docker/"$POSTGRES_DB"-$(date +%Y%m%d-%H%M%S).dump

Controleer de dump door deze door de pg_restore van de container te halen:

docker compose exec -T postgres pg_restore --list < /opt/backups/docker/mydb-20260319-120000.dump | head -10

Dit print de inhoudsopgave zonder iets te herstellen. Als het bestand beschadigd is, geeft pg_restore een fout. We gebruiken docker compose exec -T omdat pg_restore in de container zit, niet op de host (tenzij je postgresql-client apart installeert).

Hoe maak ik een back-up van een MySQL-database in Docker?

Gebruik mysqldump met --single-transaction voor InnoDB-tabellen. Dit geeft een consistente snapshot zonder de database te vergrendelen.

docker compose exec -T mysql mysqldump \
  -u root \
  -p"$MYSQL_ROOT_PASSWORD" \
  --single-transaction \
  --routines \
  --triggers \
  mydb > /opt/backups/docker/mydb-$(date +%Y%m%d-%H%M%S).sql

De -p flag heeft geen spatie voor het wachtwoord. --single-transaction gebruikt een consistente leesbewerking voor InnoDB-tabellen. --routines en --triggers nemen stored procedures en triggers op die mysqldump standaard overslaat.

Controleer dat de dump niet leeg is en eindigt met de voltooiingsmarkering:

tail -5 /opt/backups/docker/mydb-20260319-120000.sql

De output toont -- Dump completed on YYYY-MM-DD HH:MM:SS moeten zien. Als het bestand afgekapt of leeg is, is de dump mislukt.

Hoe automatiseer ik Docker-volume-back-ups met offen/docker-volume-backup?

offen/docker-volume-backup draait als sidecar-container in je Compose-stack. Het maakt back-ups van gemounte volumes volgens een schema, versleutelt de archieven optioneel met GPG, en kan direct uploaden naar S3-compatibele opslag. Het kan ook containers stoppen tijdens de back-up om consistentie te garanderen.

Voeg de back-upservice toe aan je docker-compose.yml:

services:
  # ... your existing services ...

  backup:
    image: offen/docker-volume-backup:v2.47.2
    restart: unless-stopped
    env_file:
      - ./backup.env
    volumes:
      - myapp_data:/backup/myapp_data:ro
      - myapp_db:/backup/myapp_db:ro
      - /opt/backups/docker:/archive
      - /var/run/docker.sock:/var/run/docker.sock
    labels:
      - docker-volume-backup.stop-during-backup=false

Wat dit doet: mount elk te back-uppen volume als read-only onder /backup/, mount /archive voor lokale back-upopslag, en mount de Docker-socket zodat de tool containers kan stoppen en herstarten wanneer dat is geconfigureerd. De image-tag v2.47.2 fixeert de versie. Gebruik niet latest in productie.

Beveiligingsopmerking: het mounten van de Docker-socket geeft de back-upcontainer volledige controle over Docker op de host. Dit is vereist voor de stop-during-backup-functie. Als je die functie niet nodig hebt, kun je het read-only mounten (/var/run/docker.sock:/var/run/docker.sock:ro), waardoor de tool containerlabels kan lezen maar geen containers kan stoppen of starten.

Maak het omgevingsbestand aan met beperkte rechten:

touch /opt/myapp/backup.env
chmod 600 /opt/myapp/backup.env

# /opt/myapp/backup.env
BACKUP_CRON_EXPRESSION=0 3 * * *
BACKUP_RETENTION_DAYS=7
BACKUP_COMPRESSION=gz
BACKUP_FILENAME=backup-%Y%m%dT%H%M%S.tar.gz

# GPG encryption (generate a strong passphrase)
GPG_PASSPHRASE=your-generated-passphrase-here

# S3-compatible storage (optional, see rclone section for alternative)
# AWS_S3_BUCKET_NAME=my-backups
# AWS_S3_PATH=myapp
# AWS_ENDPOINT=s3.eu-central-1.amazonaws.com
# AWS_ACCESS_KEY_ID=
# AWS_SECRET_ACCESS_KEY=

Genereer de GPG-wachtwoordzin:

openssl rand -base64 32

Bewaar deze wachtwoordzin op een veilige plek buiten de server. Als je hem kwijtraakt, zijn de versleutelde back-ups onherstelbaar.

Als je wilt dat de back-uptool specifieke containers stopt tijdens de back-up voor bestandssysteemconsistentie, voeg dan een label toe aan die services:

services:
  app:
    # ... your config ...
    labels:
      - docker-volume-backup.stop-during-backup=true

Start de back-upservice:

docker compose up -d backup

Controleer of hij draait:

docker compose logs backup

De output toont een logregel moeten zien die het cron-schema bevestigt. Wacht op de eerste geplande uitvoering, of trigger handmatig een back-up:

docker compose exec backup backup

Controleer of het archief is verschenen:

ls -lh /opt/backups/docker/

Hoe plan ik Docker-back-ups met cron?

Voor tar-gebaseerde en database-dump-strategieën handelt een shellscript met cron de planning en retentie af. De offen-tool heeft zijn eigen scheduler; sla deze sectie over als je alleen die gebruikt.

Maak het back-upscript:

touch /opt/backups/docker-backup.sh
chmod 700 /opt/backups/docker-backup.sh

#!/usr/bin/env bash
# /opt/backups/docker-backup.sh
# Backs up Docker volumes and databases, removes old archives.

set -euo pipefail

BACKUP_DIR="/opt/backups/docker"
RETENTION_DAYS=7
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
COMPOSE_DIR="/opt/myapp"

# Load database credentials from env file
source "${COMPOSE_DIR}/.env"

cd "$COMPOSE_DIR"

# --- Tar backup of application data volume ---
docker compose stop app
docker run --rm \
  -v myapp_data:/source:ro \
  -v "${BACKUP_DIR}":/backup \
  alpine tar czf "/backup/myapp_data-${TIMESTAMP}.tar.gz" -C /source .
docker compose start app

# --- PostgreSQL dump (no downtime) ---
docker compose exec -T postgres pg_dump \
  -U "$POSTGRES_USER" \
  -Fc --no-owner --no-acl \
  "$POSTGRES_DB" > "${BACKUP_DIR}/${POSTGRES_DB}-${TIMESTAMP}.dump"

# --- Retention: delete backups older than N days ---
find "$BACKUP_DIR" -type f -name "*.tar.gz" -mtime +${RETENTION_DAYS} -delete
find "$BACKUP_DIR" -type f -name "*.dump" -mtime +${RETENTION_DAYS} -delete

echo "[$(date -Iseconds)] Backup completed successfully"

Controleer of het script foutloos draait:

/opt/backups/docker-backup.sh

Controleer de uitvoerbestanden:

ls -lh /opt/backups/docker/

Voeg een cron-entry toe die dagelijks om 03:00 draait en de uitvoer logt:

crontab -e

0 3 * * * /opt/backups/docker-backup.sh >> /var/log/docker-backup.log 2>&1

De 2>&1 stuurt stderr naar hetzelfde logbestand, zodat fouten worden vastgelegd. Controleer het logbestand na de eerste uitvoering:

cat /var/log/docker-backup.log

Als het script faalt, slikt cron de fout stilletjes in tenzij je de uitvoer redirect. Om e-mailwaarschuwingen bij fouten te krijgen, voeg deze wrapper toe:

0 3 * * * /opt/backups/docker-backup.sh >> /var/log/docker-backup.log 2>&1 || echo "Docker backup failed on $(hostname)" | mail -s "BACKUP FAILED" you@example.com

Dit vereist mailutils of een vergelijkbaar pakket. Pas het ontvangstadres aan.

Hoe kopieer ik Docker-back-ups naar S3-compatibele opslag met rclone?

Lokale back-ups beschermen tegen applicatiefouten. Ze beschermen niet tegen schijffouten of een gecompromitteerde server. Je hebt off-site kopieën nodig. rclone werkt met elke S3-compatibele opslag: AWS S3, Backblaze B2, Wasabi, MinIO, OVH Object Storage, Scaleway en andere.

Installeer rclone:

apt update && apt install -y rclone

Configureer een S3-compatibele remote:

rclone config

Volg de interactieve prompts:

  1. n voor een nieuwe remote
  2. Noem het s3backup
  3. Kies s3 (Amazon S3 Compliant Storage Providers)
  4. Selecteer je provider (of "Any other S3 compatible provider")
  5. Voer je access key en secret key in
  6. Stel de regio en endpoint-URL van je provider in
  7. Laat overige opties op de standaardwaarden staan

Controleer of de remote werkt:

rclone lsd s3backup:

Dit toont je buckets. Als het faalt, kloppen je credentials of endpoint niet.

Maak een bucket voor back-ups (als je provider dit via rclone ondersteunt):

rclone mkdir s3backup:my-docker-backups

Synchroniseer je lokale back-updirectory naar de bucket:

rclone sync /opt/backups/docker s3backup:my-docker-backups/$(hostname)/ \
  --transfers 4 \
  --checkers 8 \
  --log-file /var/log/rclone-backup.log \
  --log-level INFO

Wat dit doet: sync laat de remote overeenkomen met de lokale directory. Lokaal verwijderde bestanden (door retentie) worden ook remote verwijderd. Het $(hostname) prefix scheidt back-ups als je meerdere servers hebt.

Controleer de upload:

rclone ls s3backup:my-docker-backups/$(hostname)/

De output toont je back-upbestanden moeten zien met groottes die overeenkomen met de lokale kopieën.

Voeg rclone sync toe aan het back-upscript of als aparte cron-entry die na de back-up draait:

30 3 * * * rclone sync /opt/backups/docker s3backup:my-docker-backups/$(hostname)/ --transfers 4 --log-file /var/log/rclone-backup.log --log-level INFO

Dit draait om 03:30 en geeft de back-upjob van 03:00 tijd af te ronden.

Bescherm de rclone-configuratie: deze bevat je S3-credentials.

chmod 600 ~/.config/rclone/rclone.conf
ls -la ~/.config/rclone/rclone.conf

De output toont rechten -rw------- moeten zien. Alleen root kan dit bestand lezen.

Moet ik containers stoppen voor het back-uppen van Docker-volumes?

Dit hangt af van wat het volume bevat. Dit verkeerd inschatten is de meest voorkomende oorzaak van beschadigde back-ups.

Databases (PostgreSQL, MySQL, MongoDB): tar nooit een draaiend databasevolume. De bestanden op schijf vertegenwoordigen een lopende transactiestatus. Een tar van deze bestanden is als het fotokopiëren van een boek terwijl iemand de hoofdstukken herschrijft. Het resultaat is intern inconsistent. Gebruik in plaats daarvan pg_dump, mysqldump of mongodump. Deze tools produceren een transactieconsistente snapshot terwijl de database blijft draaien.

Applicatiedata (uploads, statische bestanden, config): tar is veilig als de applicatie een korte stop tolereert. Als de app continu schrijft en je hem niet kunt stoppen, kan het tar-archief gedeeltelijk geschreven bestanden bevatten. Voor de meeste webapplicaties is een stop van 2 seconden tijdens een back-up om 3 uur 's nachts acceptabel.

Redis, key-value stores: Redis schrijft periodiek RDB-snapshots naar schijf. Trigger een BGSAVE voor het tarren van het volume en wacht tot het klaar is. Dit geeft je een consistente snapshot zonder Redis te stoppen.

docker compose exec redis redis-cli BGSAVE
# Wait a few seconds
docker compose exec redis redis-cli LASTSAVE

De veilige standaard: bij twijfel, stop de container, maak de back-up, herstart. Korte downtime is beter dan beschadigde back-ups.

Hoe herstel ik Docker-volumes op een nieuwe VPS?

Dit is de procedure die bewijst dat je back-ups werken. Installeer Docker op een verse server, breng de back-upbestanden over, maak volumes opnieuw aan, herstel data, en controleer of de applicatie draait.

1. Installeer Docker op de nieuwe VPS

apt update && apt install -y ca-certificates curl
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
  https://download.docker.com/linux/debian $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
  | tee /etc/apt/sources.list.d/docker.list > /dev/null

apt update && apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Controle:

docker --version && docker compose version

2. Breng back-upbestanden over naar de nieuwe server

Vanaf je lokale machine of de oude server:

rsync -avz --progress /opt/backups/docker/ root@NEW_SERVER_IP:/opt/backups/docker/

Of download van S3:

# On the new server, install and configure rclone first
apt install -y rclone
# Re-run rclone config with the same credentials
rclone copy s3backup:my-docker-backups/OLD_HOSTNAME/ /opt/backups/docker/

Controleer of de bestanden zijn aangekomen:

ls -lh /opt/backups/docker/

3. Kopieer je Compose- en env-bestanden

rsync -avz /opt/myapp/ root@NEW_SERVER_IP:/opt/myapp/

Of herstel ze vanuit je Git-repository. Je docker-compose.yml en .env zouden geversiebeheerd moeten zijn. Het .env-bestand zou in .gitignore moeten staan en apart geback-upt worden.

4. Herstel het tar-gebaseerde volume

# Create the volume (Docker Compose will also do this on first `up`,
# but creating it explicitly lets us restore data before starting services)
docker volume create myapp_data

# Restore from archive
docker run --rm \
  -v myapp_data:/target \
  -v /opt/backups/docker:/backup:ro \
  alpine sh -c "cd /target && tar xzf /backup/myapp_data-20260319-030000.tar.gz"

Wat dit doet: maakt het benoemde volume aan en draait vervolgens een tijdelijke container die het archief erin uitpakt. De back-updirectory is read-only gemount om ongelukken te voorkomen.

Controleer de herstelde data:

docker run --rm -v myapp_data:/data:ro alpine ls -la /data/

De output toont dezelfde bestanden moeten zien als in het originele volume.

5. Herstel de PostgreSQL-database

Start alleen de databasecontainer:

cd /opt/myapp
docker compose up -d postgres

Wacht tot hij gereed is:

docker compose logs -f postgres
# Wait until you see "database system is ready to accept connections"

Herstel de dump:

docker compose exec -T postgres pg_restore \
  -U "$POSTGRES_USER" \
  -d "$POSTGRES_DB" \
  --clean \
  --if-exists \
  --no-owner \
  --no-acl \
  < /opt/backups/docker/mydb-20260319-030000.dump

Wat dit doet: --clean verwijdert bestaande objecten voor het opnieuw aanmaken. --if-exists voorkomt fouten als de objecten nog niet bestaan. Dit maakt het herstel idempotent.

Controleer de data:

docker compose exec postgres psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c "\dt"

De output toont je tabellen moeten zien. Voer een snelle rijtelling uit op een bekende tabel:

docker compose exec postgres psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c "SELECT count(*) FROM your_table;"

6. Start alle services en controleer

docker compose up -d

Controleer of alle containers draaien:

docker compose ps

Elke service zou Up of running moeten tonen. Als een container in een herstartlus zit, controleer de logs:

docker compose logs --tail 50 service_name

Test de applicatie van buiten de server. Vanaf je lokale machine:

curl -I http://NEW_SERVER_IP:PORT

De output toont een geldige HTTP-respons moeten krijgen. Als de app een health-check-endpoint heeft, gebruik dat:

curl http://NEW_SERVER_IP:PORT/health

Voor meer over health checks, zie onze handleiding over Docker Compose resource limits en health checks.

Hoe controleer ik of een Docker-volume-back-up geldig is?

Een back-up die je nooit hebt getest, is een risico. Voer deze controles regelmatig uit, niet alleen tijdens disaster recovery.

Controleer archiefintegriteit:

# For tar.gz files
gzip -t /opt/backups/docker/myapp_data-20260319-030000.tar.gz && echo "OK" || echo "CORRUPT"

Controleer archiefinhoud:

tar tzf /opt/backups/docker/myapp_data-20260319-030000.tar.gz | wc -l

Vergelijk het bestandsaantal met een bekende goede back-up. Een plotselinge daling in het aantal bestanden duidt op een probleem.

Test herstel naar een wegwerpvolume:

docker volume create test_restore
docker run --rm \
  -v test_restore:/target \
  -v /opt/backups/docker:/backup:ro \
  alpine sh -c "cd /target && tar xzf /backup/myapp_data-20260319-030000.tar.gz"

# Inspect the restored data
docker run --rm -v test_restore:/data:ro alpine ls -la /data/

# Clean up
docker volume rm test_restore

Controleer een database-dump:

docker compose exec -T postgres pg_restore --list < /opt/backups/docker/mydb-20260319-030000.dump | wc -l

Als dit een aantal objecten retourneert (tabellen, indexen, sequences), is de dump leesbaar. Als het een fout geeft, is het bestand beschadigd.

Genereer checksums voor langetermijnopslag:

sha256sum /opt/backups/docker/*.tar.gz /opt/backups/docker/*.dump > /opt/backups/docker/checksums-$(date +%Y%m%d).sha256

Upload het checksumbestand samen met de back-ups. Voor het herstellen, controleer:

sha256sum -c /opt/backups/docker/checksums-20260319.sha256

Probleemoplossing

"Permission denied" bij het aanmaken van het tar-archief: De tijdelijke container draait standaard als root, dus dit betekent meestal dat de back-updirectory niet bestaat of verkeerde rechten heeft. Voer ls -la /opt/backups/ uit en controleer of de docker-subdirectory bestaat met rechten 700.

pg_dump/pg_restore hangt: Je bent waarschijnlijk de -T flag vergeten in docker compose exec. Zonder -T probeert exec een TTY toe te wijzen, wat blokkeert bij het pipen van uitvoer. Gebruik docker compose exec -T.

Back-upbestanden zijn 0 bytes: De container schreef naar een ander pad dan verwacht. Controleer of de volumenaam in docker volume ls overeenkomt met wat je gebruikte in de -v flag. Benoemde volumes zijn hoofdlettergevoelig.

rclone sync timeout: Grote initiële synchronisaties kunnen standaard-timeouts overschrijden. Voeg --timeout 30m en --retries 3 toe aan het rclone-commando.

offen/docker-volume-backup draait niet volgens schema: Controleer de syntaxis van BACKUP_CRON_EXPRESSION. De tool gebruikt standaard 5-velden cron-syntaxis. Voer docker compose logs backup uit en zoek naar parse-fouten.

Herstelde database heeft verkeerde rechten: Je gebruikte een dump zonder --no-owner. De dump probeert eigenaarschap in te stellen op de oorspronkelijke gebruiker, die mogelijk niet bestaat op de nieuwe server. Maak de dump opnieuw met --no-owner --no-acl of voer REASSIGN OWNED BY old_user TO new_user; uit in psql.

Verder lezen

  • Volledige Docker-productieconfiguratie
  • Health checks die bevestigen dat services leven na herstel
  • Docker CLI-basics

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?

Implementeer Docker met geautomatiseerde backups op uw VPS.

Bekijk VPS-aanbod