Docker Update schlägt fehl: Rollback ohne Datenverlust – SHA256, Volumes & Compose
Docker Rollback: Fehlerhafte neue Version zurückrollen auf die letzte funktionierende Version per SHA256-Digest
Container nach Update im Status Restarting (1), Service nicht erreichbar — das alte Image scheinbar weg. Der SHA256-Digest ist in diesem Moment dein einziger zuverlässiger Anker, weil Tags wie latest nur bewegliche Zeiger sind und das alte Image in den meisten Fällen noch lokal im Cache liegt.
Nicht geeignet wenn das alte Image bereits durch docker image prune entfernt wurde oder das Volume durch eine automatische Datenbank-Migration in ein inkompatibles Schema überführt wurde — dann ist ein Backup-Restore der einzige sichere Weg.
Der klassische Fehler: docker-compose down && docker-compose up -d ausführen, ohne vorher zu wissen, wie der Weg zurück aussieht. Hier geht es ausschließlich um den Moment, in dem das Update bereits schiefgelaufen ist. Ein SHA256-Digest ist die unveränderliche Seriennummer einer bestimmten Image-Version — solange das Image noch lokal vorhanden ist, kommst du damit exakt auf den alten Stand zurück.
Der latest-Tag zeigt nach einem docker pull auf das neue Image – das alte Image bleibt als dangling Layer ohne Tag im Cache, erreichbar nur noch über seinen SHA256-Digest.
Dieser Artikel ist Teil einer Grundlagen-Serie. Weitere Artikel:
- 📖 Docker Container updaten ohne Datenverlust (Übersicht)
- ➔ 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
Das Problem verstehen: Warum Docker-Rollbacks scheitern
Irrglaube 1: docker pull lässt sich einfach rückgängig machen
Sobald du ein neues Image mit dem Tag latest pullst, zeigt dieser Tag auf das neue Image. Das alte Image existiert zwar noch lokal, aber nur noch als namenloser dangling Layer — erreichbar ausschließlich über seinen SHA256-Fingerabdruck. Wer den vorher nicht notiert hat, sucht die Nadel im Heuhaufen.
Auf Systemen wie Synology DSM oder Unraid Angebot gibt es keine einfache Oberfläche, um diesen Fingerabdruck nachträglich herauszufinden. pull klingt nach einem simplen Download — man denkt, man kann es wie eine Datei wieder löschen oder überschreiben. Dass Tags wie latest nur bewegliche Zeiger sind und keine festen Versionen, ist nicht intuitiv.
Irrglaube 2: docker-compose down && up stellt den alten Zustand wieder her
docker-compose down stoppt und entfernt die Container — das Image auf der Festplatte bleibt das zuletzt gepullte, also das neue, fehlerhafte. Beim nächsten up startet docker-compose genau dieses neue Image wieder. Du drehst dich im Kreis.
Für ein echtes Rollback muss in der Compose-Datei explizit eine konkrete Image-Version eingetragen sein — z. B. nginx:1.24.0 statt nginx:latest. Besonders relevant für Portainer-Nutzer, die auf den Recreate-Button klicken und sich wundern, warum nichts besser wird.
Irrglaube 3: Volumes werden beim Rollback automatisch zurückgesetzt
Docker-Volumes sind vom Image vollständig getrennt — sie führen ihr eigenes Leben. Wenn das neue Image beim Start eine Datenbank-Migration durchgeführt hat (neue Tabellen angelegt, Spalten umbenannt), ist dieser Zustand dauerhaft in den Volume-Daten gespeichert. Das alte Image kann mit diesen veränderten Daten oft nicht mehr umgehen und startet mit Fehlern oder schweigendem Datenverlust.
Ein Image-Rollback ohne vorheriges Daten-Backup ist auf einem Homeserver mit Nextcloud, Vaultwarden oder Gitea ein ernstes Risiko. Das Konzept „Container = alles drin“ verleitet dazu, Image und Daten als eine Einheit zu denken — dabei ist die Entkopplung von Volumes eigentlich ein großer Vorteil, der im Fehlerfall zur unsichtbaren Falle wird.
Irrglaube 4: Altes Image lokal = sicheres Rollback jederzeit möglich
Das alte Image lokal zu haben ist eine notwendige, aber keine hinreichende Bedingung. Entscheidend ist, ob die Daten im Volume noch kompatibel mit dem alten Image sind. Apps wie Paperless-ngx, Immich oder Home Assistant führen beim ersten Start stillschweigend automatische Datenbank-Migrationen durch — das alte Image versteht das neue Format nicht mehr. Der Container startet nicht, zeigt kryptische Fehler, oder er startet und arbeitet mit korrupten Daten.
Irrglaube 5: docker tag reicht für ein vollständiges Rollback
Das Umbenennen eines Images ist nur ein winziger Teil eines echten Rollbacks. Was dabei komplett fehlt: alle Umgebungsvariablen (Passwörter, API-Keys, Pfade), Netzwerk-Zuordnungen, Port-Mappings, Volume-Mounts und Restart-Policies — also alles, was in der docker-compose.yml oder in Portainer als Stack-Konfiguration definiert ist.
Wer nur das Image zurücktaggt und den Container neu startet, bekommt im besten Fall einen Container ohne Konfiguration, im schlechtesten Fall einen Container, der mit falschen Einstellungen läuft und Daten beschädigt. Auf Unraid Angebot oder Synology, wo viele Nutzer keine Compose-Datei pflegen, ist dieses Wissen besonders kritisch.
Irrglaube 6: Docker Swarm schützt automatisch vor fehlerhaften Updates
Docker Swarm verteilt Container auf mehrere Nodes und kann Rolling Updates durchführen — aber ein fehlerhaftes Image wird trotzdem auf alle Nodes ausgerollt, wenn kein Health-Check definiert ist. Ohne einen funktionierenden Health-Check weiß Swarm nicht, ob der neue Container wirklich arbeitet oder nur „läuft“. Im 3-Node-Homelab bedeutet das: Alle drei Nodes laufen das kaputte Image. Ein Rollback in Swarm erfordert dann einen expliziten Update-Befehl auf die vorherige Image-Version — und auch hier gilt: Die Volume-Daten auf den Nodes sind bereits verändert.
Entscheidung: Welcher Rollback-Weg ist der richtige?
| Situation | Bedingung | Rollback-Weg |
|---|---|---|
| Altes Image noch im Cache, keine DB-Migration gelaufen | docker images -a zeigt <none>-Eintrag |
SHA256-Digest pinnen → Compose anpassen → up |
| Altes Image noch im Cache, DB-Migration bereits gelaufen | Logs zeigen migration oder Schema-Fehler |
Backup einspielen, dann Image-Rollback |
| Altes Image nicht mehr im Cache | docker images -a zeigt keinen alten Eintrag |
Image von Registry mit explizitem Tag pullen |
| Portainer / Synology / Unraid ohne Compose-Datei | Kein docker-compose.yml vorhanden |
Digest notieren, Image manuell taggen, Container neu erstellen |
| Docker Swarm, fehlerhaftes Rolling Update | docker service ls zeigt fehlerhafte Replicas |
docker service update --rollback <service> |
| Raspberry Pi Angebot / ARM64, Image startet nicht | Exited (1) direkt nach Start |
Image-Architektur prüfen, ARM64-spezifisches Tag pullen |
Entscheidungsbaum: Vom Symptom „Container startet nicht nach Update“ zu den drei Rollback-Pfaden – je nachdem ob das alte Image noch im Cache liegt, bereits bereinigt wurde oder Docker Swarm im Einsatz ist.
Setup: Docker Rollback Schritt für Schritt
Schritt 1: Zustand analysieren
docker images -a zeigt dir sowohl getaggte als auch namenlose (<none>) Images. Ein Image ohne Tag ist kein Fehler — das ist in den meisten Fällen das alte Image, das nach einem docker pull latest seinen Tag verloren hat.
Schritt 2: Altes Image identifizieren
Der zweite Eintrag mit <none> ist das alte Image. Über sha256:9b2c... kannst du es wieder mit einem Tag versehen. Wenn du den Digest vor dem Update nicht notiert hast, hilft docker history <image-id> — die Layer-IDs bleiben erhalten.
Schritt 3: docker-compose.yml anpassen und Image pinnen
Warum Image-Versionen pinnen? Solange latest in der Compose-Datei steht, zieht jedes docker-compose up das neueste Image — unabhängig davon, was lokal im Cache liegt. Gepinnte Tags sind die einzige zuverlässige Methode, um docker-compose down && up als echten Rollback-Mechanismus zu nutzen.
Schritt 4: Volume-Zustand prüfen, bevor du den Container startest
Wenn die Logs eine abgeschlossene Migration zeigen, ist das Volume bereits im neuen Format. Das alte Image kann damit inkompatibel sein. In diesem Fall: Backup einspielen oder Migrations-Downgrade prüfen — Nextcloud und Gitea bieten explizite Downgrade-Skripte.
Schritt 5: Rollback ausführen
docker-compose stop <service> statt docker-compose down — letzteres stoppt alle Services gleichzeitig. Mit docker-compose up -d <service> startest du isoliert nur den einen Service neu, ohne den Rest zu berühren.
Schritt 6: Docker Swarm Rollback
Ohne definierten Health-Check rollt Swarm ein fehlerhaftes Image auf alle Nodes aus, solange der Container technisch startet. Der Health-Check ist die einzige Möglichkeit, Swarm beizubringen, ob ein Update wirklich erfolgreich war.
Terminal-Sequenz: docker images --digests zeigt das dangling Image mit SHA256-Digest, docker tag macht es wieder erreichbar, und docker-compose up -d startet den Service mit der gepinnten alten Version.
Häufig gestellte Fragen
Kann ich docker pull rückgängig machen?
docker pull selbst lässt sich nicht rückgängig machen — der Befehl lädt ein neues Image herunter und überschreibt dabei den latest-Tag lokal. Das alte Image ist aber in den meisten Fällen noch vorhanden, solange du kein docker image prune ausgeführt hast.
Solange der SHA256-Digest des alten Images noch in der Ausgabe auftaucht, liegt es noch im lokalen Cache. Mit docker tag <digest> meinapp:rollback machst du es wieder erreichbar und pinnst es in der docker-compose.yml auf diesen Tag.
Wie finde ich den SHA256-Digest eines alten Docker-Images?
Wenn du den Digest vor dem Update nicht gesichert hast, hilft docker history <image-id> — die Layer-IDs bleiben erhalten. Auf Docker Hub findest du unter Tags → Digest die exakten Hashes aller veröffentlichten Versionen, falls du das Image von dort gezogen hast.
Werden Volumes beim Rollback automatisch zurückgesetzt?
Nein — niemals. Volumes sind bewusst vom Image-Lebenszyklus entkoppelt. Ein Rollback auf ein altes Image lässt den Volume-Inhalt vollständig unberührt. Unproblematisch, wenn die Migration noch nicht gelaufen ist. Kritisch, wenn die neue Version bereits Datenbankschemas geändert hat — das alte Image kann dann mit dem veränderten Volume inkompatibel sein.
Deshalb gilt: Vor jedem Update ein Volume-Backup anlegen.
Was tun, wenn die Datenbank-Migration das Volume bereits verändert hat?
Der kritischste Fall. Das alte Image startet zwar, aber der Datenbankserver verweigert den Dienst, weil das Schema neuer ist als das Image erwartet. Optionen in dieser Reihenfolge:
- Backup einspielen — das sauberste Vorgehen, setzt ein Backup vor dem Update voraus
- Migrations-Downgrade ausführen — manche Apps (z. B. Nextcloud, Gitea) bieten explizite Downgrade-Skripte
- Neue Version debuggen — manchmal ist es einfacher, das Update-Problem zu fixen als das Volume zurückzusetzen
Die Logs zeigen dir, welcher Migrations-Schritt fehlgeschlagen ist — das ist der Ausgangspunkt für Option 2 oder 3.
Wie rolle ich nur einen einzelnen Service in docker-compose zurück?
Der Schlüssel ist docker-compose stop <service> statt docker-compose down — letzteres stoppt alle Services gleichzeitig. Auf Synology (Container Manager) und Unraid gibt es dafür eine GUI, aber die CLI-Variante funktioniert auf jedem System identisch.
Ist ein Rollback sicher, wenn das alte Image noch im Cache ist?
Ja — mit einer Einschränkung. Das Image selbst ist stabil, solange es nicht durch docker image prune oder docker rmi entfernt wurde. Die eigentliche Gefahr liegt im Volume, nicht im Image. Prüfe vor dem Neustart:
Auf Raspberry Pi Angebot (ARM64) kann es passieren, dass ein älteres Image für amd64 gebaut wurde und auf ARM64 nicht startet — Exited (1) direkt nach dem Start ist ein typisches Symptom. In diesem Fall hilft nur ein Image, das explizit für linux/arm64 gebaut wurde.
Wie führe ich einen Rollback in Docker Swarm durch?
Swarm speichert die vorherige Service-Konfiguration und kann damit einen Rollback ohne manuelles Image-Tagging durchführen — aber nur auf die unmittelbar vorherige Version. Für ältere Versionen muss das Image explizit angegeben werden. Ohne Health-Check erkennt Swarm einen fehlerhaften Container nicht automatisch und rollt das fehlerhafte Image auf alle Nodes aus.
Wie halte ich eine Docker-Image-Version fest, damit kein automatisches Update passiert?
Gepinnte Tags verhindern, dass docker-compose pull oder ein Watchtower-Update das Image ohne dein Zutun ersetzt. Der SHA256-Digest ist die sicherste Methode — ein Tag kann theoretisch neu beschrieben werden, ein Digest nie.
Wie mache ich einen Docker-Rollback auf Synology oder Unraid ohne Compose-Datei?
Auf Synology Container Manager und Unraid ohne gepflegte Compose-Datei:
- Altes Image über
docker images --digestsim Terminal identifizieren docker tag <sha256:digest> <appname>:rollbackausführen- Container stoppen und löschen — Volume dabei behalten
- Neuen Container mit dem
rollback-Tag und identischer Konfiguration deployen
Das Risiko: Ohne Compose-Datei müssen alle Parameter (Ports, Volumes, Umgebungsvariablen) manuell rekonstruiert werden. docker inspect <alter-container-name> zeigt die ursprüngliche Konfiguration, falls der Container noch nicht gelöscht wurde.
Was bedeutet „docker image dangling“ und wie finde ich das alte Image?
Ein dangling Image ist ein Image ohne Tag — entstanden, wenn ein neues Image denselben Tag übernimmt. Das alte Image verliert seinen Namen, bleibt aber im Cache.
docker image prune erst ausführen, wenn der Rollback erfolgreich abgeschlossen und der Service stabil läuft. Vorher: Finger weg.
Wie schütze ich Volumes beim Docker-Rollback vor Überschreiben?
Volumes werden beim Rollback nicht automatisch überschrieben — das ist das Standardverhalten. Die Gefahr ist die umgekehrte: Das alte Image ist inkompatibel mit dem bereits veränderten Volume-Inhalt.
Benenne Backups mit Zeitstempel — bei mehreren Update-Versuchen verlierst du sonst den Überblick, welches Backup dem Zustand vor dem fehlerhaften Update entspricht.
Proxmox LXC: Docker-Container-Update schlägt fehl – was tun?
In einem Proxmox LXC-Container gelten dieselben Docker-Rollback-Schritte wie auf jedem anderen Linux-System. Zusätzliche Überlegungen:
- LXC-Snapshots vor dem Update anlegen:
pct snapshot <vmid> pre-update— damit hast du einen vollständigen System-Snapshot inklusive Docker-Daten - Wenn der LXC-Container selbst nach dem Docker-Update nicht mehr startet: Snapshot zurückspielen mit
pct rollback <vmid> pre-update - Volumes, die außerhalb des LXC-Containers auf dem Proxmox-Host gemountet sind (Bind-Mounts), werden vom LXC-Snapshot nicht erfasst — diese separat sichern
Fazit
Ein Docker-Rollback scheitert fast nie am fehlenden Image — er scheitert daran, dass latest-Tags keine Versionen sind, Volumes ein eigenes Leben führen und docker-compose down && up keine Rollback-Funktion ist. Wer Images pinnt und vor jedem Update ein Volume-Backup anlegt, hat im Fehlerfall einen klaren Weg zurück.
Unsere Empfehlungen
* Affiliate-Links – beim Kauf erhalten wir ggf. eine Provision.
Preisvergleich
| Produkt | smartkram | Fachhandel | Amazon | eBay |
|---|---|---|---|---|
| Raspberry Pi | smartkram ↗ | reichelt elektronik DE ↗ | Amazon ↗ | eBay ↗ |
| Unraid | — | — | Amazon ↗ | eBay ↗ |
* Affiliate-Links – beim Kauf erhalten wir ggf. eine Provision.
✍️ Autor: homeserverlab-Redaktion
🔄 Zuletzt aktualisiert: 10. Juni 2026
Das könnte dich auch interessieren
- Docker Container Updates durchführen ohne Datenverlust
- Docker Compose Update: Container sicher aktualisieren
- Docker Compose mit Portainer: Container-Stacks verwalten
