Docker-volumes back-uppen in 2026: een gids voor zelfhosters

Om een Docker-volume te back-uppen, koppel je het in een tijdelijke container en archiveer je het — je kunt niet zomaar de map onder /var/lib/docker/volumes kopiëren en daarop vertrouwen. De oneliner die voor de meeste volumes werkt, is een wegwerp-Alpine-container die de data met tar in een bestand zet dat jij zelf beheert. De ongemakkelijkere waarheid, en het deel dat de meeste tutorials overslaan, is dat een live databasevolume dat op deze manier is gekopieerd vaak subtiel corrupt is, en dat een back-up die je nooit hebt teruggezet geen back-up is. Deze gids behandelt de exacte commando's, hoe je databases correct aanpakt, hoe je het automatiseert en kopieën naar een externe locatie stuurt, en hoe je bewijst dat de back-up daadwerkelijk werkt.

Hoe back-up je een Docker-volume?

De standaardmethode is het draaien van een kortlevende container die je benoemde volume alleen-lezen koppelt en een gecomprimeerde tarball wegschrijft naar een via bind gekoppelde map op de host. Eén enkel commando regelt dit:

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

Dit start Alpine op, koppelt het volume mydata als /source (alleen-lezen) en schrijft een .tar.gz met tijdstempel naar ./backups op de host. De back-upgids van OneUptime gebruikt ditzelfde alleen-lezen tar-patroon, wat het dichtst in de buurt komt van een gangbare aanpak. Het werkt omdat Dockers eigen documentatie opmerkt dat volumes makkelijker te back-uppen zijn dan bind mounts — de data staat op één beheerde locatie. Voor een stateless app-cache of een bestandsopslag is dit alles wat je nodig hebt. Voor alles wat een database bevat, niet.

Waarom een live volume kopiëren niet genoeg is

Back-ups op bestandssysteemniveau gaan ervan uit dat de bestanden op schijf in een consistente staat verkeren op het moment dat je ze leest. Een draaiende database is dat zelden. Postgres, MySQL en MongoDB bufferen schrijfacties in het geheugen en schrijven ze op hun eigen schema naar schijf, dus het met tar inpakken van een live datamap kan een half geschreven transactie vastleggen of een index die verwijst naar rijen die nog niet zijn geland. Het herstel mislukt dan, of erger nog, laadt stilletjes corrupte data. De vuistregel uit de praktijk is dat databasespecifieke dumps transactioneel consistent zijn, in tegenstelling tot back-ups op bestandssysteemniveau. Je hebt twee veilige opties: de container stoppen vóór de tar (prima voor een thuislab, slecht voor alles wat uptime nodig heeft), of het eigen dump-hulpmiddel van de database gebruiken terwijl die blijft draaien. De tweede is vrijwel altijd het juiste antwoord.

Back-up databases met dumps, niet met tar

Voor een database in een container maak je een logische dump met het native hulpmiddel van de engine en back-up je het dumpbestand in plaats van het ruwe volume. Dit levert een consistente momentopname op, zelfs terwijl de database live verkeer bedient. Voor Postgres geeft pg_dump met --single-transaction een consistente point-in-time-export zonder langdurige locks, volgens de officiële PostgreSQL-documentatie:

docker exec -t my-postgres \
  pg_dump -U postgres --single-transaction mydb \
  | gzip > backups/mydb-$(date +%Y%m%d).sql.gz

MySQL en MariaDB gebruiken mysqldump --single-transaction (consistent voor InnoDB-tabellen); MongoDB gebruikt mongodump. De volgorde is belangrijk wanneer je automatiseert: dump eerst de database en draai daarna je volume- of externe back-up over de map die nu de verse dump bevat. Als je een volledige backend-stack zelf host, geldt dezelfde logica voor de Postgres die eronder draait — de productiegids voor het zelf hosten van Supabase leunt op hetzelfde patroon van 'eerst dumpen, dan opslaan' in plaats van databestanden te kopiëren.

Automatiseer het: tools versus restic

Deze commando's één keer met de hand uitvoeren is makkelijk; eraan denken om ze elke nacht uit te voeren is waar zelfhosters de mist ingaan. Twee volwassen aanpakken automatiseren de hele lus. Een speciaal daarvoor gebouwde container zoals offen/docker-volume-backup regelt planning, rotatie en upload in één image: het back-upt volumes naar S3, WebDAV, Azure Blob, Dropbox, Google Drive of SSH-bestemmingen, met optionele GPG-versleuteling en automatische rotatie van oude back-ups, en kan een container tijdens de run stoppen voor integriteit wanneer je het met een label aangeeft. Het alternatief is restic, dat versleutelde, gededupliceerde, incrementele back-ups biedt naar vrijwel elke backend — een gangbaar patroon houdt --keep-daily 7 --keep-weekly 4 --keep-monthly 6 aan en slaat, dankzij deduplicatie, bij elke nachtelijke run alleen op wat er is veranderd.

Methode	Online (zonder stoppen)?	Externe bestemmingen	Versleuteling	Het beste voor
tar-oneliner	Nee (stoppen voor DB's)	Handmatige kopie	Geen (voeg GPG toe)	Snelle, ad-hoc momentopnames
offen/docker-volume-backup	Optioneel stoppen	S3, WebDAV, Azure, Dropbox, GDrive, SSH	GPG	Volume-back-ups om in te stellen en te vergeten
restic	Ja (met dumps)	S3, B2, SFTP, REST, lokaal	Ingebouwd	Gededupliceerde, geversioneerde historie
DB-dump (pg_dump)	Ja	Pipe naar elk van bovenstaande	Via bestemming	Databases, altijd

Voor de meeste zelfgehoste stacks is de winnende combinatie een nachtelijke pg_dump (of mysqldump) die een restic-run voedt die een versleutelde, gededupliceerde kopie van de machine af duwt.

Pas de 3-2-1-regel toe en ga naar een externe locatie

Een back-up op dezelfde VPS als de data beschermt je tegen een mislukte deploy, niet tegen het overlijden van de server, een gemiste betaling of ransomware. De aloude 3-2-1-regel lost dat op: bewaar 3 kopieën van je data, op 2 verschillende media, met 1 op een externe locatie. In de praktijk betekent dat: het live volume, een lokale back-upmap en één kopie op externe objectopslag. Externe opslag is goedkoop genoeg dat kosten geen excuus zijn. Per juli 2026 kost Hetzners Storage Box BX11 €3.20/maand voor 1 TB via SSH/SFTP — een natuurlijke bestemming voor restic of rsync — terwijl Backblaze B2 ongeveer $7 per TB per maand kost met een S3-compatibele API die zowel restic als offen/docker-volume-backup native spreken. Beide maken van externe back-up een paar euro per maand. Als je na de VPS-prijsstijgingen van 2026 toch al op je rekening let, is objectopslag voor back-ups de laatste plek om op te bezuinigen.

Zet het terug — en test het herstel

Het herstel is het enige deel van een back-up dat er echt toe doet, en het is de stap die vrijwel iedereen overslaat. Om een tar-back-up terug te zetten, stop je de container en pak je het archief vervolgens weer uit in het (lege) volume:

docker run --rm \
  -v mydata:/target \
  -v $(pwd)/backups:/backup:ro \
  alpine tar xzf /backup/mydata-20260717-120000.tar.gz -C /target

Laad een databasedump in een verse container en controleer het schema en het aantal rijen voordat je erop vertrouwt. Plan een echte hersteloefening — maandelijks is redelijk — in een wegwerpcontainer, start de app op tegen de herstelde data en bevestig dat het werkt. Een back-up die je nooit hebt teruggezet is een hoop, geen herstelplan. Bak dit in je workflow zoals je ook een nieuwe machine zou verharden in het veilige eerste uur van een VPS-installatie.

Veelgestelde vragen

Kan ik een Docker-volume back-uppen zonder de container te stoppen?

Ja, met een kanttekening. Voor bestandsopslag en caches is het prima om het volume alleen-lezen te koppelen en het met tar in te pakken terwijl de container draait. Voor databases moet je het live volume niet met tar inpakken — gebruik in plaats daarvan het dump-hulpmiddel van de engine (pg_dump, mysqldump, mongodump), dat een consistente export oplevert zonder de service te stoppen.

Waar worden Docker-volumes eigenlijk opgeslagen?

Op Linux staan benoemde volumes onder /var/lib/docker/volumes/<name>/_data. Je kunt die map technisch gezien kopiëren, maar back-uppen via een container (of een dump voor databases) is veiliger en overdraagbaar tussen hosts, en daarom raadt de documentatie van Docker de aanpak met een volume-mount aan.

Wat is de beste tool om Docker-volumeback-ups te automatiseren?

Voor onbeheerde volume-back-ups met ingebouwde planning, rotatie en cloud-upload is offen/docker-volume-backup de populairste optie met één container. Voor gededupliceerde, versleutelde, geversioneerde historie over veel backends heen is restic de sterkere keuze. Veel opstellingen combineren een nachtelijke databasedump met een restic-push naar een externe locatie.

Hoe vaak moet ik back-uppen?

Stem de frequentie af op hoeveel data je je kunt veroorloven te verliezen. Elke nacht is de gangbare standaard voor zelfgehoste apps; een drukke database kan uurlijkse dumps rechtvaardigen. Wat de frequentie ook is, bewaar meerdere generaties (bijvoorbeeld 7 dagelijkse, 4 wekelijkse, 6 maandelijkse) zodat een corruptie die je laat opmerkt nog herstelbaar is.

Sources

• OneUptime — Docker-volumes back-uppen en herstellen: de alleen-lezen tar-commando's voor back-up en herstel, en het punt dat databasedumps transactioneel consistent zijn waar back-ups op bestandssysteemniveau dat niet zijn.
• Docker Docs — Volumes: het officiële advies dat volumes makkelijker te back-uppen en te migreren zijn dan bind mounts, en waar volumedata wordt opgeslagen.
• PostgreSQL-documentatie — pg_dump: het consistente dump-gedrag van --single-transaction voor live databases.
• offen/docker-volume-backup (GitHub): ondersteunde opslagbackends, GPG-versleuteling, planning, container stoppen tijdens de back-up en rotatie.
• restic: versleutelde, gededupliceerde, incrementele back-ups over meerdere opslagbackends.
• Hetzner Storage Box en Backblaze B2-prijzen: kosten voor externe opslag genoemd (juli 2026).