Docker Volume: Container-Daten dauerhaft sichern

Ein docker volume ist eine persistente Speichereinheit, die deine Daten am Leben hält, selbst wenn ein Container entfernt, neu erstellt oder sein Image aktualisiert wird. Container sind in Docker bauartbedingt flüchtig: Wenn du einen mit docker rm entfernst, verschwindet alles in seiner beschreibbaren Schicht mit ihm. Liegen Datenbankdateien, hochgeladene Bilder oder Anwendungs-Logs in dieser Schicht, kann ein einziges docker compose down stundenlang angesammelte Daten löschen. Volumes existieren genau dafür, dieses Problem zu lösen.

Warum es riskant ist, Daten im Container zu schreiben

Ein Docker-Image besteht aus gestapelten, schreibgeschützten Schichten. Wenn ein Container läuft, wird obenauf eine dünne beschreibbare Schicht hinzugefügt, in die jede Änderung geschrieben wird. Diese Schicht ist an die Lebensdauer des Containers gebunden; ist der Container weg, ist auch die Schicht weg. Die Folge:

• Den Container neu zu erstellen (Image-Update, Konfigurationsänderung) löscht die Daten.
• Festplattenzugriff über die beschreibbare Schicht ist langsamer als direktes Schreiben auf die Platte.
• Die Daten von außerhalb des Containers zu sichern oder mit einem anderen Container zu teilen, wird schwierig.

Alles, was bestehen bleiben muss, sollte außerhalb des Container-Dateisystems leben, in einem von Docker verwalteten Bereich. Dieser Bereich ist ein Volume.

Volume, Bind Mount und tmpfs

Docker bietet drei Arten von Mounts, und es ist wichtig zu wissen, welche du wählst:

• Volume: von Docker auf dem Host unter /var/lib/docker/volumes/ verwaltet. Es ist portabel, leicht zu sichern und die empfohlene Option für die Produktion.
• Bind Mount: bindet einen bestimmten Host-Ordner (wie /home/user/projekt) direkt in den Container ein. Ideal, um Code während der Entwicklung live zu bearbeiten, aber eng an die Host-Struktur gekoppelt.
• tmpfs: hält Daten nur im RAM; sie sind weg, sobald der Container stoppt. Wird für temporäre oder sensible Daten verwendet.

Eine einfache Regel: Verwende ein Volume, wenn die Daten zu Docker gehören sollen, und einen Bind Mount, wenn du sie an ein echtes Verzeichnis auf dem Host binden willst.

Ein Volume erstellen und verwenden

Das häufigste Szenario ist, ein benanntes Volume zu erstellen und an einen Container anzuhängen:

docker volume create db_data

docker run -d \
  --name postgres \
  -v db_data:/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD=geheim \
  postgres:16

Der Teil -v db_data:/var/lib/postgresql/data sagt: Hänge das Volume namens db_data an das Datenverzeichnis von PostgreSQL im Container an. Entfernst du den Container und startest ihn mit demselben Volume neu, ist die Datenbank noch da. Um vorhandene Volumes zu prüfen:

docker volume ls
docker volume inspect db_data

Persistente Daten mit Compose

In echten Projekten definierst du Volumes meist in docker-compose.yml. Das folgende Beispiel betreibt eine Datenbank mit einem persistenten Volume:

services:
  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: geheim
    volumes:
      - mysql_data:/var/lib/mysql

volumes:
  mysql_data:

Der oberste volumes:-Block deklariert das benannte Volume, und die Zeile innerhalb des Service hängt es ein. docker compose down entfernt die Container, behält aber das Volume mysql_data; docker compose up bringt die Daten zurück. Willst du das Volume ebenfalls entfernen, führst du bewusst docker compose down -v aus.

Ein Volume sichern und wiederherstellen

Da Volumes eingebettet im Host-Dateisystem liegen, ist der saubere Weg, eines zu sichern, seinen Inhalt mit einem Wegwerf-Hilfscontainer zu archivieren:

# Sichern: db_data-Volume als tar.gz speichern
docker run --rm \
  -v db_data:/data \
  -v $(pwd):/backup \
  alpine tar czf /backup/db_data.tar.gz -C /data .

# Wiederherstellen: das Archiv in ein leeres Volume entpacken
docker run --rm \
  -v db_data:/data \
  -v $(pwd):/backup \
  alpine tar xzf /backup/db_data.tar.gz -C /data

Dieser Ansatz hängt einen winzigen alpine-Container an das Volume und das aktuelle Verzeichnis an und komprimiert es dann mit tar. Für Datenbanken fügt das Erstellen logischer Backups wie mysqldump oder pg_dump eine zweite Schicht hinzu, die sicherer gegen Beschädigung ist.

Häufige Fehler

• Den falschen Pfad einhängen: Wenn du das Volume nicht an das Verzeichnis hängst, in das die App tatsächlich schreibt (z. B. /var/lib/postgresql/data bei PostgreSQL), bleibt nichts erhalten.
• Berechtigungsprobleme: Wenn die Benutzer-ID im Container nicht zum Dateieigentümer im Volume passt, bekommst du "permission denied"-Fehler.
• Anonyme Volumes ansammeln: Ohne Namen erstellte Volumes häufen sich an und füllen mit der Zeit die Festplatte; räume sie mit docker volume prune auf (vorsichtig).

Häufige Fragen

Soll ich ein Volume oder einen Bind Mount wählen?

In der Produktion wähle ein Volume, wenn die Daten portabel und von Docker verwaltet sein sollen. Während der Entwicklung ist ein Bind Mount praktischer, wenn du Host-Code live bearbeiten willst.

Wenn ich den Container lösche, wird das Volume auch gelöscht?

Nein. Benannte Volumes sind unabhängig vom Container und werden durch docker rm nicht entfernt. Nur ein expliziter Befehl wie docker volume rm oder docker compose down -v entfernt das Volume.

Können sich mehrere Container dasselbe Volume teilen?

Ja, du kannst dasselbe Volume an mehrere Container anhängen. Bei Diensten, die einen einzigen Schreiber erwarten, wie Datenbanken, kann paralleles Schreiben in dasselbe Volume jedoch zu Beschädigung führen; plane das sorgfältig.

Überlasse deine Daten nicht der Gnade eines Containers. Wenn du Hilfe bei einer Docker-Volume-Strategie, Backups oder dem Aufbau von Container-Infrastruktur brauchst, nimm Kontakt mit mir auf.