Volumes vs Bind Mounts vs tmpfs - was man wann in Docker verwendet

Docker bietet drei verschiedene Speichertypen – wer den falschen wählt, hat früher oder später ein Problem.

Named Volumes

Named Volumes werden vollständig von Docker verwaltet. Docker legt sie unter /var/lib/docker/volumes/ ab und kümmert sich um Lebenszyklus und Backups.

# Volume anlegen und nutzen
docker volume create mydata
docker run -v mydata:/var/lib/postgresql/data postgres:16

Ideal für: Datenbanken, persistente Anwendungsdaten, alles was zwischen Container-Neustarts überleben muss. Volumes sind portabel – sie funktionieren plattformübergreifend ohne Pfadprobleme.

Tücke: Ein versehentliches docker volume rm mydata löscht die Daten unwiederbringlich. Immer vorher sichern.

Bind Mounts

Bind Mounts binden ein Verzeichnis vom Host direkt in den Container. Änderungen auf dem Host sind sofort im Container sichtbar – und umgekehrt.

# Aktuelles Verzeichnis als Bind Mount
docker run -v $(pwd)/app:/var/www/html php:8.3-apache

# Read-only Config einbinden
docker run -v /etc/myapp/config.yml:/app/config.yml:ro myimage

Ideal für: Entwicklung mit Live-Reload, Konfigurationsdateien, Log-Ausgaben die man direkt lesen will.

Tücke: Berechtigungsprobleme. Der Container-User muss Schreibrechte auf den Host-Pfad haben. Auf Windows und Mac gibt es außerdem Performance-Einbußen durch die VM-Schicht.

tmpfs Mounts

tmpfs speichert Daten ausschließlich im RAM. Nach einem Container-Stopp sind sie weg – das ist gewollt.

# tmpfs mit Größenlimit
docker run --tmpfs /tmp:size=100m,mode=1777 myimage

# In Compose
services:
  app:
    tmpfs:
      - /tmp:size=50m
      - /run

Ideal für: Secrets die nicht auf Disk landen dürfen, temporäre Dateien, Session-Cache, Build-Artefakte.

Tücke: Beim Container-Stopp sind alle Daten weg. Nicht für Daten nutzen die persistiert werden müssen.

Vergleich auf einen Blick

| Eigenschaft | Named Volume | Bind Mount | tmpfs |
|---|---|---|---|
| Verwaltet von | Docker | Host-OS | Kernel |
| Persistenz | Ja | Ja | Nein (RAM) |
| Portabilität | Hoch | Gering | Hoch |
| Performance | Gut | Gut (Linux) / Schlecht (Mac/Win) | Sehr gut |
| Ideal für | Datenbanken | Entwicklung | Secrets, Cache |

Wann welcher Typ versagt

Named Volume – Daten weg: docker volume rm löscht alles. Kein Backup = kein Wiederherstellen. Immer docker volume inspect vor dem Löschen ausführen, um sicherzugehen dass das Volume nicht in Verwendung ist.

Bind Mount – Permission denied: Der Prozess im Container läuft als UID 1000, das Host-Verzeichnis gehört root. Lösung: chown 1000:1000 /hostpath oder --user $(id -u):$(id -g).

tmpfs – Daten verloren: Container gestoppt, Cache weg. Wer tmpfs für Session-Daten nutzt und mehrere Container-Replicas betreibt, braucht einen externen Session-Store (Redis).

Faustregel

Datenbank oder persistente App-Daten → Named Volume. Quellcode im Dev-Modus oder Config-Files → Bind Mount. Temporäre Dateien oder Secrets → tmpfs.