# Container Storage: Persistenz & Volume Management

TL;DR / Management Summary Ein Container ist flüchtig. Alles, was Sie innerhalb der beschreibbaren Schicht eines Containers speichern, wird beim Löschen der Instanz vernichtet. Für produktive Workloads benötigen wir persistente Speicher. Wir nutzen Docker Volumes (vom Docker-Dienst verwaltet) oder Bind-Mounts (direkte Verknüpfung mit einem Host-Ordner). Ein Senior Admin trennt Code (im Image) strikt von Daten (im Volume) und nutzt Netzwerk-Storage (NFS/Ceph), um Container-Daten über Cluster-Knoten hinweg verfügbar zu machen.

# 1. Das Problem: Ephemeral Storage

Der ‘Goldfisch’-Effekt.

Jeder Container basiert auf einem schreibgeschützten Image. Die Schreib-Ebene obenauf ist:

# 2. Persistenz-Modelle

Daten retten.

# 1. Bind Mounts

Sie verknüpfen einen Ordner am Host direkt mit einem Pfad im Container.

docker run -v /etc/mysql/my.cnf:/etc/mysql/my.cnf mysql

# 2. Docker Volumes (Empfohlen)

Der “saubere” Weg. Docker verwaltet einen Bereich unter /var/lib/docker/volumes/.

docker volume create my_data
docker run -v my_data:/app/data my_app

# 3. Deep Dive: Storage für Datenbanken

IOPS und Konsistenz.

Datenbanken (SQL) sind extrem empfindlich gegenüber Latenz.

# 4. Day-2 Operations: Backup von Volumes

Die Sicherung der Chunks.

Da Volumes oft nur “Ordner” am Host sind:

  1. Stop Container: Um Dateisperren zu vermeiden.
  2. Snapshot: Nutzen Sie die ZFS-Snapshot Funktion Ihres Proxmox-Hosts (Artikel 656).
  3. Backup: Sichern Sie den Ordner /var/lib/docker/volumes/ via Proxmox Backup Server.

# 5. Troubleshooting & “War Stories”

Wenn die Daten ‘verschwinden’.

# Top 3 Fehlerbilder

  1. Symptom: “Permission Denied” beim Schreiben ins Volume.

    • Ursache: Der User im Container (z.B. www-data mit UID 33) hat keine Schreibrechte auf dem Host-Ordner.
    • Lösung: chown -R 33:33 /pfad/am/host.

  2. Symptom: Datenverlust nach Update.

    • Ursache: Der Admin vergaß das -v Flag beim neuen docker run Befehl. Der neue Container startete mit einer leeren Schreib-Ebene.

  3. Symptom: “Stale File Handle” bei NFS-Volumes.

    • Fix: Nutzen Sie NFS v4.1 und prüfen Sie die Locking-Dienste (Artikel 688).

# “War Story”: Der “Auto-Update” Datenkiller

Ein Administrator nutzte ein Script, das nachts alle Container löschte und mit dem neuesten :latest Image startete. Er nutzte Bind-Mounts für die Configs, aber nicht für die User-Uploads. Das Ereignis: Die Applikation lief nach dem Update einwandfrei. Das Ergebnis: Erst nach drei Tagen bemerkten die User, dass alle Profilbilder der letzten 6 Monate verschwunden waren. Da sie nur in der flüchtigen Schreib-Ebene des alten Containers lagen, waren sie unwiederbringlich gelöscht. Lehre: Definieren Sie eine “Persistence Matrix”: Jede App muss dokumentieren, welche Pfade zwingend auf ein Volume gemappt werden müssen.

# 6. Monitoring & Reporting

Füllstände im Blick.

# Docker Disk Usage

Prüfen Sie den Platzverbrauch Ihrer Volumes:

docker system df -v

# 7. Fazit & Empfehlung

Speicher-Management ist die wichtigste Disziplin für den Betrieb von State-full Apps.

# Anhang: Cheatsheet (Volume CLI)

Aufgabe Befehl
Volume erstellen docker volume create <name>
Alle Volumes docker volume ls
Volume Details docker volume inspect <name>
Aufräumen docker volume prune

# Referenzen