Docker-Volume-Praxisleitfaden: 5 Beispiele gegen Datenverlust in Containern

Die letzte Zeile im Terminal: „Database import completed successfully” – nach vier Stunden war es endlich geschafft: 20.000 Testdatensätze in den MySQL-Container importiert. Ein paar API-Endpunkte getestet, alles grün.

Am nächsten Morgen tippe ich reflexartig docker ps, um den Container-Status zu prüfen. Leer. War der Container gestern Abend vielleicht nicht gestartet? Schnell docker ps -a für alle Container. Auch nichts. Dann fällt es mir ein: Vor dem Schlafengehen wollte ich Speicherplatz freimachen und habe docker system prune -a ausgeführt.

Schlimm. Alle Daten weg. 20.000 Testdatensätze, vier Stunden Arbeit – alles umsonst.

Nach drei Wochen Docker kannte ich nur die Vorteile: schneller Start, saubere Isolation. Dass Container eine Achillesferse haben – sie eignen sich nicht zum Speichern von Daten – wusste ich nicht. Container löschen, Daten weg; Container neu starten, Konfiguration zurück auf Werkseinstellungen.

In diesem Artikel zeigen Ihnen fünf Praxisbeispiele Schritt für Schritt, wie Sie mit Docker Volumes (Datenvolumes) Daten aus dem Container auslagern – damit sie nicht mehr mit dem Leben und Sterben des Containers verschwinden.

Die Wahrheit über Container-Datenverlust

Warum sind Daten weg, wenn Sie den Container löschen?

Docker nutzt ein Schichtdateisystem. Stellen Sie sich eine Mille-feuille vor: Unten die Image-Schicht (read-only, von allen Containern geteilt), oben die Container-Schicht (beschreibbar, pro Container exklusiv). Dateien, geänderte Konfigurationen und importierte Daten landen alle in dieser obersten Schicht.

Der entscheidende Punkt: Beim Löschen des Containers wird diese beschreibbare Schicht mit zerstört.

Glauben Sie es nicht? Probieren Sie das aus:

# Alpine-Container starten und Datei schreiben
docker run -it --name test-container alpine sh
# Im Container ausführen
echo "Wichtige Daten" > /tmp/data.txt
exit

# Container löschen
docker rm test-container

# Daten wiederfinden
docker run -it --name test-container alpine sh
cat /tmp/data.txt  # Fehler: No such file or directory

Die Daten sind weg – ohne jede Warnung.

Das Design ist eigentlich sinnvoll: Container sind für zustandslose Anwendungen gedacht. Nginx, API-Server – sie müssen nichts speichern, jeder Start ist identisch. Aber Datenbanken, Redis, Datei-Upload-Dienste? Die müssen Daten behalten.

Die offizielle Docker-Lösung heißt Volume (Datenvolume): Daten liegen außerhalb des Containers – Leben und Tod des Containers sind von der Datenpersistenz entkoppelt.

Was ist ein Volume? Wie rettet es Ihre Daten?

Das Wesen eines Volumes: Dockers externe Festplatte

Ein Volume ist wie eine externe Festplatte für den Container. Daten werden nicht im Container geschrieben, sondern in einem Verzeichnis auf dem Host – und von dort in einen Pfad im Container gemountet. Der Container sieht /var/lib/mysql, tatsächlich liegen die Daten auf dem Host unter /var/lib/docker/volumes/mysql-data/_data.

Container gelöscht? Kein Problem – die Daten bleiben auf dem Host. Container neu starten, dasselbe Volume erneut mounten – die Daten sind wieder da.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Docker bietet drei Mount-Arten; Anfänger verwechseln sie leicht:

Ehrlich gesagt kannte ich anfangs den Unterschied zwischen Volume und Bind Mount nicht – beides fühlte sich an wie „Host-Verzeichnis einhängen”. Bis ich in die Falle tappte: MySQL-Datenverzeichnis per Bind Mount gemountet, das Host-Verzeichnis versehentlich gelöscht – der MySQL-Container stürzte ab.

Volumes verwaltet Docker vollständig. Sie müssen sich nicht um Pfade, Berechtigungen oder Backup-Strategien kümmern. Speicherort anzeigen? docker volume inspect. Daten migrieren? docker volume-Befehle. Deshalb empfiehlt Docker Volumes statt Bind Mounts.

Wo liegen Volume-Daten tatsächlich?

Unter Linux liegen alle Volumes standardmäßig hier:

/var/lib/docker/volumes/<volume-name>/_data/

Mac- und Windows-Nutzer: Docker Desktop läuft in einer VM – diesen Pfad sehen Sie nicht direkt. Details erhalten Sie mit docker volume inspect.

5 Beispiele für den Volume-Kern

Genug Theorie – jetzt praktisch. Diese fünf Beispiele führen von den Grundlagen bis zur Praxis. Einmal durchspielen, und Sie verstehen das Prinzip.

Beispiel 1: Ihr erstes benanntes Volume

Der einfachste Einstieg: ein leeres Volume anlegen.

# Volume mit Namen my-data anlegen
docker volume create my-data

# Alle Volumes anzeigen
docker volume ls

# Volume-Details anzeigen
docker volume inspect my-data

Erwartete Ausgabe (inspect-Befehl):

[
    {
        "CreatedAt": "2025-12-17T12:00:00Z",
        "Driver": "local",
        "Mountpoint": "/var/lib/docker/volumes/my-data/_data",
        "Name": "my-data"
    }
]

Sehen Sie Mountpoint? Das ist der tatsächliche Speicherort der Daten.

Beispiel 2: Nginx-Statik persistieren

Szenario: Sie entwickeln eine statische Website. Nach jeder Code-Änderung starten Sie den Nginx-Container neu – und jedes Mal sind hochgeladene Bilder und Logs weg.

Lösung: Das Nginx-Verzeichnis /usr/share/nginx/html auf ein Volume mounten.

# Volume für Website-Inhalte anlegen
docker volume create nginx-html

# Nginx-Container starten und Volume mounten
docker run -d \
  --name my-nginx \
  -p 8080:80 \
  -v nginx-html:/usr/share/nginx/html \
  nginx:latest

# Testseite im Container erstellen
docker exec my-nginx bash -c 'echo "<h1>Hello Docker Volume!</h1>" > /usr/share/nginx/html/index.html'

# Test (Browser: http://localhost:8080 oder per curl)
curl http://localhost:8080

Jetzt den Container löschen:

docker rm -f my-nginx

Neuen Container starten und dasselbe Volume mounten:

docker run -d \
  --name my-nginx-v2 \
  -p 8080:80 \
  -v nginx-html:/usr/share/nginx/html \
  nginx:latest

# Erneut aufrufen – Inhalt ist noch da!
curl http://localhost:8080

Kein Datenverlust. Das ist die Magie von Volumes.

Beispiel 3: MySQL-Daten persistieren (Praxisniveau)

Der häufigste Fall: MySQL containerisiert betreiben, Daten müssen persistieren.

# MySQL-Volume anlegen
docker volume create mysql-data

# MySQL-Container starten
docker run -d \
  --name mysql-demo \
  -e MYSQL_ROOT_PASSWORD=my-secret-pw \
  -e MYSQL_DATABASE=testdb \
  -p 3306:3306 \
  -v mysql-data:/var/lib/mysql \
  mysql:8.0

# MySQL-Start abwarten (ca. 10 Sekunden)
sleep 10

# MySQL verbinden und Testtabelle anlegen
docker exec -it mysql-demo mysql -uroot -pmy-secret-pw testdb -e "
CREATE TABLE users (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(50)
);
INSERT INTO users (name) VALUES ('Alice'), ('Bob');
"

# Daten abfragen
docker exec -it mysql-demo mysql -uroot -pmy-secret-pw testdb -e "SELECT * FROM users;"

Container löschen (versehentliches Löschen simulieren):

docker rm -f mysql-demo

MySQL-Container neu starten und dasselbe Volume mounten:

docker run -d \
  --name mysql-demo-v2 \
  -e MYSQL_ROOT_PASSWORD=my-secret-pw \
  -p 3306:3306 \
  -v mysql-data:/var/lib/mysql \
  mysql:8.0

# Start abwarten
sleep 10

# Daten abfragen – noch da!
docker exec -it mysql-demo-v2 mysql -uroot -pmy-secret-pw testdb -e "SELECT * FROM users;"

Wichtig: Das MySQL-Datenverzeichnis ist /var/lib/mysql – genau diesen Pfad müssen Sie mounten. Andere Datenbanken haben andere Pfade: Redis /data, PostgreSQL /var/lib/postgresql/data.

Beispiel 4: Redis-Persistenz konfigurieren

Redis speichert Daten standardmäßig im Arbeitsspeicher, kann aber auf Disk persistieren (RDB oder AOF).

# Redis-Daten-Volume anlegen
docker volume create redis-data

# Redis-Container mit AOF-Persistenz starten
docker run -d \
  --name redis-demo \
  -p 6379:6379 \
  -v redis-data:/data \
  redis:latest redis-server --appendonly yes
  # --appendonly yes aktiviert AOF-Persistenz

# Testdaten schreiben
docker exec -it redis-demo redis-cli SET mykey "Hello Redis Volume"

# Daten lesen
docker exec -it redis-demo redis-cli GET mykey

Container löschen:

docker rm -f redis-demo

Neu starten:

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

docker run -d \
  --name redis-demo-v2 \
  -p 6379:6379 \
  -v redis-data:/data \
  redis:latest redis-server --appendonly yes

# Daten sind noch da
docker exec -it redis-demo-v2 redis-cli GET mykey

Hinweis: Ohne --appendonly yes hält Redis Daten nur im Speicher – nach einem Neustart sind sie weg.

Beispiel 5: Volume zwischen mehreren Containern teilen

Szenario: Ein Nginx-Container liefert statische Dateien, ein App-Container schreibt Logs – beide teilen sich ein Volume.

# Gemeinsames Volume anlegen
docker volume create shared-logs

# App-Container starten und Logs schreiben
docker run -d \
  --name app-writer \
  -v shared-logs:/logs \
  alpine sh -c "while true; do echo $(date) >> /logs/app.log; sleep 2; done"

# Nginx-Container starten und Logs lesen
docker run -d \
  --name log-reader \
  -p 8080:80 \
  -v shared-logs:/usr/share/nginx/html:ro \
  nginx:latest
  # :ro = read-only, verhindert versehentliche Änderungen durch Nginx

# Kurz warten, damit app-writer Logs schreibt
sleep 5

# Logdatei abrufen (Browser: http://localhost:8080/app.log)
curl http://localhost:8080/app.log

Wichtig:

1. Ein Volume kann gleichzeitig in mehrere Container gemountet werden
2. Mit :ro setzen Sie read-only und erhöhen die Sicherheit
3. In Produktion: Log-Sammel-Container plus App-Container über gemeinsames Volume

Volume-Verwaltungsbefehle

Nach den fünf Beispielen fragen Sie sich sicher: Wie zeige, lösche und bereinige ich Volumes?

Hier die wichtigsten Befehle auf einen Blick:

# 1. Volume anlegen
docker volume create <volume-name>

# 2. Alle Volumes auflisten
docker volume ls

# 3. Volume-Details (inkl. Mount-Pfad)
docker volume inspect <volume-name>

# 4. Bestimmtes Volume löschen
docker volume rm <volume-name>
# Hinweis: Fehler, wenn ein Container das Volume noch nutzt

# 5. Alle ungenutzten Volumes löschen (Speicher freimachen)
docker volume prune
# Bestätigung mit y

# 6. Alle ungenutzten Volumes ohne Bestätigung löschen
docker volume prune -f

Häufiges Problem: „volume is in use” beim Löschen

Ein Container nutzt das Volume noch. Lösung:

# Welcher Container nutzt es?
docker ps -a --filter volume=<volume-name>

# Container stoppen und löschen
docker rm -f <container-name>

# Dann Volume löschen
docker volume rm <volume-name>

Speicherbelegung prüfen

Wie viel Platz belegt ein Volume?

# Linux/Mac
docker volume inspect <volume-name> --format '{{ .Mountpoint }}' | xargs du -sh

# Beispielausgabe: 512M    /var/lib/docker/volumes/mysql-data/_data

Bind Mount vs. Volume: Was soll ich verwenden?

Die Frage, die Anfänger am meisten beschäftigt. Am Anfang war mir der Unterschied auch unklar.

Merken Sie sich: Produktionsdaten → Volume, Entwicklungscode → Bind Mount.

Im Detail:

Syntax im Vergleich

# Volume (empfohlen für Persistenz)
docker run -v my-volume:/data redis:latest

# Bind Mount (empfohlen für Entwicklung)
docker run -v /Users/me/code:/app node:latest

# Neue Syntax --mount (expliziter, für Produktion empfohlen)
docker run --mount type=volume,source=my-volume,target=/data redis:latest
docker run --mount type=bind,source=/Users/me/code,target=/app node:latest

Entscheidungsbaum

Bei neuer Anforderung drei Fragen:

1. Müssen Daten langfristig erhalten bleiben?
   Ja → Volume; Nein → tmpfs

2. Sollen Daten direkt auf dem Host bearbeitet werden?
   Ja → Bind Mount; Nein → Volume

3. Produktion oder Entwicklung?
   Produktion → Volume; Entwicklung → Bind Mount

Praxisvergleich

Meine Entwicklungsumgebung:

# Entwicklung: Code per Bind Mount, Datenbank per Volume
docker run -d \
  --name dev-app \
  -v $(pwd)/src:/app/src \          # Bind Mount: Code-Änderungen sofort wirksam
  -v app-uploads:/app/uploads \     # Volume: hochgeladene Dateien
  -v postgres-data:/var/lib/postgresql/data \  # Volume: Datenbankdaten
  my-app:dev

Meine Produktionsumgebung:

# Produktion: alles per Volume
docker run -d \
  --name prod-app \
  -v app-uploads:/app/uploads \
  -v postgres-data:/var/lib/postgresql/data \
  my-app:latest
# Code ist im Image – kein Mount nötig

Häufige Fragen und Best Practices

FAQ: Fallen, in die ich getappt bin – und Lösungen

F1: Gehen Volume-Daten verloren?
Nein. Solange Sie nicht manuell docker volume rm ausführen, bleiben die Daten erhalten – auch nach einem Host-Neustart.

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

Aber Vorsicht: docker system prune -a --volumes löscht alle ungenutzten Volumes. Mit Bedacht verwenden!

F2: Was passiert, wenn das Volume beim Start nicht existiert?
Docker legt es automatisch an:

# Kein vorheriges docker volume create nötig
docker run -d -v auto-created-volume:/data alpine
# Docker erstellt auto-created-volume automatisch

Ich empfehle trotzdem manuelles Anlegen – so wissen Sie genau, wo die Daten liegen.

F3: Wie sichere ich Volume-Daten?
Offizielle Methode:

# Temporären Container starten und Volume packen
docker run --rm \
  -v mysql-data:/source \
  -v $(pwd):/backup \
  alpine tar -czf /backup/mysql-backup.tar.gz -C /source .

# Wiederherstellen
docker run --rm \
  -v mysql-data:/target \
  -v $(pwd):/backup \
  alpine tar -xzf /backup/mysql-backup.tar.gz -C /target

F4: Kann man Volumes zwischen Hosts migrieren?
Ja, aber manuell:

1. Auf dem Quell-Host: Volume wie oben archivieren
2. .tar.gz auf den neuen Host übertragen
3. Auf dem Ziel-Host: Volume anlegen und Daten entpacken

Fortgeschritten: NFS oder Cloud-Speicher als Volume Driver.

F5: Was sind anonyme Volumes? Wie bereinigen?
Ohne Volume-Namen erzeugt Docker anonyme Volumes:

docker run -d -v /data alpine  # zufälliger Name wie a1b2c3d4...

Schwer zu verwalten, fressen Speicher. Bereinigung:

docker volume prune  # löscht alle ungenutzten Volumes (inkl. anonyme)

Best Practice: Immer benannte Volumes verwenden.

6 Best Practices für Produktion

1. Immer benannte Volumes

   # ✓ Gute Praxis
   docker run -v mysql-data:/var/lib/mysql mysql:8.0
   
   # ✗ Schlechte Praxis
   docker run -v /var/lib/mysql mysql:8.0  # anonymes Volume

2. Kritische Daten regelmäßig sichern
   Tägliches Backup der Datenbank-Volumes einplanen. Datenverlust tut weh – das weiß ich aus Erfahrung.

3. Docker Compose für komplexe Projekte

   # docker-compose.yml
   services:
     db:
       image: mysql:8.0
       volumes:
         - mysql-data:/var/lib/mysql
   
   volumes:
     mysql-data:
       driver: local

4. In Produktion —mount statt -v
   --mount ist expliziter, Fehlermeldungen sind klarer:

   docker run --mount type=volume,source=mysql-data,target=/var/lib/mysql mysql:8.0

5. Ungenutzte Volumes regelmäßig bereinigen
   Monatlich:

   docker volume prune

6. Sensible Daten: verschlüsselte Volumes
   Passwörter und Schlüssel im Volume? Verschlüsselung erwägen (z. B. LUKS).

Fazit

Zurück zu jenem Morgen: Hätte ich damals Docker Volumes gekannt, hätte ein Befehl gereicht:

docker run -d --name mysql-demo -v mysql-data:/var/lib/mysql mysql:8.0

Die Daten wären nicht mit dem Container verschwunden. Vier Stunden Arbeit, 20.000 Testdatensätze – sicher auf dem Host geblieben.

Docker-Container sind zustandslos – das ist Stärke und Grenze zugleich. Volumes überwinden diese Grenze: leichte, isolierte Container und trotzdem persistente Daten.

Fünf Beispiele: erstes Volume, Nginx-Statik, MySQL und Redis in der Praxis, gemeinsames Volume zwischen Containern. Das deckt etwa 90 % des Alltags ab.

Jetzt sind Sie dran. Terminal öffnen, erstes Volume anlegen, MySQL-Container starten, Daten schreiben. Container löschen, neu starten – und sehen, dass die Daten noch da sind. Dann verstehen Sie Datenpersistenz wirklich.

Wenn Sie nicht noch einmal um drei Uhr morgens Daten verlieren wollen: Diesen Artikel bookmarken. Er kann Ihnen eines Tages den Arbeitsabend retten.