# Docker auf dem Mac aufräumen, ohne Daten zu verlieren > Images, Container, Build-Cache und zustandsbehaftete Volumes vor dem Pruning prüfen und Sparse-Disk-Belegung separat messen. Published: 2026-06-26 | Updated: 2026-08-08 Docker Desktop kann Dutzende Gigabyte belegen, weil Images, beschreibbare Container-Schichten, Build-Cache und Volumes in einer Linux-Virtualdisk liegen. Diese Kategorien sind nicht gleichermaßen verzichtbar. Build-Cache ist meist reproduzierbar; ein Datenbank-Volume kann die einzige Kopie wichtiger Daten sein. Sicheres Aufräumen beginnt mit dem Docker-Inventar, nicht mit dem breitesten Prune-Befehl. ## Warum Docker-Speicherplatz nicht zurückkommt Docker Desktop unter macOS betreibt eine Linux-VM und speichert seine Daten in der Regel in einer Sparse-Virtualdisk namens `Docker.raw`. Der [Mac-Speicherleitfaden](https://docs.docker.com/desktop/troubleshoot-and-support/faqs/macfaqs/#where-does-docker-desktop-store-linux-containers-and-images) von Docker verweist auf **Docker Desktop > Settings > Resources > Advanced** für Speicherort, Disk-Limit und den tatsächlich belegten Platz. Verschieben Sie die Datei mit dieser Einstellung, nicht mit dem Finder. Eine Sparse-Datei hat eine maximale logische Größe und eine kleinere physische Belegung; `ls -lh` allein kann sie daher deutlich größer erscheinen lassen, als sie aktuell belegt. Sehen Sie nach, was Docker selbst als belegt meldet: ``` docker system df -v ``` Die Detailansicht gliedert Images, Container, lokale Volumes und Build-Cache. „Reclaimable“ bedeutet, dass Docker keinen aktuellen Verweis kennt, der das Objekt braucht; es beweist nicht, dass Sie einen gestoppten Container, ein altes Image oder ein Volume morgen nicht brauchen. Prüfen Sie vor dem Prunen auch `docker ps -a` und `docker volume ls`. ## Mit gezieltem Aufräumen beginnen Geben Sie Speicher immer von innen in Docker frei, nicht indem Sie die Virtualdisk-Datei löschen. Beginnen Sie mit der Kategorie, die Sie verstehen: ``` docker builder prune --filter until=168h docker image prune docker container prune ``` Der erste Befehl entfernt Build-Cache älter als sieben Tage; passen Sie das Alter an Ihre Arbeit an. Die beiden nächsten fragen nach, bevor hängende (dangling) Images und gestoppte Container entfernt werden. Führen Sie nach jedem Schritt erneut `docker system df -v` aus, damit Sie sehen, welche Aktion etwas gebracht hat. Der [Pruning-Leitfaden](https://docs.docker.com/engine/manage-resources/pruning/) von Docker beschreibt `docker system prune` als breiteren Komfortbefehl. Mit `-a` werden alle ungenutzten Images entfernt, nicht nur hängende Schichten. Mit `--volumes` erweitert sich der Vorgang auf ungenutzte anonyme Volumes, die Datenbankdateien oder anderen Zustand enthalten können. Machen Sie aus `docker system prune -a --volumes` keinen Standard-Aufräumbefehl. Prüfen Sie vor jedem Volume-Prune Namen und Zugehörigkeit: ``` docker volume ls docker volume inspect ``` Von Compose erzeugte Volumes tragen in der Regel Projekt- und Service-Labels. Identifizieren Sie das zugehörige Projekt und exportieren oder sichern Sie Daten, die sich nicht neu erzeugen lassen, bevor Sie das Volume entfernen. ## Die Disk-Image selbst freigeben Nach einem Prune existieren freie Blöcke im Linux-Dateisystem, bevor macOS sie unbedingt von der Sparse-Disk zurückerhält. Die aktuelle Docker-Dokumentation sagt, dass ein `Docker.raw`-Image freigabefähigen Host-Speicher normalerweise innerhalb von Sekunden zurückgibt; ältere `Docker.qcow2`-Images nutzen einen Hintergrundprozess, der Minuten dauern kann. Messen Sie den tatsächlichen Festplattenverbrauch erneut, statt die logische Maximalgröße der Datei zu beurteilen. Ein Factory Reset ist keine Verdichtung: er zerstört lokale Container, Images, Volumes und Einstellungen. Nutzen Sie ihn nur, wenn dieser vollständige Verlust beabsichtigt ist und wichtige Volume-Daten exportiert wurden. ## Unter der Haube: warum die Datei wächst und nicht schrumpft Docker Desktop betreibt eine Linux-VM, und `Docker.raw` ist die Virtualdisk dieser VM: eine Sparse-Datei, die wächst, wenn der Gast schreibt, aber Speicher nicht automatisch an macOS zurückgibt, wenn der Gast löscht. Das Entfernen eines Images markiert Blöcke im Dateisystem der VM als frei, aber die Host-Datei schrumpft nur, wenn der Gast TRIM/discard ausgibt und Docker Desktop discard und Verdichtung nutzen kann, um freigabefähige Blöcke zurückzugeben. Der Zeitpunkt hängt von Version und Disk-Image-Implementierung ab. Deshalb müssen logisches Aufräumen und die Änderung der Host-Kapazität getrennt gemessen werden – und warum das Löschen der Host-Datei dem Zerstören der gesamten Docker-Umgebung entspricht.
Eine sparse Docker.raw-Datei wächst, wenn die Guest-VM schreibt, und kann freigabefähige Blöcke über discard und Verdichtung an macOS zurückgeben
Das Löschen eines Docker-Objekts gibt zuerst Speicher in der VM frei. Physische Belegung an macOS zurückzugeben ist ein eigener Sparse-Disk-Schritt.
## Wo eine Festplattenkarte hilft Eine Festplattenkarte wie die Analyze-Ansicht von [Mole](https://mole.fit/) kann die Virtualdisk und ihren physischen Fußabdruck zeigen. Welches interne Objekt referenziert ist, muss Dockers eigene CLI entscheiden. Die beiden Sichten beantworten verschiedene Fragen: macOS zeigt, wo Kapazität belegt ist; Docker erklärt, was diese Belegung enthält. ## Eine sichere Reihenfolge Führen Sie `docker system df -v` aus, identifizieren Sie alte Projekte und zustandsbehaftete Volumes, exportieren Sie einzigartige Daten und prunen Sie eine Kategorie nach der anderen. Prüfen Sie erneut sowohl Dockers interne Summen als auch die physische Kapazität unter macOS. Nutzen Sie breite Prune-Flags erst, nachdem Sie ihren erweiterten Umfang geprüft haben, und verwenden Sie einen Factory Reset nie als routinemäßigen Shortcut zur Speicherfreigabe. Der schnellste sichere Gewinn ist meist alter Build-Cache, nicht unbekannte Volumes. --- Canonical HTML page: https://mole.fit/de/blog/how-to-clean-up-docker-mac Blog index for agents: https://mole.fit/de/blog/llms.txt Site index for agents: https://mole.fit/llms.txt