Daten mit Volumes persistent speichern

Contents

Lesedauer: 12 Minuten

Docker-Container besitzen eine beschreibbare Dateisystemschicht, deren Inhalt beim Entfernen des Containers verloren geht. Sollen Daten unabhängig vom Lebenszyklus eines Containers erhalten bleiben, müssen sie außerhalb dieser Schicht gespeichert werden.

Neben Bind Mounts bietet Docker dafür sogenannte Volumes. Dabei handelt es sich um eigenständige, von Docker verwaltete Speicherobjekte, die in das Dateisystem eines oder mehrerer Container eingebunden werden können. Während bei einem Bind Mount der Speicherpfad auf dem Host ausdrücklich angegeben wird, übernimmt Docker bei einem Volume die Verwaltung des Speicherortes. Die Anwendung innerhalb des Containers greift in beiden Fällen auf einen gewöhnlichen Verzeichnispfad zu.

Die Grundlagen der beschreibbaren Container-Schicht und ihrer Persistenzproblematik sind bereits im Artikel Daten mit Bind Mounts persistent speichern, insbesondere im Abschnitt Die beschreibbare Dateisystemschicht eines Containers, beschrieben.

Ein benanntes Docker-Volume erstellen

Docker unterscheidet zwischen benannten und anonymen Volumes. Benannte Volumes besitzen einen ausdrücklich vergebenen Namen und lassen sich dadurch unabhängig von einem bestimmten Container verwalten und wiederverwenden. Anonyme Volumes erhalten dagegen automatisch generierte Namen.

Für das folgende Experiment wird ein benanntes Volume verwendet. Als Anwendung dient erneut der Webserver nginx.

Zunächst wird geprüft, welche Volumes bereits vorhanden sind:

$ sudo docker volume ls

Mit docker volume create wird ein neues Volume erstellt:

$ sudo docker volume create academy-volume-nginx-01-html
academy-volume-nginx-01-html

Eine erneute Abfrage zeigt das Volume mit dem Treiber local:

$ sudo docker volume ls
DRIVER    VOLUME NAME
local     academy-volume-nginx-01-html

Eigenschaften des Volumes untersuchen

Mit docker volume inspect lassen sich die Eigenschaften des Volumes anzeigen:

$ sudo docker volume inspect academy-volume-nginx-01-html
[
    {
        "CreatedAt": "2026-10-31T09:55:40+01:00",
        "Driver": "local",
        "Labels": null,
        "Mountpoint": "/var/lib/docker/volumes/academy-volume-nginx-01-html/_data",
        "Name": "academy-volume-nginx-01-html",
        "Options": null,
        "Scope": "local"
    }
]

Besonders relevant sind die Eigenschaften Driver, Mountpoint, Name und Scope.

Der Treiber local verwaltet das Volume über den Docker-Daemon des Hosts.
Scope: local bedeutet, dass es nicht automatisch anderen Docker-Hosts zur Verfügung steht.
Mountpoint gibt den tatsächlichen Speicherort an. Bei der untersuchten Installation liegt dieser unter:
/var/lib/docker/volumes/academy-volume-nginx-01-html/_data

Dieser Pfad wurde nicht beim Erstellen des Volumes angegeben, sondern von Docker festgelegt. Auf anderen Systemen oder bei anderen Volume-Treibern kann er abweichen.

Der direkte Zugriff auf solche internen Speicherverzeichnisse ist für Diagnosezwecke möglich. Für den regulären Betrieb sollten Volumes jedoch über Docker und die vorgesehenen Anwendungen verwaltet werden.

Im nächsten Schritt wird das Volume einem nginx-Container zugeordnet. Ziel ist es, die vom Webserver ausgelieferten HTML-Dateien außerhalb der beschreibbaren Container-Schicht zu speichern.

Dazu wird das Volume unter /usr/share/nginx/html eingebunden:

$ sudo docker run -d \
  --name academy-volume-nginx-01 \
  --restart unless-stopped \
  -p 8082:80 \
  --mount type=volume,source=academy-volume-nginx-01-html,target=/usr/share/nginx/html \
  nginx:stable-alpine

Die Mount-Definition besteht aus drei wesentlichen Angaben:

type=volume: Ein Docker-Volume wird eingebunden.
source=...: Name des zu verwendenden Volumes.
target=...: Verzeichnis innerhalb des Containers, in dem das Volume bereitgestellt wird.

Da das Volume bereits existiert, verwendet Docker das vorhandene Speicherobjekt. Wird ein noch nicht vorhandener Volume-Name angegeben, kann Docker das benannte Volume automatisch erstellen.

Anders als bei einem Bind Mount muss kein Host-Verzeichnis angegeben werden.

Automatische Übernahme vorhandener Dateien (Copy-up)

Vor dem Erstellen des Containers wurde das Volume-Verzeichnis auf dem Host untersucht:

$ sudo ls -la /var/lib/docker/volumes/academy-volume-nginx-01-html/_data

Es enthielt keine Nutzdaten.

Nach dem Start des nginx-Containers ergab dieselbe Untersuchung:

$ sudo ls -la /var/lib/docker/volumes/academy-volume-nginx-01-html/_data
-rw-r--r-- 1 root root 497  2. Okt 19:14 50x.html
-rw-r--r-- 1 root root 896  2. Okt 19:14 index.html

Die beiden Dateien waren zuvor ausschließlich im Dateisystem des nginx-Images vorhanden. Docker hatte sie beim erstmaligen Einbinden des leeren Volumes automatisch übernommen. Dieses Verhalten wird als Copy-up oder Volume-Population bezeichnet.

Wird ein leeres Volume in ein Container-Verzeichnis eingebunden, das bereits Dateien enthält, kopiert Docker diese standardmäßig in das Volume. Bei einem Bind Mount findet diese automatische Übernahme nicht statt.

Copy-up bezeichnet hier die erstmalige Übernahme vorhandener Dateien in ein leeres Volume. Das ist nicht mit dem Copy-on-Write-Mechanismus der beschreibbaren Container-Schicht zu verwechseln. Die automatische Übernahme lässt sich mit der Mount-Option volume-nocopy unterbinden. Bei einem bereits befüllten Volume findet keine erneute Übernahme statt.

Was geschieht mit den ursprünglichen Dateien?

Das Volume wird über das bestehende Verzeichnis /usr/share/nginx/html eingehängt. Dadurch werden dessen ursprüngliche Inhalte verdeckt, aber nicht gelöscht. Die Anwendung verwendet weiterhin denselben Verzeichnispfad. Sie sieht dort jedoch die Dateien des eingebundenen Volumes. Das entspricht dem grundlegenden Mount-Verhalten unter Linux und gilt ebenso für Bind Mounts.

Würde der Mount tatsächlich entfernt, wäre wieder der zuvor verdeckte Inhalt des Container-Dateisystems sichtbar. Eine nachträgliche Änderung oder Entfernung der Mount-Konfiguration ist bei einem bestehenden Docker-Container im regulären Betrieb allerdings nicht vorgesehen. Dafür muss der Container mit der gewünschten Konfiguration neu erstellt werden.

Daten im Volume verändern

Nachdem das Volume erfolgreich in den nginx-Container eingebunden wurde, lässt sich sein Inhalt unabhängig vom Container bearbeiten. Änderungen stehen der Anwendung unmittelbar zur Verfügung.

Für den folgenden Versuch wird auf dem Docker-Host eine neue Datei index.html erstellt:

<!DOCTYPE html>
<html lang="de">
<head>
    <meta charset="UTF-8">
    <title>Docker-Volume-Test</title>
</head>
<body>
    <h1>Docker-Volume-Test erfolgreich</h1>
    <p>Diese HTML-Datei liegt in einem benannten Docker-Volume.</p>
</body>
</html>

Anschließend wird die Datei mit docker cp in das HTML-Verzeichnis des laufenden Containers kopiert:

$ sudo docker cp index.html academy-volume-nginx-01:/usr/share/nginx/html/index.html

Der Befehl kopiert die lokale Datei index.html vom Host in den Container academy-volume-nginx-01. Dort ersetzt sie die bereits vorhandene Datei gleichen Namens.

Da das Zielverzeichnis /usr/share/nginx/html mit unserem benannten Volume verbunden ist, wird die Datei unmittelbar im Volume gespeichert und nicht in der beschreibbaren Container-Schicht.

Der tatsächliche Speicherpfad des Volumes auf dem Host muss dafür nicht bekannt sein.

Änderung über den Webserver überprüfen

Nach dem Kopieren lässt sich die Webseite im Browser über http://<Docker-Host>:8082 aufrufen. Anstelle der ursprünglichen nginx-Willkommensseite erscheint die angepasste HTML-Seite. Ein Neustart des Containers ist nicht erforderlich. nginx liest die Datei bei der nächsten entsprechenden HTTP-Anfrage aus dem eingebundenen Volume. Die Änderung betrifft ausschließlich die Daten im Volume. Das zugrunde liegende Docker-Image bleibt unverändert.

Persistenz nach dem Entfernen eines Containers

Ein benanntes Docker-Volume besitzt einen eigenständigen Lebenszyklus. Wird ein Container entfernt, bleiben das Volume und die darin gespeicherten Daten erhalten. Ein anschließend neu erstellter Container kann dasselbe Volume wiederverwenden.

Um dieses Verhalten zu überprüfen, wird der nginx-Container zunächst gestoppt und anschließend entfernt:

$ sudo docker stop academy-volume-nginx-01
$ sudo docker rm academy-volume-nginx-01

Mit docker ps -a lässt sich überprüfen, dass der Container nicht mehr existiert. Das benannte Volume bleibt dagegen weiterhin vorhanden:

$ sudo docker volume ls
DRIVER    VOLUME NAME
local     academy-volume-nginx-01-html

Container mit vorhandenem Volume neu erstellen

Der Container wird nun mit derselben Mount-Konfiguration erneut erstellt.

$ sudo docker create \
  --name academy-volume-nginx-01 \
  --restart unless-stopped \
  -p 8082:80 \
  --mount type=volume,source=academy-volume-nginx-01-html,target=/usr/share/nginx/html \
  nginx:stable-alpine

Und gestartet:

$ sudo docker start academy-volume-nginx-01

Dass zunächst der Container mit docker create erstellt und anschließend mit docker start gestartet wird, ist nur eine Variation des zuvor verwendeten docker run Kommandos. Der Container könnte auch sofort ein weiteres Mal mit docker run erstellt und gleichzeitig gestartet werden.

Da das bereits vorhandene Volume nicht leer ist, findet keine erneute Übernahme der ursprünglichen Dateien aus dem Image statt. Docker verwendet stattdessen die gespeicherten Volume-Daten. Beim erneuten Aufruf von http://<Docker-Host>:8082 erscheint deshalb weiterhin die zuvor angepasste HTML-Seite.

Das Experiment bestätigt, dass die Daten des benannten Volumes unabhängig vom entfernten Container erhalten bleiben (Persistenz) und einem neuen Container zur Verfügung stehen.

Ein Volume in mehreren Containern verwenden

Docker-Volumes können gleichzeitig in mehrere Container eingebunden werden. Dabei lassen sich die Zugriffsrechte für jeden Container getrennt festlegen. Auf diese Weise kann beispielsweise ein Container Daten verändern, während andere Container ausschließlich lesend darauf zugreifen.

Um dieses Verhalten zu untersuchen, wird ein zweiter nginx-Container erstellt. Er verwendet dasselbe Volume academy-volume-nginx-01-html, bindet es jedoch schreibgeschützt ein:

$ sudo docker run -d \
  --name academy-volume-nginx-02 \
  --restart unless-stopped \
  -p 8083:80 \
  --mount type=volume,source=academy-volume-nginx-01-html,target=/usr/share/nginx/html,readonly \
  nginx:stable-alpine

Die zusätzliche Mount-Option readonly verhindert Schreibzugriffe aus dem zweiten Container auf das Volume. Der erste Container behält dagegen seinen bisherigen Lese- und Schreibzugriff.

Da beide nginx-Instanzen auf dieselben HTML-Dateien zugreifen, liefern sie unter http://<Docker-Host>:8082 beziehungsweise http://<Docker-Host>:8083 dieselbe Webseite aus.

Hinweis zur gemeinsamen Datennutzung: Docker stellt den gemeinsamen Speicher bereit, koordiniert jedoch keine konkurrierenden Schreiboperationen der Anwendungen. Wenn mehrere Container gleichzeitig dieselben Daten verändern, muss die Anwendung selbst deren Konsistenz sicherstellen. Für Datenbanken und andere zustandsbehaftete Anwendungen ist dieser Aspekt besonders wichtig.

Zugriffsrechte überprüfen

Die Mount-Konfiguration des zweiten Containers wird mit docker inspect untersucht:

$ sudo docker inspect academy-volume-nginx-02 --format '{{json .Mounts}}' | jq
[
  {
    "Type": "volume",
    "Name": "academy-volume-nginx-01-html",
    "Source": "/var/lib/docker/volumes/academy-volume-nginx-01-html/_data",
    "Destination": "/usr/share/nginx/html",
    "Driver": "local",
    "Mode": "z",
    "RW": false,
    "Propagation": ""
  }
]

Der dargestellte JSON-Ausschnitt beschränkt sich auf die relevanten Eigenschaften. RW: false bestätigt, dass das Volume in diesem Container schreibgeschützt eingebunden ist. Beim ersten Container ist dagegen RW: true gesetzt.

Schreibschutz praktisch überprüfen

Mit docker exec wird versucht, aus dem zweiten Container eine neue Datei im eingebundenen Volume anzulegen:

$ sudo docker exec academy-volume-nginx-02 touch /usr/share/nginx/html/schreibtest.txt
touch: /usr/share/nginx/html/schreibtest.txt: Read-only file system

Volumes verwalten und löschen

Benannte Docker-Volumes existieren unabhängig von den Containern, die sie verwenden. Sie bleiben auch dann erhalten, wenn ein Container gestoppt oder entfernt wird. Ihre Verwaltung und Löschung erfolgt deshalb über eigene Docker-Befehle.

Verwendete Volumes identifizieren

Bevor ein Volume gelöscht wird, sollte überprüft werden, ob es noch einem Container zugeordnet ist. Mit dem Volume-Filter von docker ps lassen sich die betreffenden Container ermitteln:

$ sudo docker ps -a \
  --filter volume=academy-volume-nginx-01-html \
  --format "table {{.Names}}\t{{.Status}}"
NAMES                     STATUS
academy-volume-nginx-02   Up 24 hours
academy-volume-nginx-01   Up 25 hours

Die Ausgabe zeigt die zugeordneten Container einschließlich ihres aktuellen Status. Die Option -a berücksichtigt dabei auch gestoppte Container.

Ein Volume löschen

Zum Löschen eines benannten Volumes dient der Befehl docker volume rm:

$ sudo docker volume rm academy-volume-nginx-01-html
Error response from daemon: remove academy-volume-nginx-01-html: volume is in use - [5e59e2378eb2868a81958ac20f3f935aebf90b4663e3a83567bf397cba7c25a7, 1b0aca617b703f8f95d41beec25163737815a50e6741af8814e1d6dbb3e2636

Da das Volume im vorliegenden Beispiel noch von Containern verwendet wird, verweigert Docker den Löschvorgang. Die Fehlermeldung nennt die IDs der Containers, die das Volume referenzieren.

Erst wenn alle zugeordneten Container entfernt wurden, kann das Volume gelöscht werden. Mit dem Löschen des Volumes gehen auch die darin gespeicherten Daten verloren.

Nicht mehr verwendete Volumes können außerdem mit docker volume prune bereinigt werden. Standardmäßig betrifft dies unbenutzte anonyme Volumes; mit der Option --all können auch unbenutzte benannte Volumes entfernt werden. Vor einer solchen Bereinigung sollte deshalb geprüft werden, welche Daten noch benötigt werden.

Persistenz ersetzt keine Datensicherung

Ein Docker-Volume schützt Daten vor dem Verlust durch das reguläre Entfernen eines Containers. Es schützt jedoch nicht vor versehentlichem Löschen, fehlerhaften Schreiboperationen oder Defekten des zugrunde liegenden Speichersystems. Persistente Anwendungsdaten müssen daher unabhängig vom Container-Lebenszyklus gesichert werden. Die Sicherung und Wiederherstellung von Docker-Volumes und Bind Mounts wird in einem gesonderten Artikel behandelt.

Docker-Volumes und Bind Mounts im Vergleich

Sowohl Docker-Volumes als auch Bind Mounts ermöglichen die persistente Speicherung von Daten außerhalb der beschreibbaren Container-Schicht. Beide Verfahren verwenden denselben grundlegenden Mount-Mechanismus, unterscheiden sich jedoch hinsichtlich der Speicherverwaltung und des Verhaltens beim Einbinden.

Eigenschaft	Bind Mount	Docker-Volume
Speicherort	Vom Administrator festgelegt	Von Docker verwaltet
Einbindung über	Host-Verzeichnispfad	Volume-Name
Eigenständiges Docker-Objekt	Nein	Ja
Automatische Übernahme vorhandener Image-Dateien	Nein	Standardmäßig bei leerem Volume
Gemeinsame Nutzung durch mehrere Container	Möglich	Möglich
Schreibgeschützte Einbindung	Möglich	Möglich
Typische Verwendung	Konfigurationsdateien, Quellcode, gezielte Host-Verzeichnisse	Anwendungsdaten, dauerhafte Datenhaltung

Bind Mounts eignen sich insbesondere dann, wenn ein Container gezielt auf Dateien oder Verzeichnisse des Hosts zugreifen soll. Docker-Volumes sind dagegen häufig die zweckmäßigere Wahl, wenn persistente Anwendungsdaten unabhängig von einem bestimmten Host-Verzeichnispfad verwaltet werden sollen. Welche Methode sinnvoller ist, hängt von den Anforderungen der Anwendung und dem jeweiligen Betriebskonzept ab.

Fazit

Docker-Volumes ermöglichen die persistente Speicherung von Daten unabhängig vom Lebenszyklus einzelner Container. Im Gegensatz zu Bind Mounts übernimmt Docker die Verwaltung des Speicherortes.

Das praktische Beispiel zeigt, wie ein benanntes Volume erstellt, in einen Container eingebunden und nach dessen Entfernung wiederverwendet werden kann. Auch der gleichzeitige Zugriff mehrerer Container mit unterschiedlichen Schreibrechten ist möglich.

Besonders hervorzuheben ist die automatische Übernahme vorhandener Image-Dateien beim erstmaligen Einbinden eines leeren Volumes (Copy-up). Die ursprünglichen Dateien werden dabei nicht verändert, sondern durch den Mount verdeckt.

Docker-Volumes eignen sich insbesondere für die dauerhafte Speicherung von Anwendungsdaten. Sie vereinfachen deren Verwaltung, ersetzen jedoch weder ein geeignetes Berechtigungskonzept noch eine regelmäßige Datensicherung.

Befehlszeilenreferenz

docker volume ls : Vorhandene Docker-Volumes auflisten.
docker volume create NAME : Ein benanntes Volume erstellen.
docker volume inspect NAME : Eigenschaften und Speicherort eines Volumes anzeigen.
docker volume rm NAME : Ein nicht mehr verwendetes Volume löschen.
docker volume prune : Nicht verwendete Volumes bereinigen; mit --all auch unbenutzte benannte Volumes.
docker ps -a --filter volume=NAME : Container ermitteln, die ein bestimmtes Volume verwenden.
docker inspect CONTAINER --format '{{json .Mounts}}' : Mount-Konfiguration eines Containers anzeigen.
docker run --mount type=volume,... : Einen Container mit eingebundenem Volume erstellen und starten.
docker cp QUELLE ZIEL : Dateien zwischen Host und Container kopieren.
docker create : Einen Container erstellen, ohne ihn zu starten.
docker start CONTAINER : Einen vorhandenen Container starten.

1. November 2026

Updated on 1. November 2026

Was this article helpful?

Yes No

About The Author

Pronto

"We are connecting more than computers..."