Docker Backup vor dem Update: So geht’s richtig

Docker Backup vor dem Update – Datenverlust vermeiden mit der richtigen Sicherungsstrategie

Ein vollständiges Volume-Backup vor dem Update ist die einzige Absicherung gegen Datenverlust — docker compose up -d schreibt sofort in dein Volume, noch bevor du weißt, ob das neue Image überhaupt funktioniert. Wer ausschließlich zustandslose Container ohne persistente Volumes betreibt, braucht das nicht — dort reicht ein Image-Tag-Wechsel.

---

Das Problem: Was beim Docker-Update wirklich passiert

docker compose pull gefolgt von docker compose up -d klingt harmlos. Der neue Container startet, bindet das bestehende Volume ein und beginnt sofort zu schreiben — Datenbankmigrationen, Schema-Änderungen, neue Konfigurationsformate. Läuft das Update schief, sind deine Daten im Volume bereits verändert. Ohne vorheriges Backup gibt es keinen Weg zurück.

Drei Dinge können dabei verloren gehen:
– Volumes — persistente Daten (Datenbanken, Uploads, Konfigurationen)
– docker-compose.yml und .env — Ports, Passwörter, Pfade. Klingt banal, ist aber der häufigste Grund warum ein Rollback scheitert.
– Das alte Image — ohne es kannst du den Container nicht auf den Vorstand zurücksetzen

Docker-Container-Anatomie: Image, Volume und Compose-Datei als drei getrennte Blöcke — was beim Update ersetzt wird und was erhalten bleibt

---

Entscheidung: Welche Backup-Methode für welches Setup

Kurzfassung für die häufigsten Fälle:

• Named Volumes → tar via Alpine-Container (siehe Schritt 2)
• Bind Mounts → direktes cp -r auf dem Host reicht
• Datenbank läuft → Dump-Befehl im laufenden Container, kein Stopp nötig
• Proxmox oder Unraid → kein VM-Snapshot als Ersatz für Volume-Backup (dazu gleich mehr)
• Portainer → erstellt keine Backups. Du musst manuell ran.

Backup-Entscheidungsbaum: Die richtige Methode für Named Volumes, Bind Mounts, Datenbanken und plattformspezifische Setups auf einen Blick

---

Setup: Vollständiges Backup vor dem Update — Schritt für Schritt

Schritt 1: Herausfinden, was gesichert werden muss

Zeigt dir exakt, was du sichern musst — Typ (Volume oder Bind Mount), Quellpfad auf dem Host, Zielpfad im Container. Vor jedem Update ausführen, nicht aus dem Gedächtnis arbeiten.

docker inspect im Terminal: Volumes und Bind Mounts eines Containers im JSON-Format — so erkennst du, was vor dem Update gesichert werden muss

Schritt 2: Container stoppen

Kurze Downtime ist besser als ein inkonsistentes Backup. Ausnahme: Datenbanken mit eigenem Dump-Befehl (siehe Schritt 3b).

Schritt 3a: Named Volume sichern

Das Alpine-Image startet kurz, bindet das Volume ein, packt alles in ein Archiv und verschwindet wieder. Das Ergebnis liegt im aktuellen Verzeichnis auf dem Host.

Schritt 3b: Datenbank-Dump im laufenden Betrieb (ohne Stopp)

Schritt 4: Compose-Datei und Umgebungsvariablen sichern

Schritt 5: Altes Image-Tag sichern (optional, aber empfohlen)

Schritt 6: Update durchführen

Vollständiger Update-Ablauf im Terminal: docker compose stop → tar-Backup → docker compose pull → docker compose up -d mit erfolgreicher Volume-Sicherung

Schritt 7: Rollback, wenn das Update fehlschlägt

---

Plattform-spezifische Hinweise

Unraid: AppData-Backup vor dem Update

Auf Unraid liegen Bind Mounts standardmäßig unter /mnt/user/appdata/containername/. Das ist dein primärer Sicherungspfad:

Das CA Backup/Restore Plugin automatisiert diesen Schritt für alle Container gleichzeitig. Wichtig: Named Volumes liegen separat unter /var/lib/docker/volumes/ und müssen zusätzlich gesichert werden — das Plugin erfasst sie nicht automatisch.

Synology Container Manager: Backup vor dem Update

Projektdaten liegen unter /volume1/docker/projektname/. Hyper Backup kann diesen Ordner einschließen:

Named Volumes auf Synology: /var/lib/docker/volumes/ — erfordert Root-Zugriff via SSH. Hyper Backup erfasst diesen Pfad nicht automatisch.

Proxmox LXC mit Docker: Volumes korrekt sichern

Ein Proxmox-Snapshot bei laufenden Docker-Containern ist kein vollwertiges Backup für Datenbankdaten — dazu gleich mehr unter den Irrtümern.

Raspberry Pi: SD-Karte und Docker-Volumes

SD-Karten unter Last produzieren häufiger Fehler als SSDs. Ein vollständiges Image als Fallback ist auf dem Raspberry Pi sinnvoller als auf anderen Plattformen — in meinem Test mit einem Pi 4 und einer günstigen Class-10-Karte hatte ich nach 8 Monaten Dauerbetrieb den ersten Dateisystemfehler. Seitdem läuft der Pi auf einer SSD via USB.

Docker Desktop / WSL2 auf Windows 11: Volumes sichern

Volumes liegen im WSL2-Dateisystem, nicht direkt unter Windows zugänglich:

---

Die 6 gefährlichsten Irrtümer beim Docker-Backup

Irrtum 1: docker commit sichert alles — auch die Volumes

docker commit fotografiert nur das Dateisystem innerhalb des Containers — Betriebssystem und installierte Programme. Alles in einem Volume (Datenbanken, Uploads, Konfigurationsdateien) bleibt dabei komplett außen vor.

Der Begriff klingt nach „alles festschreiben“ wie in Git. Docker zeigt nach dem Befehl eine Erfolgs-ID an — das erzeugt ein falsches Gefühl von Sicherheit.

Konkretes Beispiel: Nextcloud läuft, du machst vor dem Update docker commit, rollst danach zurück — die App startet wieder, aber alle Nutzerdaten sind weg. Die lagen im Volume, nicht im Container.

Irrtum 2: docker save sichert auch die Container-Daten

docker save exportiert nur das Image — die Vorlage, aus der Container gebaut werden. Die eigentlichen Laufzeitdaten (PostgreSQL-Datenbank deiner Gitea-Instanz, Konfiguration deines Home Assistant) liegen in Volumes und werden von docker save schlicht ignoriert.

Irrtum 3: docker compose down + docker compose up ist ein Backup-Prozess

docker compose down stoppt und entfernt Container — ohne jede Sicherung. Volumes bleiben standardmäßig erhalten, aber wenn beim anschließenden Update etwas schiefläuft (Datenbankschema wird automatisch migriert und ist danach inkompatibel mit der alten Version), gibt es keinen Weg zurück.

Das Backup muss immer VOR dem down-Befehl und manuell erstellt werden.

Viele Anleitungen zeigen genau diese Abfolge als „Update-Prozess“, ohne den fehlenden Backup-Schritt zu erwähnen. Der Ablauf fühlt sich strukturiert an — ist aber kein Backup.

Irrtum 4: Portainer sichert Container-Daten automatisch

Portainer ist eine grafische Oberfläche zur Verwaltung von Docker — kein Backup-Tool. Es zeigt Container, Volumes und Logs übersichtlich an, erstellt aber zu keinem Zeitpunkt automatisch Sicherungen.

Wer sich auf Portainer als Sicherheitsnetz verlässt und dann ein Update einspielt, das die Datenbank zerschießt, schaut in Portainer auf eine leere oder fehlerhafte Instanz — ohne Rückfahrkarte. Besonders auf Synology DSM und Unraid, wo Portainer als zentrale Schaltzentrale beworben wird, entsteht dieser Irrglaube.

Irrtum 5: Ein Proxmox-VM-Snapshot reicht als Docker-Backup

Ein Snapshot des Hosts oder der VM kann inkonsistente Daten enthalten, wenn Docker-Container zum Zeitpunkt des Snapshots noch laufen. Datenbanken wie MySQL, PostgreSQL oder MariaDB schreiben Daten nicht sofort vollständig auf die Festplatte — ein Teil steckt noch im Arbeitsspeicher oder in offenen Transaktionen.

Ein Snapshot in diesem Moment ist wie ein Foto eines fahrenden Autos: Es sieht aus wie das Auto, aber die Räder sind unscharf. Nach der Wiederherstellung kann die Datenbank korrupt sein und sich weigern zu starten.

Lösung: Container stoppen, dann Snapshot — oder Datenbank-Dump im laufenden Betrieb via pg_dump / mysqldump.

Irrtum 6: Volumes werden beim Container-Löschen mitgelöscht — also muss ich sie nicht extra sichern

Docker trennt Volumes bewusst vom Container-Lebenszyklus. Beim Update-Prozess kann es passieren, dass ein Volume explizit mit dem Flag --volumes entfernt wird, oder dass ein neues Image ein anderes Volume-Schema erwartet und das alte Volume ignoriert. Die Daten sind dann zwar noch vorhanden, werden aber nicht mehr genutzt — und irgendwann doch gelöscht.

„Noch vorhanden“ ist nicht dasselbe wie „gesichert“.

---

Fehler-Matrix: Symptome, Ursachen, Fixes

---

FAQ: Häufige Fragen zum Docker-Backup vor dem Update

Fazit

Ein Docker-Backup vor dem Update besteht aus drei Teilen: Volume-tar, docker-compose.yml + .env kopieren, altes Image-Tag notieren. Wer das überspringt und auf docker commit, docker save, Portainer oder VM-Snapshots vertraut, hat beim nächsten fehlgeschlagenen Update keine Rückfahrkarte.

Das könnte dich auch interessieren

• Nextcloud Backup automatisieren – Docker Volumes sichern
• Home Server Backup Strategie: 3-2-1 Regel richtig umsetzen
• Home Server Sicherheit: VPN, Firewall und Backup richtig