Docker Volumes – Persistenz und Backups

Container sind schnell gestartet – aber ohne Plan für Persistenz sind deine Daten beim nächsten Update oder Crash weg. Genau hier kommen Docker Volumes ins Spiel: Sie trennen Daten vom Container-Lebenszyklus und sorgen dafür, dass Informationen erhalten bleiben, auch wenn ein Container neu gebaut oder gelöscht wird.

Damit du nicht nur speicherst, sondern auch absicherst, brauchst du zusätzlich eine saubere Backup-Strategie. In diesem Einsteiger-Guide zeige ich dir, wie Docker Volumes funktionieren, wann du sie statt Bind Mounts verwendest und wie du Backups und Restores mit wenigen Befehlen zuverlässig umsetzt – Schritt für Schritt und leicht verständlich.

Was sind Docker Volumes und warum sind sie wichtig?

Docker Volumes sind von Docker verwaltete Datenbereiche außerhalb des Container-Dateisystems. Sie sind ideal für Datenbanken, Uploads oder Konfigurationsstände, die ein Container lesen/schreiben muss, ohne dass sie beim Neuaufsetzen verloren gehen. Vorteil: Docker kümmert sich um Pfadverwaltung, Rechte (grundsätzlich) und einfache Portabilität zwischen Hosts.

Volumes vs. Bind Mounts vs. tmpfs

• Volumes: von Docker verwaltet, liegen standardmäßig unter /var/lib/docker/volumes/.... Empfehlung für die meisten persistierenden Daten.
• Bind Mounts: binden einen Host-Ordner ein (z. B. ./data:/var/lib/app). Gut für lokale Entwicklung, weil du Dateien direkt siehst. In Produktion anfälliger für Pfad-/Rechteprobleme.
• tmpfs: landen im RAM (flüchtig). Ideal für hochfrequente, temporäre Daten (z. B. Caches), nicht für Persistenz.

Volumes anlegen und verwenden

Benanntes Volume erstellen

Mit benannten Volumes behältst du den Überblick:

docker volume create mydata
docker run -d --name app -v mydata:/var/lib/app myimage:latest

Der Container schreibt nach /var/lib/app, die Daten liegen sicher im Volume mydata.

Mit Docker Compose arbeiten

Compose macht es deklarativ und portabel:

services:
  db:
    image: postgres:16
    volumes:
      - dbdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=secret
volumes:
  dbdata:
    labels:
      purpose: "prod-db"

Starte alles mit docker compose up -d. Das named volume dbdata bleibt erhalten, selbst wenn der Service neu gebaut wird.

Best Practices für stabile Persistenz

Eindeutige Mount-Pfade

Lege klare, dokumentierte Pfade im Container fest (z. B. /var/lib/app, /var/lib/postgresql/data). So weiß jeder sofort, wo die Daten liegen.

Rechte & Nutzer-IDs verstehen

Container-Prozesse laufen oft nicht als root. Achte darauf, dass der User im Container Schreibrechte hat. Falls nötig:

docker run --rm -v mydata:/data alpine sh -c 'chown -R 999:999 /data'

(Ersetze 999:999 durch die UID:GID deines Dienstes.)

Labels & Namenskonventionen

Nutze sprechende Namen (project_env_service_data) und Labels (owner=team-x, backup=true). Das erleichtert Monitoring und Backups.

Ein Volume pro Zweck

Mische nicht alles in ein Volume. Trenne z. B. Daten, Logs und Uploads. Das macht Backups kleiner und Restores gezielter.

Backups: einfach, schnell und zuverlässig

Einmaliges Tar-Backup eines Volumes

Mit einem kurzlebigen Hilfscontainer sicherst du ein Volume als tar.gz:

# Linux/macOS
docker run --rm \
  -v mydata:/data \
  -v "$PWD":/backup \
  alpine sh -c 'tar -czf /backup/mydata-$(date +%F).tgz -C /data .'

Das erzeugt im aktuellen Ordner eine Datei wie mydata-2025-09-19.tgz. Die Kompression spart Platz, die Struktur bleibt erhalten.

Restore aus einem Tar-Backup

Vorher Container stoppen, damit keine Schreibzugriffe stattfinden:

docker stop app

docker run --rm \
  -v mydata:/data \
  -v "$PWD":/backup \
  alpine sh -c 'rm -rf /data/* && tar -xzf /backup/mydata-2025-09-19.tgz -C /data'
  
docker start app

Passe den Dateinamen an dein Backup an. Mit rm -rf /data/* stellst du sicher, dass keine alten Fragmente übrig bleiben.

Automatisierte Backups (Cron)

Erstelle ein kleines Shell-Script, das täglich sichert, rotiert und löscht (z. B. nach 7/14/30 Tagen). Plane es per cron oder nutze einen dedizierten Backup-Container, der regelmäßig läuft. Wichtig: Prüfe Backups gelegentlich mit einem Test-Restore – nur getestete Backups sind wertvoll.

Sicherheit & Pflege

Secrets und Schlüssel

Keine Schlüssel oder Datenbank-Dumps im Image ablegen. Leite Credentials über Docker Secrets oder Umgebungsvariablen ein und sichere Volumes mit zugriffsbeschränkten Rechten.

Monitoring und Alarme

Überwache Füllstände (docker system df, Host-Disk) und Backup-Erfolg (Exit-Codes, Log-Zeilen). Ein simpler Check, der das Ablaufdatum der letzten Sicherung prüft, verhindert böse Überraschungen.

Migration & Portabilität

Um Volumes zwischen Hosts zu übertragen, kopierst du das Tar-Backup und spielst es auf dem Zielhost in ein frisches Volume ein. Für große Installationen können Volume-Driver (z. B. NFS, Ceph) sinnvoll sein – für Einsteiger reicht meist der local driver.

Häufige Fehler – und wie du sie vermeidest

Ein häufiger Stolperstein ist der Wechsel zwischen Volume und Bind Mount ohne zu wissen, wo die Daten liegen. Dokumentiere deine Mounts in README/Compose-Dateien. Verlasse dich nicht auf Container-Dateisysteme (Layer) für Persistenz – Container können ersetzt werden. Sichere immer das Volume, nicht nur eine Kopie im Container. Und denke daran, vor einem Restore Dienste zu stoppen, damit keine konkurrierenden Schreibzugriffe passieren.

Fazit

Mit Docker Volumes trennst du lebende Daten sauber vom Container-Image und machst deine Umgebung update-fest. Eine schlanke Backup-Routine mit tar.gz, klaren Namespaces und gelegentlichen Test-Restores sorgt dafür, dass du im Notfall schnell wieder lauffähig bist. Hältst du dich an klare Pfade, korrekte Rechte und automatisierte Abläufe, bleiben deine Container-Setups robust, sicher und pflegeleicht.