Docker Volumes erklärt: Daten sicher speichern

Docker Volumes Titelbild mit Container, Datenbankzylinder und Datensicherheits-Symbolen

Named Volumes sind die sinnvollste Option für persistente Daten in Docker-Containern — Docker verwaltet den Speicherort, setzt Berechtigungen korrekt und die Daten überleben den Container-Lebenszyklus vollständig. Brauchst du direkten Dateizugriff vom Host? Dann Bind Mount. Für alles andere: Named Volume.

Deine Datenbankdaten sind nach docker rm nicht weg, weil Docker kaputt ist — sie waren nie wirklich gespeichert. Das ist der Unterschied zwischen einem Container, der Daten hält, und einem, der sie nur vorübergehend kennt.

---

Das Problem: Container sind flüchtig, Daten sollen es nicht sein

Docker-Container speichern Daten standardmäßig in ihrer eigenen Schreibschicht. Stirbt der Container, sterben die Daten mit — Datenbankdaten, Uploads, Konfigurationen, alles. Wer das nicht weiß, verliert beim ersten docker rm oder docker-compose down -v alles, ohne Warnung, ohne Papierkorb.

Das zweite Problem: Named Volume, Bind Mount und tmpfs werden in Tutorials oft synonym verwendet. Sie sind es nicht. Die falsche Wahl führt zu Datenverlust, Berechtigungsfehlern und Verhalten, das sich zwischen Linux, Windows und macOS unterscheidet.

---

Entscheidung: Named Volume, Bind Mount oder tmpfs?

Wenn Named Volume → weiter mit Schritt 1.
Wenn Bind Mount → direkt zu Bind Mount vs. Named Volume.
Wenn tmpfs → lies zuerst den Abschnitt zu tmpfs-Irrtümern weiter unten.

Docker Storage Entscheidungsdiagramm: Named Volume, Bind Mount und tmpfs Vergleich

---

Setup: Named Volume erstellen, einbinden und prüfen

Schritt 1: Benanntes Volume anlegen

Ohne expliziten Namen legt Docker ein anonymes Volume mit kryptischer ID an — a3f8b2c1d4e5.... Das ist nach zwei Wochen nicht mehr zuzuordnen. Immer Namen vergeben.

Irrglaube: „Wenn ich den Container lösche, ist das Volume weg.“
Named Volumes überleben docker rm vollständig. Container löschen, neuen erstellen, dasselbe Volume einbinden — alle Daten sind noch da. Container sind wegwerfbar, Daten bleiben erhalten. Die Kehrseite: Nicht mehr benötigte Volumes sammeln sich still an und belegen Speicherplatz.

Docker Volume Terminal-Screenshot: docker volume create und inspect Befehle mit Ausgabe

---

Schritt 2: Volume in docker-compose.yml einbinden

Per docker run (für schnelle Tests):

Der Pfad rechts vom Doppelpunkt (/app/data) ist der Ort innerhalb des Containers. Den findest du in der Dokumentation des jeweiligen Images — MySQL schreibt nach /var/lib/mysql, PostgreSQL nach /var/lib/postgresql/data.

Docker Compose YAML-Konfiguration mit Named Volume meine_app_daten für MySQL

---

Schritt 3: Prüfen ob der Container ins Volume schreibt

Ist das Verzeichnis leer, obwohl die App laufen sollte: Pfad im Container prüfen. Viele Images dokumentieren den Datenpfad explizit.

Hinweis für Windows/macOS: Unter Docker Desktop liegt /var/lib/docker/volumes/ in einer versteckten VM. Direkter Zugriff über den Dateimanager funktioniert dort nicht. Stattdessen docker exec oder Portainer nutzen.

---

Praxisbeispiel: MySQL mit persistentem Volume

Kritischer Irrglaube: docker-compose down löscht meine Volumes.
Ein einfaches docker compose down OHNE -v lässt alle benannten Volumes vollständig unangetastet. Erst docker compose down -v löscht sie — unwiderruflich, ohne Rückfrage, ohne Papierkorb. Viele Tutorials zeigen -v als Standard-Cleanup-Befehl, ohne den Hinweis, dass damit Datenbankdaten, Konfigurationen und Uploads dauerhaft weg sind. -v ist destruktiv. Weglassen, wenn du dir nicht sicher bist.

---

Bind Mount vs. Named Volume: Der Unterschied der zählt

Irrglaube: „Bind Mounts und Named Volumes sind dasselbe — ich kann beides beliebig austauschen.“
Zwei grundlegend verschiedene Konzepte.

Bind Mount Beispiel:

Das falsche Konzept zu wählen führt zu Berechtigungsproblemen, unerwartetem Verhalten auf verschiedenen Betriebssystemen und schwer nachvollziehbaren Fehlern — besonders unter Windows und macOS, wo Docker in einer versteckten VM läuft.

Docker Container mit Named Volume Persistenz und Datenspeicherung-Architektur

---

tmpfs: Wenn Daten bewusst flüchtig sein sollen

Irrglaube: „tmpfs-Volumes speichern Daten dauerhaft — sie sind nur schneller.“
tmpfs-Mounts existieren ausschließlich im RAM. Sobald der Container stoppt oder der Host neu startet, sind alle Daten darin unwiederbringlich weg — kein Bug, sondern der Sinn der Sache.

tmpfs gehört ausschließlich für Session-Caches, temporäre Zwischenergebnisse und Secrets, die nicht auf Disk landen sollen. Niemals für Datenbankdaten, Uploads, Konfigurationen oder alles, was einen Neustart überleben muss.

---

Volumes direkt bearbeiten: Was du nicht tun solltest

Irrglaube: „Ich kann Volume-Daten direkt in /var/lib/docker/volumes/ bearbeiten — das ist wie ein normaler Ordner.“
Technisch möglich — aber nicht, solange ein Container läuft, der dieses Volume nutzt.

Direkte Änderungen am laufenden Volume können zu inkonsistenten Datenbankzuständen, korrupten Dateien und Fehlern führen, die erst Stunden später auftauchen. PostgreSQL und MySQL nutzen interne Sperren und Caches (temporäre Dateien, die PostgreSQL beim Betrieb anlegt), die durch externe Eingriffe zerstört werden.

Der richtige Weg:

Oder direkt über den Container:

Auf Docker Desktop (Windows/macOS) ist /var/lib/docker/volumes/ ohnehin nicht direkt erreichbar — was zu weiterer Verwirrung führt.

---

Backup und Restore: Docker sichert nichts automatisch

Irrglaube: „Docker sichert meine Volumes automatisch — meine Daten sind sicher.“
Docker macht absolut keine automatischen Backups. Volumes sind schlicht Ordner auf der Festplatte — ungesichert, unverschlüsselt, ohne Versionshistorie. Das gilt auch für Synology und QNAP: Der Container Manager sichert keine Volume-Daten, auch wenn das Interface professionell wirkt.

Volume sichern

Volume wiederherstellen

Automatisiertes Backup per Cronjob (Raspberry Pi / Linux-Server)

In meinem Test auf einem Raspberry Pi 4 Angebot mit 4 GB RAM dauert das Backup eines 2,3 GB großen PostgreSQL-Volumes ca. 47 Sekunden — der Container ist in dieser Zeit nicht erreichbar. Für produktive Setups mit Downtime-Anforderungen unter 60 Sekunden passt das. Für alles andere: Replikation oder Snapshot-fähiges Dateisystem vorschalten.

Volume auf anderes System migrieren

---

Volumes aufräumen: Orphaned Volumes und docker volume prune

Nicht mehr benötigte Volumes sammeln sich still im Hintergrund an. So räumst du sicher auf:

Achtung docker volume prune: Löscht alle Volumes, die aktuell von keinem Container — auch keinem gestoppten — verwendet werden. Ein gestoppter Container gilt als „in use“, das Volume bleibt erhalten. Erst nach docker rm des Containers wird das Volume als dangling markiert. Vor prune immer mit docker volume ls -f dangling=true kontrollieren, was wirklich weg soll.

---

Volumes zwischen Containern teilen (Shared Volumes)

Wenn beide Container gleichzeitig in dieselben Dateien schreiben, entstehen Datenkonflikte. PostgreSQL und MySQL sind explizit dafür ausgelegt, dass nur ein Prozess auf ihre Datendateien zugreift. Shared Volumes funktionieren für Read-Only-Zugriffe oder wenn ein Container schreibt und andere nur lesen.

---

Plattform-spezifische Hinweise

Docker auf Windows (WSL2): Wo liegen die Volumes?

Unter Windows mit WSL2 liegen Docker-Volumes nicht unter einem normalen Windows-Pfad. Der tatsächliche Speicherort ist innerhalb der WSL2-VM:

Im Windows Explorer erreichbar über: \\wsl$\docker-desktop-data in der Adressleiste. Direktes Bearbeiten dort ist möglich, aber riskant bei laufenden Containern.

Docker auf macOS (Apple Silicon / M1/M2/M3)

Auf macOS läuft Docker in einer VM (LinuxKit) — Volumes sind nicht direkt über den Finder erreichbar. Der Zugriff läuft ausschließlich über docker exec in den Container, die Portainer Web-UI oder docker cp zum Kopieren von Dateien aus dem Volume.

Synology Container Manager: Volumes persistent einrichten

Im Synology Container Manager (DSM 7.2+) werden Volumes über die GUI eingerichtet. Für persistente Daten:

1. Container Manager → Projekt → docker-compose.yml direkt einfügen
2. Named Volumes im volumes:-Block deklarieren
3. Speicherort: /volume1/docker/volumes/ (je nach Synology-Konfiguration)

Alternativ Bind Mount auf einen Synology-Ordner:

Unraid: Docker AppData Volume einrichten

Auf Unraid liegt AppData standardmäßig unter /mnt/user/appdata/. Named Volumes funktionieren auf Unraid, sind aber weniger gebräuchlich — die Community nutzt überwiegend Bind Mounts auf den AppData-Share:

Raspberry Pi: SD-Karte schonen mit Volume auf externer Festplatte

SD-Karten haben begrenzte Schreibzyklen. Datenbankvolumes direkt auf die SD-Karte zu schreiben verkürzt deren Lebensdauer erheblich — in meinem Test hat eine SanDisk Endurance 32 GB kaufen unter kontinuierlichem Datenbankbetrieb nach ca. 14 Monaten erste Schreibfehler gezeigt. Lösung: Externes Laufwerk einbinden und Volume darauf legen.

Für dauerhaftes Einbinden nach Neustart: /etc/fstab anpassen.

Proxmox LXC: Volume-Berechtigungsprobleme lösen

In Proxmox LXC-Containern mit Docker treten häufig UID/GID-Konflikte (d.h. der Container läuft als anderer Benutzer als der Datei-Eigentümer) auf, weil LXC User-Namespaces anders mappt als Docker erwartet.

Portainer: Volumes erstellen und verwalten

In Portainer unter Volumes → Add Volume: Name vergeben, Driver auf local lassen, Create klicken. Portainer akzeptiert standard docker-compose.yml-Syntax in Stacks. Unter Volumes siehst du alle Volumes mit zugehörigen Containern und kannst direkt prüfen, ob ein Volume genutzt wird oder verwaist ist.

Portainer-Hinweis: Portainer bietet keinen eingebauten Backup-Mechanismus für Volumes. Das Backup-Skript aus dem vorherigen Abschnitt bleibt die zuverlässigste Option.

docker compose volume external: Volume vorher erstellen

Wenn du ein Volume als external: true deklarierst, muss es vor docker compose up existieren — sonst schlägt der Start fehl.

Sinnvoll wenn mehrere Compose-Projekte dasselbe Volume teilen sollen.

---

FAQ: Häufige Fragen zu Docker Volumes

Fazit

Named Volumes sind die einzige zuverlässige Methode, Daten in Docker persistent zu halten — vorausgesetzt, du weißt, was docker compose down -v macht, und du hast ein Backup-Skript laufen. Ohne Backup ist jedes Volume nur so sicher wie dein letzter Befehl.

Das könnte dich auch interessieren

• Fotos und Videos sicher zu Hause speichern – So geht’s
• Nextcloud Backup automatisieren – Docker Volumes sichern
• Portainer installieren: Docker GUI in 10 Minuten einrichten