Backups für Docker Volumes richtig umsetzen

Wer Docker produktiv nutzt, muss früher oder später auch an Backups denken. Das Problem dabei: Viele sichern nur ihre docker-compose.yml oder nur den Container, vergessen aber die eigentlichen Daten im Volume. Genau dort liegen bei den meisten Anwendungen aber Datenbanken, Uploads, Einstellungen oder andere wichtige Inhalte.

Die offizielle Docker-Dokumentation beschreibt Volumes ausdrücklich als bevorzugten Mechanismus für persistente Daten und zeigt auch einen sauberen Weg zum Sichern und Wiederherstellen per zusätzlichem Container. Genau auf diesem Prinzip bauen wir in dieser Anleitung auf.

Wir schauen uns an, wie du Docker Volumes sauber sicherst, was du zusätzlich dokumentieren solltest und wie ein Restore im Ernstfall funktioniert.

1. Was du bei Docker-Backups wirklich sichern musst

Ein vollständiges Docker-Backup besteht in der Praxis meist aus mehreren Teilen:

• der Compose-Datei oder sonstigen Container-Konfiguration
• Umgebungsdateien wie .env
• den eigentlichen persistenten Daten im Docker Volume
• optional zusätzlichen Bind Mount Dateien

Wichtig: Nur den Container zu sichern bringt oft wenig. Der Container selbst ist meist schnell neu gebaut. Entscheidend sind fast immer die Daten im Volume und die Information, wie der Container später wieder korrekt gestartet werden muss.

2. Vorhandene Volumes prüfen

Schau dir zuerst an, welche Volumes auf deinem System vorhanden sind:

docker volume ls

Wenn du genauere Informationen zu einem bestimmten Volume brauchst, kannst du es inspizieren:

docker volume inspect paperless_data

So findest du Name, Mountpoint und weitere Details. Für die meisten Backups reicht der Volume-Name.

3. Backup-Ordner anlegen

Lege auf dem Host einen Ordner an, in den deine Sicherungen geschrieben werden:

sudo mkdir -p /srv/backups/docker
sudo chown $USER:$USER /srv/backups/docker

Damit hast du einen klaren Ort für deine Archivdateien und kannst diese später leichter weiterkopieren oder automatisieren.

4. Ein Docker Volume sauber sichern

Docker zeigt in der offiziellen Doku den klassischen Weg über einen temporären Container, der das Volume einhängt und den Inhalt als Archiv in einen Host-Ordner schreibt.

Ein praxistaugliches Beispiel sieht so aus:

docker run --rm \
  -v paperless_data:/source:ro \
  -v /srv/backups/docker:/backup \
  alpine \
  tar czf /backup/paperless_data_2026-03-20.tar.gz -C /source .

Was hier passiert:

• das Volume paperless_data wird schreibgeschützt eingebunden
• der Host-Ordner /srv/backups/docker wird als Ziel gemountet
• ein temporärer Alpine-Container erstellt das komprimierte Archiv

Danach liegt dein Backup als .tar.gz Datei auf dem Host.

5. Prüfen, ob das Archiv wirklich existiert

Kontrolliere danach immer direkt, ob die Datei tatsächlich geschrieben wurde:

ls -lh /srv/backups/docker

Wenn du ganz sicher gehen willst, kannst du auch kurz in das Archiv hineinsehen:

tar -tzf /srv/backups/docker/paperless_data_2026-03-20.tar.gz | head

Genau dieser kurze Check spart später böse Überraschungen mit leeren oder beschädigten Backups.

6. Vor dem Backup: Anwendung möglichst konsistent halten

Bei einfachen Dateianwendungen reicht ein laufendes Backup oft schon aus. Sobald aber Datenbanken oder sehr schreibintensive Anwendungen beteiligt sind, solltest du vorsichtiger sein.

Je nach Anwendung ist es sinnvoll, vor dem Backup kurz anzuhalten:

docker compose stop

Oder gezielt nur den betroffenen Dienst zu stoppen:

docker compose stop app

Danach führst du das Backup aus und startest die Anwendung wieder:

docker compose start

Das reduziert das Risiko inkonsistenter Datenstände deutlich. Besonders bei Datenbanken ist das oft die bessere Wahl.

7. Compose-Datei und .env nicht vergessen

Ein Volume-Backup allein reicht im Ernstfall oft noch nicht. Du solltest zusätzlich auch die Konfigurationsdateien deiner Anwendung sichern:

cp docker-compose.yml /srv/backups/docker/docker-compose.yml
cp .env /srv/backups/docker/.env

Wenn du mehrere Projekte hast, ist es sinnvoll, pro Anwendung einen eigenen Backup-Ordner oder zumindest eine klare Benennung zu verwenden.

8. Restore eines Docker Volumes

Auch das Wiederherstellen läuft sauber über einen temporären Container. Er mountet ein leeres oder bestehendes Ziel-Volume und entpackt das Archiv dort hinein.

Erstelle das Volume bei Bedarf zuerst:

docker volume create paperless_data

Danach spielst du das Archiv zurück:

docker run --rm \
  -v paperless_data:/restore \
  -v /srv/backups/docker:/backup \
  alpine \
  sh -c "cd /restore && tar xzf /backup/paperless_data_2026-03-20.tar.gz"

Wenn der Container danach wieder mit demselben Volume startet, sollte er seine Daten in genau dem Zustand vorfinden, der im Archiv gesichert wurde.

9. Restore auch wirklich testen

Ein Backup ist erst dann wirklich etwas wert, wenn du den Restore zumindest einmal getestet hast. Genau daran scheitern in der Praxis erstaunlich viele Setups.

Mein klarer Rat:

• lege testweise ein neues Volume an
• spiele das Backup dort zurück
• starte die Anwendung testweise mit diesem Volume
• prüfe, ob Daten und Einstellungen wirklich vorhanden sind

Gerade bei Nextcloud, Paperless, Immich, Datenbanken oder Git-Diensten ist das extrem wichtig.

10. Offsite-Backups mitdenken

Ein Backup auf demselben Server schützt nicht gegen Totalausfall des Hosts. Deshalb solltest du deine Archivdateien zusätzlich an einen zweiten Ort kopieren, zum Beispiel:

• auf ein NAS
• auf einen zweiten Server
• in ein S3-kompatibles Objekt-Storage
• auf verschlüsselte externe Datenträger

Die eigentliche Docker-Sicherung ist also nur der erste Schritt. Für ein belastbares Konzept brauchst du zusätzlich mindestens eine zweite Kopie außerhalb des Systems.

11. Automatisierung per Cron

Wenn du das regelmäßig machen willst, kannst du das Backup in ein kleines Shell-Skript auslagern und per Cron automatisieren. Ein minimales Beispiel:

#!/usr/bin/env bash
set -euo pipefail

DATE=$(date +%F)
VOLUME="paperless_data"
TARGET="/srv/backups/docker"

mkdir -p "$TARGET"

docker run --rm \
  -v ${VOLUME}:/source:ro \
  -v ${TARGET}:/backup \
  alpine \
  tar czf /backup/${VOLUME}_${DATE}.tar.gz -C /source .

Danach könnte ein Cronjob das Skript zum Beispiel jede Nacht ausführen. Wichtig ist aber auch hier: Logs prüfen und Restore später testweise nachvollziehen.

12. Typische Fehler vermeiden

Diese Punkte sehe ich in der Praxis besonders oft:

• nur Container sichern, aber nicht die Volumes
• keine Compose-Datei oder .env mit sichern
• Backup nie testen
• Archiv lokal speichern, aber nie offsite kopieren
• laufende Datenbanken im ungünstigen Moment sichern

Wenn du diese Fehler vermeidest, bist du schon deutlich besser aufgestellt als viele Standard-Setups.

13. Fazit

Docker Volumes sauber zu sichern ist kein Hexenwerk, aber man sollte es bewusst und reproduzierbar tun. Der offizielle Docker-Weg über einen temporären Container mit eingehängtem Volume ist simpel, transparent und sehr gut automatisierbar.

Die wichtigste Erkenntnis ist dabei: Nicht nur Daten sichern, sondern auch die Startkonfiguration deiner Container. Erst aus Volume-Backup plus Compose- beziehungsweise Umgebungsdateien entsteht ein wirklich brauchbarer Wiederherstellungsplan.

Tipp:
Wenn du mehrere Self-Hosted-Dienste betreibst, lohnt sich als nächster Schritt oft ein zentrales Backup-Skript pro Host oder Projekt, damit nicht jede Anwendung ihr eigenes halbes Backup-System erfindet.