Docker Compose Volumes und Backups erklärt

Ich führte docker compose down -v aus, um einen Stack aus Gewohnheit sauber neu zu starten — eine Angewohnheit aus einem anderen Projekt, in dem dieses Flag harmlos war. Hier war es das nicht. Das -v löschte das benannte Volume des Stacks zusammen mit den Containern, und für rund dreißig Sekunden, bevor die restic-Wiederherstellung fertig war, wusste ich schlicht nicht, ob ein Jahr an Vaultwarden-Einträgen überhaupt noch irgendwo existierte.

Der Beinahe-Unfall: was docker compose down -v wirklich löscht

Ein einfaches docker compose down stoppt und entfernt die Container des Stacks sowie sein Standardnetzwerk — alles, was in einem benannten Volume liegt, bleibt unberührt, weil Docker Speicher nicht einfach mal so löscht. Fügen Sie -v (oder --volumes) hinzu, entfernt Compose zusätzlich jedes benannte Volume, das in dieser Compose-Datei deklariert ist, sofort und ohne Rückfrage. Es fragt nicht, welches Volume gemeint ist, und unterscheidet nicht zwischen "das war Absicht" und "das Flag stammte noch aus einem anderen Terminal-Verlauf". Ich hatte ein restic-Backup, und die Wiederherstellung funktionierte — aber die dreißig Sekunden zwischen dem Ausführen des Befehls und der Bestätigung machten den Unterschied zwischen einer Anekdote und einem echten Datenverlust-Vorfall.

Bind Mounts vs. benannte Volumes in einer Tabelle

	Bind Mount	Benanntes Volume
Speicherort	Ein bestimmter, selbst gewählter Ordner auf dem Host	Von Docker verwaltet, unter dessen eigenem Speicherpfad
Sichtbarkeit auf dem Host	Direkt — jederzeit per ls einsehbar	Indirekt — nur über docker volume-Befehle prüfbar
Portabilität zwischen Hosts	An genau diesen Host-Pfad gebunden	Portabler; die App macht keine Annahmen über das Host-Layout
Backup-Methode	Ein Backup-Tool direkt auf den Ordner zeigen lassen	Braucht einen Hilfscontainer oder das eigene Export-Tool der App
Typischer Einsatz hier	Configs, Medien, alles direkt gesicherte	Datenbank-Engine-Daten (Postgres, MariaDB)

Bind Mounts: ein Host-Ordner als Speicher eines Containers

Ein Bind Mount ist eine direkte Verbindung von einem Host-Pfad zu einem Container-Pfad — ./vw-data:/data bindet den Ordner vw-data, der neben der Compose-Datei liegt, direkt in den Container ein. Weil es ein echter, sichtbarer Ordner auf dem Host ist, funktioniert jedes Backup-Tool, das bereits weiß, wie man ein Verzeichnis sichert — restic, rsync, ein NAS-Sync-Job — ohne jede container-spezifische Logik darauf. Genau deshalb liegen Configs und Medien in diesem Homelab auf Bind Mounts: Der Backup-Schritt muss nicht einmal wissen, dass Docker existiert.

Benannte Volumes: von Docker verwalteter Speicher

Ein benanntes Volume — einmal unter dem obersten volumes:-Schlüssel einer Compose-Datei deklariert und über seinen Namen referenziert — liegt unter Dockers eigenem Speicherpfad (/var/lib/docker/volumes/ unter Linux) statt an einem selbst gewählten Pfad. Diese Indirektion ist ein Feature für alles, das keine Annahmen über den Host machen sollte: Eine Datenbank-Engine verwaltet ihr eigenes Datei-Layout innerhalb dieses Volumes und kümmert sich nicht darum, wo Docker es physisch ablegt. Der Preis dafür ist, dass eine Sicherung keine simple Ordnerkopie ist — sie braucht entweder einen Hilfscontainer oder das eigene Export-Tool der Datenbank.

Die tatsächliche Storage-Wahl dieses Homelabs, Dienst für Dienst

Dienst	Speicherart	Warum
Vaultwarden (/data)	Bind Mount	Das Backup-Ziel für restic muss ein einfacher Ordner sein, kein von Docker verwalteter Pfad
Caddy-Konfiguration und Zertifikate	Bind Mount	Wird oft genug von Hand bearbeitet, dass direkter Host-Zugriff zählt
Jellyfin-Medienbibliothek	Bind Mount auf bestehenden NAS-Speicher	Der Raspberry-Pi-NAS besitzt diesen Speicher bereits; Jellyfin zeigt einfach darauf
Postgres-Datenverzeichnis	Benanntes Volume	Datenbankdateien sollten nicht live roh kopiert werden; sichern Sie mit pg_dump, nicht mit einer Ordnerkopie

Vollständige Details zum Bind-Mount-Aufbau von Vaultwarden finden Sie im Vaultwarden-Selbsthosting-Guide.

Einen Bind Mount sichern

Kein Container nötig — das Backup-Tool zeigt direkt auf den Ordner:

restic backup ./vw-data --tag vaultwarden

Ein benanntes Volume korrekt sichern

Für ein benanntes Volume mit reinen Dateien (keine laufende Datenbank) übernimmt ein kurzlebiger Hilfscontainer, der sowohl das Volume als auch einen Host-Ordner einbindet, das Archivieren:

docker run --rm \
  -v vw_internal_data:/source:ro \
  -v "$(pwd)/backup":/backup \
  alpine tar czf /backup/volume-backup.tar.gz -C /source .

Entscheidungshilfe: Bind Mount oder benanntes Volume?

Diensttyp	Empfehlung	Warum
Konfigurationsdateien, Zertifikate, alles von Hand Bearbeitete	Bind Mount	Direkter Host-Zugriff; einfache Ordner-Sicherung
Medienbibliotheken und bereits vorhandener NAS-Speicher	Bind Mount	Zeigt auf Speicher, der schon außerhalb von Docker existiert
Datenbank-Engine-Daten (Postgres, MariaDB, Redis-Persistenz)	Benanntes Volume + das eigene Dump-Tool der Engine	Vermeidet das Korruptionsrisiko einer rohen Kopie live laufender Daten
App-Daten ohne laufende Schreibvorgänge (statischer App-Zustand)	Beides möglich — Bind Mount für direkte Sichtbarkeit	Ein benanntes Volume geht ebenso gut; das Risiko betrifft speziell laufende Datenbanken

Die Storage-Wahl ist unabhängig von der Restart-Policy des Dienstes — siehe den Restart-Policies-Guide — und unabhängig davon, welchem Netzwerk er beitritt, behandelt im Docker-Compose-Netzwerke-Guide. Alle drei sind separate, pro Dienst getroffene Entscheidungen, kein globaler Standard für den ganzen Stack.

Fazit

Legen Sie Configs und Medien auf Bind Mounts, damit jedes generische Backup-Tool sie direkt erreicht. Legen Sie laufende Datenbankdaten auf benannte Volumes und sichern Sie sie mit dem eigenen Tool der Datenbank, nie mit einer rohen Kopie. Stellen Sie dann tatsächlich einmal ein Backup wieder her, bevor docker compose down -v diese Aufgabe ungefragt für Sie übernimmt.

Häufig gestellte Fragen

Löscht docker compose down Volumes?

Nein, nicht standardmäßig. Ein einfaches docker compose down entfernt Container und das Standardnetzwerk, lässt benannte Volumes aber unangetastet. Erst das zusätzliche Flag -v (oder --volumes) löscht die in dieser Compose-Datei deklarierten benannten Volumes.

Was ist der Unterschied zwischen einem Bind Mount und einem benannten Volume?

Ein Bind Mount bindet einen selbst gewählten Ordner auf dem Host in den Container ein, sodass Sie ihn direkt durchsuchen und sichern können. Ein benanntes Volume ist Speicher, den Docker selbst unter seinem eigenen Pfad verwaltet — besser isoliert von Host-Pfad-Annahmen, aber für die Sicherung auf einen Hilfscontainer oder das eigene Tool der App angewiesen.

Wie sichert man ein benanntes Docker-Volume?

Führen Sie einen kurzlebigen Container aus, der das benannte Volume schreibgeschützt zusammen mit einem Host-Backup-Ordner einbindet, und archivieren Sie den Inhalt des Volumes dann mit tar. Für eine laufende Datenbank nutzen Sie stattdessen das eigene Export-Tool der Engine (pg_dump, mysqldump) statt einer rohen Dateikopie.

Ist es sicher, das Docker-Volume einer Datenbank direkt für ein Backup zu kopieren?

Nicht, während die Datenbank läuft. Eine rohe Kopie der Dateien einer laufenden Datenbank kann sie mitten im Schreibvorgang erwischen und ein Backup erzeugen, das vollständig wirkt, sich aber nicht sauber wiederherstellen lässt. Nutzen Sie stattdessen das eigene Dump-Tool der Datenbank-Engine gegen den laufenden Container.