Docker Container Updates: Sicher & ohne Datenverlust

docker restart wechselt das Image nicht. docker rm ohne Volume-Prüfung löscht Daten unwiederbringlich. Der einzig zuverlässige Update-Weg: Volume-Backup → docker pull → Container stoppen und entfernen → neu deployen mit identischen Mounts und Umgebungsvariablen.

Watchtower auf datenkritische Container wie Nextcloud, Vaultwarden oder Immich anzuwenden ist keine Option — dort sind manuelle Updates mit Changelog-Prüfung Pflicht.

Kurzantwort: Volume-Backup anlegen → docker pull <image> → alten Container stoppen und entfernen → neuen Container mit identischem Volume-Mount und identischen Umgebungsvariablen neu erstellen. docker restart reicht nicht, docker pull allein reicht nicht — erst das Neuerstellen des Containers aktiviert das neue Image.

Docker Container Updates sicher durchführen — der richtige Workflow verhindert Datenverlust.

---

Das Problem: Warum Docker Updates so oft schiefgehen

Der häufigste Fehler: docker restart ausführen und davon ausgehen, dass jetzt die neue Version läuft. Tut sie nicht. Der Container läuft nach einem Restart auf exakt demselben Image-Layer wie vorher — das neue Image, das du gerade gepullt hast, bleibt ungenutzt.

Der zweithäufigste Fehler: docker rm ausführen, ohne vorher zu prüfen, ob Daten im Container-Dateisystem statt in einem Volume liegen. Dann sind Konfigurationen, Datenbanken oder Upload-Ordner weg — unwiederbringlich.

Drei Begriffe, die du kennen musst:

• Image: Die unveränderliche Vorlage, aus der ein Container erstellt wird — vergleichbar mit einer ISO-Datei.
• Container: Die laufende Instanz dieses Images. Flüchtig — gehört nicht zur Datenhaltung. Wer Daten im Container-Dateisystem ablegt, verliert sie beim nächsten docker rm. Das ist kein Bug, das ist Design.
• Volume: Ein Datenspeicher außerhalb des Containers, der docker rm überlebt. Deine Daten gehören immer dort hin.

---

Entscheidung: Welche Update-Methode für welchen Fall?

Entscheidungsbaum: Die richtige Update-Methode hängt von Container-Typ, Datenkritikalität und Orchestrierungswerkzeug ab.

---

Schritt für Schritt: Docker Container sicher auf neue Version aktualisieren

Voraussetzung: Du weißt, wie dein Container gestartet wurde — per docker run oder per docker-compose.yml. Falls nicht: docker inspect <containername> zeigt dir alles.

---

Schritt 1: Überblick verschaffen — was läuft gerade?

docker ps listet jeden laufenden Container mit Name, Image und Uptime. Merk dir den Namen deines Containers (Spalte NAMES) — den brauchst du in jedem folgenden Schritt. docker images zeigt, welche Image-Versionen lokal gecacht sind, inklusive dem Datum des letzten pull.

Prüfen: Dein Container taucht in der Liste auf, z. B. nextcloud oder vaultwarden.

---

Schritt 2: Backup der Volumes anlegen — bevor du irgendetwas anfasst

Die Ausgabe zeigt dir unter Source den Pfad auf deinem Host, z. B. /opt/nextcloud/data.

$(date +%Y%m%d) hängt automatisch das heutige Datum ans Backup, z. B. data_backup_20250115.

Stolperfalle: Named Volumes (z. B. nextcloud_data) liegen unter /var/lib/docker/volumes/nextcloud_data/_data. Anonyme Volumes, die manche Images beim ersten Start automatisch erstellen, werden mit docker rm -v still mitgelöscht — prüfe deshalb immer die Mounts-Ausgabe, bevor du docker rm ausführst.

---

Schritt 3: Neues Image herunterladen

docker pull lädt das aktuelle Image vom Docker Hub herunter. Das allein startet noch nichts neu — dein laufender Container bleibt unberührt.

Prüfen: Die Ausgabe endet mit Status: Downloaded newer image for nextcloud:latest. Steht dort Status: Image is up to date, ist bereits die aktuelle Version lokal vorhanden.

Irrglaube: latest bedeutet automatisch aktuell.
latest ist nur ein gewöhnliches, statisches Label — nicht anders als 1.0 oder stable. Es bedeutet lediglich: „Das war die neueste Version, als der Entwickler dieses Tag gesetzt hat.“ Docker prüft nicht selbstständig, ob auf Docker Hub kaufen eine neuere Version unter diesem Tag liegt. Ein explizites docker pull imagename:latest ist nötig — und selbst dann kann sich hinter latest plötzlich eine komplett andere Hauptversion verbergen. Für produktive Setups: Immer einen konkreten Versions-Tag pinnen, z. B. nextcloud:28.0.3.

Um den genauen Image-Digest vor und nach dem Pull zu vergleichen:

Der vollständige Docker Update-Ablauf als Flussdiagramm: Von Volume-Backup über Image Pull bis zum Neustart des Containers.

---

Schritt 4: Alten Container stoppen und entfernen

docker stop sendet ein sauberes Shutdown-Signal. docker rm löscht den Container-Layer, aber nicht deine Volumes — solange du nicht docker volume rm oder das --volumes-Flag verwendest.

Stolperfalle: docker rm -f nextcloud erzwingt das Entfernen ohne vorheriges Stoppen. Für Datenbank-Container wie MariaDB oder PostgreSQL immer docker stop zuerst — sonst riskierst du korrupte Tabellen.

---

Schritt 5: Neuen Container mit gleichem Volume-Mount starten

Variante A — docker run (Einzelcontainer):

Variante B — docker-compose (empfohlen, weil reproduzierbar):

Irrglaube: docker-compose up -d nach docker-compose pull aktualisiert zuverlässig.
Docker Compose prüft beim up -d standardmäßig nur, ob ein Container mit dem gewünschten Namen bereits läuft — nicht ob das zugrundeliegende Image neuer ist. Ohne --force-recreate bleiben laufende Container oft unverändert, selbst wenn das neue Image längst lokal vorliegt. Das Ergebnis: Du glaubst, aktualisiert zu haben — der Container läuft aber noch auf dem alten Stand.

Prüfen:

docker ps zeigt den Container als Up X seconds. docker logs gibt die letzten 50 Zeilen aus — hier siehst du sofort, ob Fehler wie fehlende Umgebungsvariablen oder fehlgeschlagene Datenbankmigrationen aufgetreten sind.

Stolperfalle nach Datenbank-Updates: Neue Major-Versionen (z. B. MariaDB 10.x → 11.x) erfordern oft eine explizite Migration. In diesem Fall: altes Image-Tag pinnen (mariadb:10.11) und erst nach einem Datenbank-Dump updaten.

Terminal-Ausgabe des vollständigen Docker Update-Workflows: pull, stop, rm und run in der richtigen Reihenfolge.

---

Weiterführende Grundlagen-Artikel

• Docker Volumes erstellen und verwalten
• Docker Compose Container updaten
• Watchtower Docker automatisch updaten
• Docker Container Backup erstellen
• Portainer Container updaten
• Docker Container Rollback nach fehlgeschlagenem Update

Häufig gestellte Fragen

Fazit

Ein Docker Container Update ist kein docker restart — es ist ein kontrolliertes Stoppen, Neuerstellen und Remounten. Volume-Mounts vor jedem docker rm prüfen, Backup anlegen, dann deployen. Wer das einmal verinnerlicht hat, verliert keine Daten mehr.

Das könnte dich auch interessieren

• Portainer Backup und Updates: Container sicher verwalten
• Docker Compose mit Portainer: Container-Stacks verwalten
• Plex Docker Container einrichten: Docker Compose Guide