Volumes: persistente Daten

Docker Volumes: persistente Daten

Container sind nach Design flüchtig. Sie werden gebaut, gestartet, irgendwann gestoppt und gelöscht – und mit ihnen verschwinden alle Daten, die im Container-Filesystem geschrieben wurden. Das ist gut so, denn es macht Container reproduzierbar und einfach zu skalieren. Aber: Reale Anwendungen erzeugen Daten, die nicht verschwinden dürfen – Datenbank-Inhalte, hochgeladene Dateien, generierte Reports. Dafür gibt es Volumes: einen Mechanismus, mit dem Daten über den Container-Lebenszyklus hinaus erhalten bleiben. Wer Volumes nicht versteht, verliert früher oder später Produktionsdaten. Diese Lektion macht aus dieser Falle ein bewusstes Werkzeug.

Die Analogie ist ein Hotelzimmer: Wenn du auscheckst (Container wird gelöscht), wird das Zimmer aufgeräumt – deine Wäsche, deine Zahnbürste, deine Notizen sind weg. Was bleibt, ist dein Schließfach im Tresor in der Lobby (Volume): unabhängig vom Zimmer, persistent. Du kannst nächste Woche in ein anderes Zimmer einchecken (neuer Container) und dein Schließfach ist immer noch da.

1) Das Problem: was passiert ohne Volume?

Schau dir den Lebenszyklus eines Containers mit und ohne Volume direkt im Vergleich an. Du siehst, warum Volumes für jede Anwendung mit persistenten Daten Pflicht sind:

Container-Lebenszyklus – Datenverlust-Demo

Die Lehre aus diesem Test: Wer Datenbanken, hochgeladene Dateien, generierte Logs oder Sitzungsdaten in einem Container betreibt, MUSS ein Volume nutzen. Das ist kein „nice to have", sondern Existenzfrage für die Anwendung. docker rm bedeutet ohne Volume: alles weg, kein Backup im Container-Filesystem.

2) Drei Volume-Typen im Vergleich

Docker kennt drei Mechanismen, um Daten außerhalb des Containers zu speichern. Sie unterscheiden sich grundlegend in Verwaltung, Portabilität und Einsatzgebiet:

Die drei Mount-Typen

1. Named Volume

docker run -v data-vol:/var/lib/db

Docker-verwaltetes Volume mit Namen. Wird auf dem Host unter /var/lib/docker/volumes/ angelegt – Pfad ist Docker-intern, du musst dich nicht drum kümmern.

✓ Portabel, OS-unabhängig
✓ Von Docker verwaltet (Backup, Prune)
✓ Volumetreiber (lokal, NFS, Cloud)
✗ Pfad auf Host schwerer manuell zugänglich

2. Bind Mount

docker run -v /etc/conf:/etc/conf

Konkretes Host-Verzeichnis wird in den Container gemountet. Du kontrollierst den Pfad selbst.

✓ Direkter Host-Zugriff, mit Editor änderbar
✓ Perfekt für Dev (Live-Code-Reload)
✓ Config-Dateien einschleusen
✗ Host-pfad-abhängig (Windows ≠ Linux)
✗ Sicherheitsrisiko bei sensiblen Pfaden

3. tmpfs

docker run --tmpfs /tmp:size=100M

RAM-basierter Mount, kein Disk-Storage. Daten leben nur, solange der Container läuft.

✓ Sehr schnell (RAM-Zugriff)
✓ Sensible Daten landen nicht auf Disk
✗ NICHT persistent – Restart = weg
✗ Verbraucht RAM

Faustregel: Named Volume für persistente Anwendungsdaten (Datenbank, Uploads), Bind Mount für Konfigdateien und Entwicklungsumgebungen (Code live ins Container-Filesystem), tmpfs für temporäre Hochgeschwindigkeits-Speicher (Sessions, Caches, Krypto-Material).

3) Named Volumes im Detail

Named Volumes sind der empfohlene Standard für produktive Anwendungsdaten. Sie sind portabel, von Docker verwaltet und einfach zu sichern. Hier eine komplette Sitzung mit Anlegen, Befüllen, Inspektion und Aufräumen:

Named Volumes – komplette Sitzung

$ docker volume create db-data db-data $ docker volume ls DRIVER VOLUME NAME local db-data $ docker volume inspect db-data [ { "CreatedAt": "2026-05-16T17:15:23Z", "Driver": "local", "Mountpoint": "/var/lib/docker/volumes/db-data/_data", "Name": "db-data", "Scope": "local" } ] # Mit Volume starten $ docker run -d --name db \ -v db-data:/var/lib/postgresql/data \ -e POSTGRES_PASSWORD=secret \ postgres:16 a3f8b2c1e4d5... # Container löschen – Volume bleibt $ docker rm -f db $ docker volume ls DRIVER VOLUME NAME local db-data # lebt noch! # Neuer Container, gleiches Volume → Daten noch da $ docker run -d --name db2 -v db-data:/var/lib/postgresql/data \ -e POSTGRES_PASSWORD=secret postgres:16 # Aufräumen wenn nicht mehr gebraucht $ docker volume rm db-data Error: volume is in use - [a3f8b2c1...] $ docker rm -f db2 && docker volume rm db-data db2 db-data

Beachte: Ein Volume kann nicht gelöscht werden, solange ein Container es nutzt – Schutz gegen versehentlichen Datenverlust. docker volume prune löscht alle ungenutzten Volumes – ein zweischneidiges Werkzeug, das man nur bewusst einsetzen sollte.

4) Bind Mounts – Code-Sharing für Entwicklung

Bind Mounts sind das Werkzeug der Wahl in Entwicklungsumgebungen. Klassisches Setup: Du editierst Code auf deinem Laptop, der Container sieht die Änderungen sofort – ohne dass du das Image neu bauen musst. Sehr produktiv, aber für Produktion nicht geeignet (Host-Pfad-Abhängigkeit, Sicherheit).

Bind Mounts – Dev-Workflow mit Live-Code

$ pwd /home/alice/projects/myapp $ ls server.js package.json public/ src/ # Aktuelles Verzeichnis als Bind Mount ins Container-/app $ docker run -d --name dev \ -v $(pwd):/app \ -p 3000:3000 \ node:20-alpine \ sh -c "cd /app && npm install && npm run dev" # Jetzt Datei lokal editieren: $ echo "console.log('hello')" >> server.js # Container sieht Änderung SOFORT (nodemon reload) $ docker logs -f dev [nodemon] restarting due to changes... [nodemon] starting `node server.js` Server running on port 3000 hello # Read-Only-Variante (Container kann nichts schreiben) $ docker run -v $(pwd)/config:/etc/nginx/conf.d:ro nginx ^^^ read-only

Das :ro-Suffix macht den Mount read-only – sehr wichtig, wenn du Konfigurationsdateien einschleust, die der Container nicht verändern soll. So vermeidest du, dass ein kompromittierter Container deine Host-Konfiguration manipuliert. Für sensible Host-Pfade (/etc/passwd, /var/run/docker.sock) gilt: niemals in Bind-Mounts geben – das ist eine der häufigsten Container-Eskalations-Schwachstellen, siehe Docker-Sicherheit.

5) Anonymous Volumes und VOLUME-Anweisung

Es gibt eine vierte Variante, die häufiger ist, als man denkt: Anonymous Volumes. Sie entstehen automatisch, wenn ein Image im Dockerfile eine VOLUME-Anweisung hat. Beispiel: Das offizielle Postgres-Image hat VOLUME /var/lib/postgresql/data drin – wenn du den Container ohne -v startest, legt Docker trotzdem ein anonymes Volume an. Das ist gut (Daten sind nicht im Container-FS), aber gefährlich: Das Volume hat einen zufälligen Hash-Namen, und beim Container-Restart bekommst du leicht ein neues.

Konsequenz: immer explizit ein Named Volume oder Bind Mount mappen, niemals auf das Anonymous Volume vertrauen. Probier es aus:

Anonymous Volume – die Falle

$ docker run -d --name db1 -e POSTGRES_PASSWORD=x postgres:16 $ docker volume ls DRIVER VOLUME NAME local f8a2c1e4d5b7a9c0d1e2f3a4b5c6d7e8f9a0b1c2 ← Anonymous $ docker rm -f db1 $ docker run -d --name db2 -e POSTGRES_PASSWORD=x postgres:16 $ docker volume ls DRIVER VOLUME NAME local f8a2c1e4d5b7a9c0d1e2f3a4b5c6d7e8f9a0b1c2 ← alt, verwaist! local a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 ← neu, leer # db2 hat KEINEN Zugriff auf die Daten von db1 # Volumes sammeln sich an und müssen manuell aufgeräumt werden

Genau wegen dieses Verhaltens ist docker volume prune ein wichtiger Maintenance-Befehl: er löscht alle Volumes, die nicht mehr von einem Container referenziert werden. Aber Vorsicht – wer das in einer Datenbank-Umgebung ohne Backup ausführt, kann sich von wertvollen Daten verabschieden. Mehr zur Datensicherung in Backup-Arten.

6) Volumes mit Containern teilen

Ein Volume kann von mehreren Containern gleichzeitig genutzt werden – sehr nützlich für Sidecar-Patterns, Log-Sammler oder Web/Worker-Setups. Beispiel: Ein Web-Container schreibt Uploads in ein Volume, ein Worker-Container liest aus demselben Volume und verarbeitet die Dateien:

Volume zwischen Containern teilen

$ docker volume create uploads # Web-Container schreibt Uploads $ docker run -d --name web -v uploads:/app/uploads -p 80:80 myapp/web # Worker-Container liest sie $ docker run -d --name worker -v uploads:/data myapp/worker # Backup-Container greift auch zu $ docker run --rm -v uploads:/source -v $(pwd):/backup \ alpine tar -czf /backup/uploads-$(date +%F).tar.gz -C /source . # Sauberer Backup-Trick: temporärer Alpine-Container mountet beide # Volumes und packt alle Daten in ein TAR auf dem Host

Wichtig bei geteilten Volumes: Achte auf Locks und Concurrency. Zwei Container, die gleichzeitig in dieselbe Datei schreiben, können sich Daten überschreiben oder Korruption verursachen. Datenbanken sollten in der Regel nicht dasselbe Volume teilen – sie haben eigene Mechanismen für Cluster-Replikation. Mehr in Deadlocks & Konkurrenz.

7) Storage-Treiber und Cloud-Volumes

Standardmäßig legt Docker Named Volumes als lokale Verzeichnisse auf dem Host an (Treiber local). Aber es gibt austauschbare Volume Driver für andere Backends:

Treiber	Storage	Einsatz
`local`	Host-Filesystem	Standard, Single-Host-Setups
`local-persist`	Host, persistenter Pfad	Mehr Kontrolle als Standard-local
`nfs` / `cifs`	Netzwerk-Share	Volume auf NAS, mehrere Hosts
`rexray` / `flocker`	Cluster-Storage	Container-Migration zwischen Hosts
`aws-ebs`, `azure-disk`, `gce-pd`	Cloud-Block-Storage	Container in der Cloud, persistente Daten

In Kubernetes-Setups wird das Konzept generalisiert zu PersistentVolumes und PersistentVolumeClaims – die Anwendung deklariert, was sie braucht (z. B. „10 GB SSD"), das Cluster sucht passendes Volume. Diese Abstraktion ist eine der mächtigsten Eigenschaften moderner Container-Orchestrierung, weil sie Anwendung und Storage entkoppelt – die App weiß nicht, dass ihre Daten auf AWS EBS, Azure Managed Disk oder lokalem NFS liegen.

Zusammenfassung

Container-Filesysteme sind flüchtig – beim Löschen sind alle Daten weg. Volumes sind der Mechanismus für persistente Daten. Drei Typen: Named Volume (von Docker verwaltet, portabel, Standard für Produktion), Bind Mount (konkretes Host-Verzeichnis, ideal für Dev und Config-Files), tmpfs (RAM-basiert, nicht persistent, schnell). Befehle: docker volume create/ls/inspect/rm/prune; Mount-Syntax: -v name:/pfad für Named, -v /host:/container für Bind, --tmpfs /pfad für tmpfs. Anonymous Volumes entstehen aus VOLUME-Anweisungen im Dockerfile – ohne explizites Mapping leicht Datenverlust durch verwaiste Volumes. Volumes können zwischen Containern geteilt werden (Sidecar-Pattern, Backup-Container). Volume-Treiber erlauben Cloud- und Netzwerk-Storage (AWS EBS, NFS, CIFS) – in Kubernetes abstrahiert als PersistentVolumeClaims. Sicherheits-Hinweis: nie sensible Host-Pfade wie /var/run/docker.sock in Bind-Mounts geben. Read-only mit Suffix :ro.