Das letzte Update war vor 9. November 2026 von Benedikt Schächner
Wenn dein Docker-Host plötzlich keinen freien Speicherplatz mehr hat, denkst du vermutlich zuerst an große Images, Datenbanken oder Volumes. Tatsächlich können auch Container-Protokolle innerhalb kurzer Zeit viele Gigabyte belegen – beispielsweise wenn eine Anwendung denselben Fehler immer wieder meldet. Besonders tückisch: Die übliche Docker-Speicherübersicht zeigt diese Logdateien nicht immer vollständig an. In dieser Anleitung findest du zuerst den Verursacher, begrenzt das weitere Wachstum und kontrollierst anschließend, ob die Ursache der Meldungsflut behoben ist.
Für wen? Die Schritte gelten für Docker Engine auf Linux (beispielsweise Ubuntu oder Debian) und Docker Compose. Du benötigst Zugriff auf den Host und die Berechtigung, Docker-Befehle auszuführen. Bei Rootless Docker, Docker Desktop oder einem externen Logging-Treiber unterscheiden sich Speicherpfade und Verwaltung. Docker-Befehle sind nicht automatisch harmlos: Die Berechtigung auf den Docker-Socket gewährt weitreichenden Host-Zugriff.
1. Speicherverbrauch eingrenzen
Prüfe zuerst, ob tatsächlich das Dateisystem voll ist, auf dem Docker seine Daten speichert. Starte mit diesen lesenden Befehlen:
df -h
docker system df
docker info --format '{{.DockerRootDir}}'
docker info --format '{{.LoggingDriver}}'
Beispielausgabe (gekürzt; Werte und Namen auf deinem Server können abweichen):
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 100G 94G 6.0G 94% /
TYPE TOTAL ACTIVE SIZE
Images 12 7 8.2GB
Containers 9 8 1.1GB
Local Volumes 6 5 21GB
Build Cache 2 0 120MB
/var/lib/docker
json-file
Die Beispielwerte sind keine Messung an deinem Server. df -h zeigt die Belegung der Dateisysteme, docker system df unter anderem Images, Container, Volumes und Build-Cache. Der zuletzt ausgegebene Logging-Treiber ist zunächst nur der Standard für neue Container. Einzelne Container können abweichend konfiguriert sein.
2. Verursachenden Container finden
Lass dir zuerst die laufenden Container anzeigen. Danach prüfst du den Logging-Treiber und den Logpfad eines konkreten Containers. Ersetze mein-container durch den tatsächlichen Namen aus der ersten Ausgabe:
docker ps --format 'table {{.Names}}\t{{.Status}}'
docker inspect --format '{{.HostConfig.LogConfig.Type}}' mein-container
docker inspect --format '{{.LogPath}}' mein-container
Beispielausgabe (gekürzt; Werte und Namen auf deinem Server können abweichen):
NAMES STATUS
mein-container Up 3 hours
andere-app Up 2 days
json-file
/var/lib/docker/containers/abc123.../abc123...-json.log
Der Logpfad kann bei anderen Treibern fehlen oder anders aussehen. Bei json-file kannst du die Größe des von Docker gemeldeten Pfads lesend ermitteln. Verwende den tatsächlich ausgegebenen absoluten Pfad, nicht den verkürzten Platzhalter aus diesem Beispiel:
sudo du -h '/vollstaendiger/pfad/zur/container-json.log'
Beispielausgabe (gekürzt; Werte und Namen auf deinem Server können abweichen):
12G /vollstaendiger/pfad/zur/container-json.log
Wenn du mehrere Container prüfst, wiederhole diese Schritte gezielt bei den verdächtigen Diensten. Für eine erste Übersicht über besonders große Dateien kannst du auf einem klassischen Docker-Engine-Host außerdem sudo du -h /var/lib/docker/containers verwenden – aber nur, wenn docker info dieses Datenverzeichnis bestätigt. Auf anderen Installationen ist dieser Pfad möglicherweise falsch.
Wichtig: Docker verwaltet diese Dateien selbst. Lösche, rotiere oder bearbeite sie nicht direkt mit Shell-Befehlen, solange Docker sie benutzt. Das kann die Protokollierung beschädigen. Auch docker system prune --volumes ist keine sichere pauschale Sofortmaßnahme: Nicht verwendete Volumes können wichtige Daten enthalten.
3. Die Logflut verstehen
Bevor du die Aufbewahrung begrenzt, schaue dir die letzten Logzeilen an. Denn Rotation verhindert zwar unbegrenztes Wachstum, repariert aber keine Datenbankverbindung, keine Anmeldeschleife und keinen ständig abstürzenden Dienst:
docker logs --tail 50 --timestamps mein-container
Beispielausgabe (gekürzt; Werte und Namen auf deinem Server können abweichen):
2026-11-09T14:01:02.000000000Z [ERROR] Beispiel: Verbindung zur Datenbank fehlgeschlagen
2026-11-09T14:01:07.000000000Z [ERROR] Beispiel: erneuter Verbindungsversuch
2026-11-09T14:01:12.000000000Z [INFO] Beispiel: Wiederholung in 5 Sekunden
Die Meldungen oben sind bewusst erfunden und ausschließlich als Beispielausgabe gekennzeichnet. In echten Logs können Zugangstokens, IP-Adressen, Nutzernamen oder andere sensible Informationen stehen. Teile sie deshalb nicht ungeprüft öffentlich. Notiere dir die konkrete Fehlermeldung und suche ihre Ursache in der Dokumentation des betroffenen Dienstes.
4. Log-Rotation mit Compose
Wenn dein Container den Treiber json-file verwendet, kannst du in der vorhandenen compose.yaml unter dem jeweiligen Dienst eine maximale Dateigröße und Anzahl der Dateien festlegen. Das folgende vollständige Minimalbeispiel zeigt die Einrückung; übertrage nur den Abschnitt logging in deine vorhandene Dienstdefinition, statt die Anwendung oder ihre Volumes zu ersetzen:
services:
app:
image: nginx:stable
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
max-size: "10m" bewirkt eine Rotation, sobald eine Protokolldatei etwa 10 MB erreicht. max-file: "3" begrenzt die Anzahl der vorgehaltenen Dateien pro Container auf drei. Beide Optionswerte stehen in Anführungszeichen. Die Größenangaben beziehen sich auf die Logdateien dieses Containers, nicht auf Datenbanken oder andere gespeicherte Anwendungsdaten.
5. Änderung sicher übernehmen
Sichere vor Änderungen die bestehende Compose-Datei und gegebenenfalls die persistenten Daten des Dienstes. Wechsle in das Verzeichnis deiner tatsächlichen Compose-Datei. Mit diesen Befehlen kannst du die Konfiguration prüfen und die benötigte Neuerstellung erst danach bewusst ausführen:
docker compose config --quiet
docker compose config --services
docker compose up -d --force-recreate app
Beispielausgabe (gekürzt; Werte und Namen auf deinem Server können abweichen):
app
[+] Running 1/1
✔ Container projekt-app-1 Started
Die erste Zeile docker compose config --quiet liefert bei Erfolg normalerweise keine Ausgabe und den Exitcode 0. Der zweite Befehl zeigt die vorhandenen Dienstnamen. app ist im dritten Befehl nur der Name aus dem obigen Beispiel und muss bei dir durch den echten Dienstnamen ersetzt werden. --force-recreate erstellt diesen Container neu; das kann eine Unterbrechung verursachen. Führe dies nur aus, wenn die Compose-Datei tatsächlich korrekt ist und persistente Daten abgesichert sind.
Kontrolliere anschließend die aktive Konfiguration am neu erzeugten Container:
docker compose ps
docker inspect --format '{{json .HostConfig.LogConfig}}' projekt-app-1
Beispielausgabe (gekürzt; Werte und Namen auf deinem Server können abweichen):
NAME IMAGE SERVICE STATUS
projekt-app-1 nginx:stable app Up
{"Type":"json-file","Config":{"max-file":"3","max-size":"10m"}}
Ersetze projekt-app-1 durch den Containernamen, den docker compose ps auf deinem System tatsächlich meldet. Wenn der Container noch die alten Werte anzeigt, prüfe, ob die Compose-Datei am richtigen Ort liegt, der richtige Dienst geändert wurde und der Container wirklich neu erstellt wurde.
6. Alternative für neue Container
Docker empfiehlt für viele eigenständig betriebene Hosts den Treiber local, weil er platzsparend arbeitet und bereits standardmäßig rotierende Protokolle verwendet. Wenn du ihn als neuen Standard einsetzen möchtest, kannst du /etc/docker/daemon.json auf einem klassischen Linux-Host entsprechend konfigurieren. Überschreibe eine bereits vorhandene Datei nicht blind: Andere Einstellungen wie Registry-Mirrors oder Datenpfade müssen erhalten bleiben.
{
"log-driver": "local"
}
Vor einem Neustart muss die gesamte JSON-Konfiguration syntaktisch gültig sein. Ein Neustart des Docker-Dienstes kann laufende Anwendungen beeinträchtigen; plane ihn deshalb in ein Wartungsfenster. Änderungen der Daemon-Standards gelten außerdem nur für anschließend neu erstellte Container. Bereits vorhandene Container behalten ihre Logging-Konfiguration.
Auch mit dem local-Treiber kannst du die letzten Meldungen regulär über docker logs lesen. Unterschiede gibt es bei der internen Speicherstruktur; greife daher nicht direkt auf die gespeicherten Dateien zu.
7. Erfolg dauerhaft kontrollieren
Prüfe nach der Umstellung, ob das Dateisystem wieder ausreichend freien Platz hat und die Anwendung nicht länger massenhaft Fehler meldet. Log-Rotation begrenzt zunächst das künftige Wachstum. Bereits bestehende Dateien verschwinden nicht allein dadurch, dass du die Einstellung in einer Datei ergänzt. Wenn sehr viel Speicher bereits belegt ist, plane die sichere Bereinigung zusammen mit der dokumentierten Neuerstellung des betroffenen Containers und einem funktionierenden Backup.
df -h
docker logs --tail 30 mein-container
docker inspect --format '{{json .HostConfig.LogConfig}}' mein-container
Beispielausgabe (gekürzt; Werte und Namen auf deinem Server können abweichen):
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 100G 83G 17G 83% /
[INFO] Beispiel: Anwendung bereit
{"Type":"json-file","Config":{"max-file":"3","max-size":"10m"}}
Die Ausgabe zeigt nur, wie ein erfolgreicher Zustand aussehen könnte. Ob Speicher wirklich frei geworden ist und die Anwendung korrekt funktioniert, musst du auf deinem Host selbst kontrollieren. Bleiben die Logs sehr groß, kontrolliere den tatsächlich aktiven Treiber, die Anwendungsausgaben und gegebenenfalls, ob ein anderer Container betroffen ist.
Häufige Fragen
Warum hilft docker system df nicht? Diese Übersicht ist keine vollständige Dateisystemanalyse und muss den Platzbedarf deiner Logdateien nicht im erwarteten Umfang zeigen. Nutze zusätzlich df, den Docker-Datenpfad und die Container-Inspektion.
Reicht ein Neustart des Containers? Nein. Neue Standardwerte aus daemon.json greifen erst bei neu erstellten Containern. Eine Änderung in Compose benötigt ebenfalls das Übernehmen der geänderten Containerkonfiguration.
Soll ich alle Docker-Logs deaktivieren? In der Regel nicht. Die Protokolle helfen bei Sicherheitsproblemen und Fehlerdiagnosen. Begrenze ihren Speicherbedarf und behebe die wiederholten Fehler, statt pauschal jede Diagnosemöglichkeit abzuschalten.
Fazit
Wenn Docker-Logs deine Festplatte füllen, sind zwei Schritte entscheidend: Identifiziere zuerst den betroffenen Container und die eigentliche Fehlermeldung. Richte anschließend eine passende Rotation ein und kontrolliere, ob der Container die Konfiguration wirklich übernommen hat. So verhinderst du, dass derselbe Fehler in wenigen Tagen erneut das ganze Dateisystem belegt.
Offizielle Quellen: Docker: Logging-Treiber konfigurieren, Docker: JSON-File-Treiber, Docker: Local-Logging-Treiber. Weiterlesen: Dockge installieren.

Schreiben Sie einen Kommentar