Wo die Gigabytes wirklich stecken
Docker Desktop lagert unter WSL2 alles — Images, Container, Volumes, Build-Cache — in spezielle WSL-Distributionen, die jeweils als eine einzige dynamische VHDX-Datei auf C: liegen. Jeder Pull bringt Schichten, jeder Build Cache, und Löschen gibt Speicher nur innerhalb des Linux-Dateisystems frei: Die Datei auf dem Host bleibt auf ihrem Höchststand. Ihre eigene Ubuntu- oder Debian-Distribution macht denselben Trick mit ihrem ext4.vhdx, und in der Jagd nach „dicken Ordnern“ taucht nichts davon auf, weil es für Windows nur ein paar opake Dateien sind.
- docker-desktop-data (ältere Versionen) bzw. docker_data.vhdx (neuere): der Hauptfresser mit 30–80 GB unter %LOCALAPPDATA%\Docker\wsl — Images, Container, Volumes, Build-Cache
- docker-desktop: die kleinere System-Distribution, in der die Docker-Engine selbst läuft
- Eigene WSL2-Distributionen: je eine ext4.vhdx unter %LOCALAPPDATA%\Packages\...\LocalState
- Build-Cache: docker builder behält Zwischenschichten, selbst wenn das fertige Image längst gelöscht ist
- Dangling Images und gestoppte Container: verwaiste Schichten abgebrochener Builds und Pulls
- Anonyme Volumes: werden bei jedem Compose-Build still angelegt und überleben sogar docker image prune
Erst innen aufräumen — eine schmutzige Disk zu verdichten ist verlorene Zeit
Eine VHDX voller toter Images zu verdichten bringt nur eine kleinere Datei hervor, die sofort wieder wächst — die Reihenfolge entscheidet. Starten Sie innen: docker system df zeigt, was Images, Container, Volumes und Cache wirklich belegen, und die Zahlen überraschen meist. docker system prune -a entfernt ungenutzte Images und gestoppte Container, --volumes inklusive verwaister Volumes — prüfen Sie vorher, ob Sie nicht gerade Datenbankdaten löschen, die Sie behalten wollten. Danach räumt docker builder prune den Build-Cache leer, den wiederholte Rebuilds aufblähen; erst wenn docker system df eine akzeptable Zahl meldet, lohnt sich der Griff zur Datei auf dem Host.
Dann die Disk verdichten: drei offizielle Wege
Zuerst wsl --shutdown, sonst ist die Datei von laufenden Containern und Distributionen gesperrt. Auf aktuellen WSL-Builds markiert wsl --manage <Distro> --set-sparse true die VHDX als sparse, sodass Windows freie Blöcke zurückholen kann; auf älteren Versionen ist Export und Import der zuverlässige Weg — wsl --export in ein .tar, wsl --unregister, wsl --import in einen frischen Ordner — und die Datei wird neu in echter Datengröße angelegt. Docker Desktop kann die komplette Disk auch auf ein anderes Laufwerk verschieben — Settings > Resources > Advanced — und migriert die Daten mit; das ist die ehrliche Lösung, wenn C: für Ihre Arbeit schlicht zu klein ist. Und drosseln Sie das Wachstum gleich mit: auf derselben Einstellungsseite gibt es ein Diskgrößen-Limit, und der monatliche Blick auf docker system df hält Sie darunter.
Fragen und Antworten
Warum belegt Docker Desktop so viel Speicherplatz?
Docker verwahrt jedes Image, jeden Layer, jedes Volume und jeden Build-Cache-Eintrag in einer dynamischen VHDX, die nach Bedarf wächst und nie von selbst schrumpft. docker system df zeigt die Aufteilung, danach ausmisten und die Disk verdichten.
Wie verkleinere ich die Docker-VHDX unter WSL2?
Zuerst wsl --shutdown, dann die Disk mit wsl --manage <Distro> --set-sparse true als sparse markieren. Oder die Distribution in ein .tar exportieren, unregistern und zurückimportieren — die frische VHDX entspricht dann der echten Datengröße.
Vor dem Kauf genau wissen, was enthalten ist.
Der einmalige 30-Minuten-Test umfasst Basisfunktionen. PRO-markierte Werkzeuge bleiben bis zur Aktivierung einer kostenpflichtigen Lizenz gesperrt.
Weiterlesen
Schreiben Sie uns: [email protected]