Docker-Volumes sichern in 2026: Ein Self-Hosting-Leitfaden

Um ein Docker-Volume zu sichern, hängen Sie es in einen temporären Container ein und archivieren es – Sie können nicht einfach den Ordner unter /var/lib/docker/volumes kopieren und sich darauf verlassen. Der Einzeiler, der für die meisten Volumes funktioniert, ist ein Wegwerf-Alpine-Container, der die Daten in eine Datei tart, die Sie selbst kontrollieren. Die unbequemere Wahrheit, die die meisten Tutorials auslassen: Ein laufendes Datenbank-Volume, das auf diese Weise kopiert wird, ist oft auf subtile Weise beschädigt – und ein Backup, das Sie noch nie wiederhergestellt haben, ist kein Backup. Dieser Leitfaden behandelt die genauen Befehle, den korrekten Umgang mit Datenbanken, die Automatisierung samt Auslagerung der Kopien an einen externen Ort und den Nachweis, dass das Backup tatsächlich funktioniert.

Wie sichert man ein Docker-Volume?

Die Standardmethode besteht darin, einen kurzlebigen Container auszuführen, der Ihr benanntes Volume schreibgeschützt einhängt und einen komprimierten Tarball in ein per Bind-Mount eingebundenes Verzeichnis auf dem Host schreibt. Ein einziger Befehl erledigt das:

docker run --rm \
  -v mydata:/source:ro \
  -v $(pwd)/backups:/backup \
  alpine tar czf /backup/mydata-$(date +%Y%m%d-%H%M%S).tar.gz -C /source .

Das startet Alpine, hängt das Volume mydata als /source (schreibgeschützt) ein und schreibt ein mit Zeitstempel versehenes .tar.gz in ./backups auf dem Host. Der OneUptime-Backup-Leitfaden verwendet dasselbe schreibgeschützte tar-Muster, was einem kanonischen Vorgehen am nächsten kommt. Es funktioniert, weil Dockers eigene Dokumentation anmerkt, dass Volumes leichter zu sichern sind als Bind-Mounts – die Daten liegen an einem einzigen verwalteten Ort. Für einen zustandslosen App-Cache oder einen Dateispeicher reicht das völlig aus. Für alles, was eine Datenbank enthält, nicht.

Warum das Kopieren eines laufenden Volumes nicht ausreicht

Backups auf Dateisystemebene setzen voraus, dass sich die Dateien auf der Festplatte in dem Moment, in dem Sie sie lesen, in einem konsistenten Zustand befinden. Eine laufende Datenbank ist das selten. Postgres, MySQL und MongoDB puffern Schreibvorgänge im Arbeitsspeicher und schreiben sie nach eigenem Zeitplan auf die Festplatte, sodass das Tarren eines laufenden Datenverzeichnisses eine halb geschriebene Transaktion oder einen Index erfassen kann, der auf Zeilen verweist, die noch nicht angekommen sind. Die Wiederherstellung schlägt dann fehl oder lädt – schlimmer noch – stillschweigend beschädigte Daten. Die Faustregel aus der Praxis lautet, dass datenbankspezifische Dumps transaktional konsistent sind, anders als Backups auf Dateisystemebene. Sie haben zwei sichere Optionen: den Container vor dem Tarren stoppen (in Ordnung für ein Home-Lab, schlecht für alles, was Verfügbarkeit braucht) oder das eigene Dump-Werkzeug der Datenbank verwenden, während sie weiterläuft. Die zweite Option ist fast immer die richtige Antwort.

Datenbanken mit Dumps sichern, nicht mit tar

Bei einer containerisierten Datenbank erstellen Sie einen logischen Dump mit dem nativen Werkzeug der Engine und sichern die Dump-Datei statt des rohen Volumes. Das erzeugt einen konsistenten Snapshot, selbst während die Datenbank laufenden Datenverkehr bedient. Für Postgres liefert pg_dump mit --single-transaction einen konsistenten Point-in-Time-Export ohne lange Sperren, gemäß der offiziellen PostgreSQL-Dokumentation:

docker exec -t my-postgres \
  pg_dump -U postgres --single-transaction mydb \
  | gzip > backups/mydb-$(date +%Y%m%d).sql.gz

MySQL und MariaDB verwenden mysqldump --single-transaction (konsistent für InnoDB-Tabellen); MongoDB verwendet mongodump. Bei der Automatisierung kommt es auf die Reihenfolge an: Erst die Datenbank dumpen, dann das Volume- oder Off-Site-Backup über das Verzeichnis laufen lassen, das nun den frischen Dump enthält. Wenn Sie einen kompletten Backend-Stack selbst hosten, gilt dieselbe Logik für das darunter laufende Postgres – der Leitfaden für das produktive Self-Hosting von Supabase setzt auf dasselbe Muster „erst dumpen, dann speichern“ statt Datendateien zu kopieren.

Automatisieren: Tools vs. restic

Diese Befehle einmal von Hand auszuführen ist einfach; daran zu denken, sie jede Nacht auszuführen, ist der Punkt, an dem Self-Hoster scheitern. Zwei ausgereifte Ansätze automatisieren die gesamte Schleife. Ein speziell dafür gebauter Container wie offen/docker-volume-backup übernimmt Planung, Rotation und Upload in einem einzigen Image: Er sichert Volumes auf S3, WebDAV, Azure Blob, Dropbox, Google Drive oder SSH-Ziele, mit optionaler GPG-Verschlüsselung und automatischer Rotation alter Backups und kann einen Container während des Laufs stoppen, um die Integrität zu wahren, wenn Sie ihn entsprechend labeln. Die Alternative ist restic, das verschlüsselte, deduplizierte, inkrementelle Backups bietet auf nahezu jedes Backend – ein gängiges Muster behält --keep-daily 7 --keep-weekly 4 --keep-monthly 6 und speichert dank Deduplizierung bei jedem nächtlichen Lauf nur das, was sich geändert hat.

Methode	Online (ohne Stopp)?	Off-Site-Ziele	Verschlüsselung	Am besten für
tar-Einzeiler	Nein (Stopp bei DBs)	Manuelle Kopie	Keine (GPG ergänzen)	Schnelle, spontane Snapshots
offen/docker-volume-backup	Optionaler Stopp	S3, WebDAV, Azure, Dropbox, GDrive, SSH	GPG	Volume-Backups nach dem Set-and-Forget-Prinzip
restic	Ja (mit Dumps)	S3, B2, SFTP, REST, lokal	Integriert	Deduplizierte, versionierte Historie
DB-Dump (pg_dump)	Ja	Pipe an jedes der obigen	Über das Ziel	Datenbanken, immer

Für die meisten selbst gehosteten Stacks ist die Gewinnerkombination ein nächtlicher pg_dump (oder mysqldump), der einen restic-Lauf speist, der eine verschlüsselte, deduplizierte Kopie vom Server auslagert.

Die 3-2-1-Regel anwenden und auslagern

Ein Backup auf demselben VPS wie die Daten schützt Sie vor einem fehlerhaften Deploy, nicht vor dem Ausfall des Servers, einer Zahlungslücke oder Ransomware. Die altbewährte 3-2-1-Regel behebt das: Bewahren Sie 3 Kopien Ihrer Daten auf, auf 2 verschiedenen Medien, mit 1 außer Haus. In der Praxis bedeutet das: das laufende Volume, ein lokales Backup-Verzeichnis und eine Kopie auf entferntem Objektspeicher. Off-Site-Speicher ist billig genug, dass Kosten keine Ausrede sind. Stand Juli 2026 kostet Hetzners Storage Box BX11 €3.20/Monat für 1 TB über SSH/SFTP – ein natürliches restic- oder rsync-Ziel –, während Backblaze B2 rund $7 pro TB pro Monat kostet mit einer S3-kompatiblen API, die sowohl restic als auch offen/docker-volume-backup nativ sprechen. Beides macht aus dem Off-Site-Backup ein paar Euro im Monat. Wenn Sie nach den VPS-Preiserhöhungen 2026 ohnehin schon auf Ihre Rechnung achten, ist Objektspeicher für Backups der letzte Ort zum Sparen.

Wiederherstellen – und die Wiederherstellung testen

Die Wiederherstellung ist der einzige Teil eines Backups, auf den es wirklich ankommt, und es ist der Schritt, den fast jeder auslässt. Um ein tar-Backup wiederherzustellen, stoppen Sie den Container und extrahieren dann das Archiv zurück in das (leere) Volume:

docker run --rm \
  -v mydata:/target \
  -v $(pwd)/backups:/backup:ro \
  alpine tar xzf /backup/mydata-20260717-120000.tar.gz -C /target

Bei einem Datenbank-Dump laden Sie ihn in einen frischen Container und prüfen Schema und Zeilenanzahl, bevor Sie ihm vertrauen. Planen Sie eine echte Wiederherstellungsübung – monatlich ist sinnvoll – in einen Wegwerf-Container, fahren Sie die App gegen die wiederhergestellten Daten hoch und bestätigen Sie, dass sie funktioniert. Ein Backup, das Sie noch nie wiederhergestellt haben, ist eine Hoffnung, kein Wiederherstellungsplan. Verankern Sie das in Ihrem Arbeitsablauf – so, wie Sie auch einen neuen Server in der sicheren ersten Stunde eines VPS-Setups härten würden.

Häufig gestellte Fragen

Kann ich ein Docker-Volume sichern, ohne den Container zu stoppen?

Ja, mit einer Einschränkung. Für Dateispeicher und Caches ist es in Ordnung, das Volume schreibgeschützt einzuhängen und es zu tarren, während der Container läuft. Bei Datenbanken sollten Sie das laufende Volume nicht tarren – verwenden Sie stattdessen das Dump-Werkzeug der Engine (pg_dump, mysqldump, mongodump), das einen konsistenten Export ohne Stoppen des Dienstes erzeugt.

Wo werden Docker-Volumes tatsächlich gespeichert?

Unter Linux liegen benannte Volumes unter /var/lib/docker/volumes/<name>/_data. Sie können dieses Verzeichnis technisch gesehen kopieren, aber die Sicherung über einen Container (oder ein Dump bei Datenbanken) ist sicherer und über Hosts hinweg portabel – deshalb empfiehlt Dockers Dokumentation den Ansatz per Volume-Mount.

Was ist das beste Tool zur Automatisierung von Docker-Volume-Backups?

Für unkomplizierte Volume-Backups mit integrierter Planung, Rotation und Cloud-Upload ist offen/docker-volume-backup die beliebteste Ein-Container-Option. Für deduplizierte, verschlüsselte, versionierte Historie über viele Backends hinweg ist restic die stärkere Wahl. Viele Setups kombinieren einen nächtlichen Datenbank-Dump mit einem restic-Push nach außer Haus.

Wie oft sollte ich sichern?

Richten Sie die Häufigkeit danach aus, wie viele Daten Sie sich zu verlieren leisten können. Nächtlich ist der übliche Standard für selbst gehostete Apps; eine stark ausgelastete Datenbank kann stündliche Dumps rechtfertigen. Wie auch immer die Taktung ist – bewahren Sie mehrere Generationen auf (zum Beispiel 7 tägliche, 4 wöchentliche, 6 monatliche), damit eine spät bemerkte Beschädigung noch wiederherstellbar ist.

Sources

• OneUptime – Docker-Volumes sichern und wiederherstellen: die schreibgeschützten tar-Befehle zum Sichern und Wiederherstellen sowie der Hinweis, dass Datenbank-Dumps transaktional konsistent sind, wo Dateisystem-Backups es nicht sind.
• Docker Docs – Volumes: offizielle Empfehlung, dass Volumes leichter zu sichern und zu migrieren sind als Bind-Mounts, und wo Volume-Daten gespeichert werden.
• PostgreSQL-Dokumentation – pg_dump: das konsistente Dump-Verhalten von --single-transaction für laufende Datenbanken.
• offen/docker-volume-backup (GitHub): unterstützte Speicher-Backends, GPG-Verschlüsselung, Planung, Container-Stopp während des Backups und Rotation.
• restic: verschlüsselte, deduplizierte, inkrementelle Backups über mehrere Speicher-Backends hinweg.
• Hetzner Storage Box und Backblaze B2 – Preise: zitierte Kosten für Off-Site-Speicher (Juli 2026).