Docker Volumes: Daten dauerhaft speichern (Anleitung)

Löschst du einen Container, sind auch alle Daten darin verloren – Datenbanken, Uploads, Konfigurationen. Damit das nicht passiert, gibt es Docker Volumes. Sie speichern Daten dauerhaft außerhalb des Containers. In dieser Anleitung erklären wir die drei Speicher-Typen, zeigen dir, wie du Volumes anlegst, in docker-compose.yml nutzt und sicherst. Am Ende weißt du genau, wie du deine Container-Daten persistent speicherst, welcher Speichertyp für welchen Zweck taugt und wie du typische Berechtigungsprobleme vermeidest.

Warum brauchst du Volumes?

Container sind per Design flüchtig: Ihr Dateisystem existiert nur, solange der Container läuft. Wird er neu erstellt – etwa bei einem Update – beginnt er mit dem unveränderten Image. Alles, was währenddessen geschrieben wurde, ist weg. Volumes lösen das Problem, indem sie ein Verzeichnis außerhalb des Container-Dateisystems einbinden. Dort bleiben die Daten erhalten, egal was mit dem Container passiert. Wenn du die Grundlagen von Containern auffrischen willst, lies zuerst Was ist Docker?.

Die drei Speicher-Typen im Vergleich

Docker kennt drei Wege, um Daten dauerhaft oder temporär zu speichern:

Für die meisten Selfhosting-Anwendungen sind Named Volumes die beste Wahl, weil Docker sie sauber verwaltet. Bind Mounts nimmst du, wenn du den genauen Speicherort auf dem Host bestimmen willst.

Named Volume anlegen und nutzen

Ein Named Volume erstellst du entweder explizit oder du lässt es beim Containerstart automatisch anlegen. Explizit geht es so:

docker volume create meine-daten

docker volume create meine-daten

Anschließend bindest du es beim Start eines Containers mit -v ein. Das folgende Beispiel legt die Daten einer PostgreSQL-Datenbank ins Volume:

docker run -d \
  --name datenbank \
  -v meine-daten:/var/lib/postgresql/data \
  postgres:16

docker run -d \
  --name datenbank \
  -v meine-daten:/var/lib/postgresql/data \
  postgres:16

Links vom Doppelpunkt steht der Volume-Name, rechts der Pfad im Container. Selbst wenn du den Container löschst und neu erstellst – solange du dasselbe Volume einbindest, sind die Daten wieder da.

Bind Mount nutzen

Beim Bind Mount gibst du statt eines Volume-Namens einen absoluten Pfad auf dem Host an. Das ist praktisch für Konfigurationsdateien, die du direkt bearbeiten willst:

docker run -d \
  --name webserver \
  -v /opt/nginx/config:/etc/nginx/conf.d \
  nginx:latest

docker run -d \
  --name webserver \
  -v /opt/nginx/config:/etc/nginx/conf.d \
  nginx:latest

Änderungen im Host-Verzeichnis /opt/nginx/config sind sofort im Container sichtbar. Achte hier besonders auf die Dateirechte des Host-Verzeichnisses.

Volumes in docker-compose.yml

Im Alltag definierst du Volumes meist über Compose. Named Volumes werden unten im volumes:-Block deklariert und bei den Diensten referenziert. Falls du Compose noch installieren musst, hilft dir Docker Compose installieren.

services:
  datenbank:
    image: postgres:16
    volumes:
      - db-daten:/var/lib/postgresql/data   # Named Volume
      - ./init:/docker-entrypoint-initdb.d    # Bind Mount

volumes:
  db-daten:

services:
  datenbank:
    image: postgres:16
    volumes:
      - db-daten:/var/lib/postgresql/data   # Named Volume
      - ./init:/docker-entrypoint-initdb.d    # Bind Mount

volumes:
  db-daten:

Vergisst du die Deklaration im unteren volumes:-Block, quittiert Compose das mit einem Fehler. Wie du ihn löst, steht in „service refers to undefined volume“.

Volumes auflisten, inspizieren und löschen

Diese Befehle brauchst du zum Verwalten deiner Volumes:

Ein Volume sichern und wiederherstellen

Für ein Backup packst du den Inhalt eines Volumes mit einem kurzlebigen Hilfscontainer in ein Tar-Archiv. So sicherst du meine-daten in die Datei backup.tar.gz im aktuellen Verzeichnis:

docker run --rm \
  -v meine-daten:/quelle \
  -v $(pwd):/backup \
  alpine tar czf /backup/backup.tar.gz -C /quelle .

docker run --rm \
  -v meine-daten:/quelle \
  -v $(pwd):/backup \
  alpine tar czf /backup/backup.tar.gz -C /quelle .

Die Wiederherstellung funktioniert umgekehrt – das Archiv wird in ein (leeres) Volume entpackt:

docker run --rm \
  -v meine-daten:/ziel \
  -v $(pwd):/backup \
  alpine sh -c "tar xzf /backup/backup.tar.gz -C /ziel"

docker run --rm \
  -v meine-daten:/ziel \
  -v $(pwd):/backup \
  alpine sh -c "tar xzf /backup/backup.tar.gz -C /ziel"

Named Volume oder Bind Mount – wann was?

Beide Verfahren speichern Daten außerhalb des Containers, unterscheiden sich aber in Verwaltung und Kontrolle. Als Faustregel gilt: Nutze Named Volumes für alles, was Docker verwalten darf – Datenbanken, Anwendungsdaten, Caches. Greife zum Bind Mount, wenn du eine Datei oder ein Verzeichnis vom Host aus direkt bearbeiten willst, etwa eine nginx.conf oder ein Zertifikat.

• Named Volume: portabel, von Docker verwaltet, ideal für persistente Zustandsdaten und Backups.
• Bind Mount: voller Zugriff auf den Host-Pfad, perfekt für Konfigurationen und Entwicklungs-Workflows.
• tmpfs: nur im RAM, nichts wird auf die Platte geschrieben – für Secrets und kurzlebige Daten.

Berechtigungen und typische Stolperfallen

Der häufigste Fehler bei Volumes sind falsche Dateirechte. Prozesse im Container laufen oft unter einer bestimmten UID/GID (etwa 999 bei PostgreSQL). Passt diese nicht zu den Rechten des gemounteten Verzeichnisses, verweigert die Anwendung den Start mit „permission denied“. Bei Named Volumes setzt Docker die Rechte in der Regel automatisch korrekt; bei Bind Mounts musst du sie selbst anpassen, zum Beispiel mit chown -R 999:999 /opt/app/data auf dem Host.

Ein weiterer Klassiker: Ein leeres Bind-Mount-Verzeichnis überdeckt beim ersten Start die im Image mitgelieferten Standarddateien. Prüfe bei Problemen deshalb immer zuerst mit docker logs CONTAINER, was der Dienst beim Start meldet.

Wo Volumes liegen und was das für Backups bedeutet

Named Volumes speichert Docker unter /var/lib/docker/volumes/<name>/_data. Du solltest dort aber nicht von Hand hineinschreiben – nutze stattdessen den im Abschnitt oben gezeigten Weg über einen Hilfscontainer. Für ein zuverlässiges Backup empfiehlt es sich, den Container vor dem Sichern kurz zu stoppen, damit keine halb geschriebenen Datenbankdateien im Archiv landen. Datenbanken sicherst du am besten zusätzlich mit ihrem eigenen Dump-Werkzeug (z. B. pg_dump oder mysqldump).

Häufige Fragen

Wo speichert Docker seine Volumes?

Named Volumes liegen standardmäßig unter /var/lib/docker/volumes/. Den exakten Pfad eines Volumes zeigt dir docker volume inspect NAME im Feld Mountpoint. Bind Mounts liegen an dem Host-Pfad, den du beim Start angegeben hast.

Bleiben die Daten nach docker compose down erhalten?

Ja. docker compose down entfernt Container und Netzwerke, lässt Named Volumes aber unangetastet. Erst mit docker compose down -v werden auch die zugehörigen Volumes gelöscht – dieses Flag solltest du nur bewusst einsetzen.

Wie migriere ich ein Volume auf einen anderen Server?

Sichere das Volume wie oben gezeigt in ein tar.gz-Archiv, kopiere die Datei per scp auf den Zielserver und entpacke sie dort in ein neues, leeres Volume. So ziehst du Datenbanken und App-Daten ohne Datenverlust um.

Fazit

Docker Volumes trennen deine Daten sauber vom Container und machen sie updatesicher. Für die meisten Fälle sind Named Volumes ideal, Bind Mounts nutzt du für Konfigurationen mit festem Pfad. Denk daran, wichtige Volumes regelmäßig zu sichern. Als Nächstes lohnt sich ein Blick darauf, wie Docker-Netzwerke funktionieren und wie du Container automatisch aktualisierst.