Auf einem NAS liegt die Ursache meist in der Docker-Ebene oder im Speicherpfad des Containers: Der Dienst schreibt fortlaufend Logdaten, ohne alte Einträge zu begrenzen. Akute Datengefahr besteht zunächst nicht, solange noch ausreichend freier Speicher vorhanden ist und keine System-, Container- oder Datenbankdateien betroffen sind. Prüfe deshalb zuerst die Speicherbelegung und die Größe einzelner Logdateien, bevor du Container neu startest, löschst oder deren Verzeichnisse bearbeitest.
Eine saubere Lösung besteht aus drei Teilen: Du begrenzt die Größe eines einzelnen Logs, legst eine Anzahl aufzubewahrender Dateien fest und prüfst danach, ob die verwendete Container-Laufzeit diese Einstellungen tatsächlich übernommen hat. Eine Rotation verhindert, dass ein dauerhaft laufender Dienst den Speicher unbemerkt aufbraucht. Sie ersetzt jedoch kein Backup und schützt nicht vor fehlerhaften Anwendungen, die zusätzlich eigene Protokolle in gemountete Ordner schreiben.
Welche Logdateien wachsen auf dem NAS?
Docker unterscheidet zwischen den Protokollen, die der Container an die Standardausgabe und den Standardfehler schreibt, und Dateien, die eine Anwendung selbst anlegt. Die erste Gruppe wird vom Docker-Logging-Treiber verarbeitet. Sie lässt sich bei passenden Einstellungen über Größen- und Aufbewahrungslimits begrenzen.
Die zweite Gruppe liegt häufig in einem Bind-Mount oder Volume. Webserver, Datenbanken, Medienserver und Automatisierungssoftware schreiben dort eigene Dateien wie Zugriffs-, Fehler- oder Debug-Protokolle. Eine Docker-Logrotation erfasst diese Dateien nicht automatisch. Für solche Logs brauchst du die Rotation der jeweiligen Anwendung oder eine separate Verwaltung auf dem NAS.
Bei der Suche solltest du außerdem zwischen drei Speicherorten unterscheiden:
- Container-Logs der Docker-Laufzeit, die meist im internen Docker-Datenverzeichnis liegen.
- Anwendungslogs in einem gemounteten Ordner oder Docker-Volume.
- System- und Dienstprotokolle des NAS, die von DSM, QTS, QuTS hero, UGOS Pro oder TerraMaster OS verwaltet werden.
Diese Bereiche haben unterschiedliche Zuständigkeiten. Eine Änderung am Container-Logging löst daher nicht automatisch ein Problem mit einem überfüllten Anwendungsordner oder einem NAS-Systemprotokoll.
Vor der Änderung: Speicher und Verursacher ermitteln
Bevor du Limits setzt, halte fest, welcher Speicherpool oder welches Volume betroffen ist. Ein voller Speicher kann nicht nur Docker stoppen, sondern auch Snapshots, Datenbanken, Aktualisierungen oder Systemdienste beeinträchtigen. Bei einem kritischen Füllstand solltest du zuerst unnötige temporäre Dateien und eindeutig identifizierte alte Logs sichern oder nach den Regeln deiner Anwendung entfernen. Lösche keine unbekannten Dateien aus dem Docker-Datenverzeichnis.
Öffne in der Verwaltungsoberfläche deines NAS die Speicheranalyse oder die Speicherübersicht. Suche anschließend nach dem Docker-Datenpfad und nach den Verzeichnissen, die du als Bind-Mounts eingebunden hast. Die genaue Bezeichnung hängt vom NAS-System, vom Installationsweg und von der Docker-Variante ab.
Bei einem Container mit stark wachsendem Standardlog sind oft wiederholte Fehlermeldungen der Auslöser. Ein Dienst kann wegen eines falschen Mounts, eines nicht erreichbaren Hosts, fehlender Berechtigungen oder eines fehlerhaften Plugins in kurzer Zeit sehr viele identische Zeilen erzeugen. Ein Limit verhindert zwar die Speicherknappheit, beseitigt aber nicht die eigentliche Fehlfunktion.
Die passenden Limits für Docker-Logs
Für den klassischen JSON-Logging-Treiber sind vor allem zwei Einstellungen wichtig. max-size begrenzt die Größe einer einzelnen Logdatei. max-file legt fest, wie viele rotierte Dateien neben der aktuellen Datei erhalten bleiben. Wird ein Limit erreicht, benennt Docker die alte Datei um und beginnt eine neue.
Ein Beispiel für eine zurückhaltende Konfiguration ist eine maximale Größe von 10 Megabyte und eine Aufbewahrung von drei Dateien. Zusammen können dadurch ungefähr 40 Megabyte pro Container entstehen, wobei Verwaltungsinformationen und Abweichungen durch die Implementierung möglich sind. Die tatsächliche Gesamtmenge hängt außerdem davon ab, ob mehrere Container dieselbe Anwendung betreiben und ob zusätzliche Anwendungslogs geschrieben werden.
Die Werte sollten zum Dienst passen. Bei einem kleinen privaten Dienst reichen niedrigere Grenzen häufig aus. Bei einem wichtigen Webdienst können größere Dateien sinnvoll sein, wenn du Fehler über einen längeren Zeitraum untersuchen musst. Sehr hohe Limits verschieben das Risiko nur nach hinten. Entscheidend ist, dass die Summe aller Containerlogs zum freien Speicher und zur geplanten Aufbewahrung passt.
Die Einstellungen greifen nur, wenn der Container mit ihnen erstellt oder neu erstellt wurde. Das bloße Ändern einer Konfigurationsdatei oder ein gewöhnlicher Neustart übernimmt neue Logging-Optionen nicht immer. Ob die Änderung aktiv ist, musst du nach der Bereitstellung anhand der Containerkonfiguration prüfen.
Rotation in einer Compose-Konfiguration
Wird der Dienst über eine Compose-Datei verwaltet, werden die Logging-Optionen normalerweise am jeweiligen Service definiert. Ein allgemeines Muster sieht so aus:
- logging legt die Logging-Konfiguration des Dienstes fest.
- driver bestimmt den verwendeten Treiber.
- options enthält beispielsweise max-size und max-file.
Die genaue Schreibweise muss zu deiner Compose-Version und zum eingesetzten Verwaltungswerkzeug passen. Ändere nur den betroffenen Service und bewahre vorher eine Kopie der bisherigen Datei auf. Danach wird der Dienst in der Regel neu erstellt. Dabei können kurze Unterbrechungen auftreten; laufende Schreibvorgänge, Datenbanken und abhängige Dienste solltest du vorher berücksichtigen.
Wenn die Compose-Datei bereits einen anderen Logging-Treiber verwendet, gelten dessen eigene Regeln. Eine Einstellung für den JSON-Treiber wirkt dann nicht automatisch. Prüfe deshalb zuerst den tatsächlich verwendeten Treiber und vermische keine Konfigurationen aus unterschiedlichen Docker-Umgebungen.
Globale Vorgaben und ihre Grenzen
Eine globale Docker-Konfiguration kann Standardwerte für neu erstellte Container vorgeben. Das ist nützlich, wenn viele Dienste nach demselben Prinzip bereitgestellt werden. Bereits vorhandene Container übernehmen solche Vorgaben jedoch häufig erst nach einer Neuerstellung. Außerdem können einzelne Services eigene Werte definieren und damit globale Standardeinstellungen überschreiben.
Auf NAS-Systemen wird Docker nicht immer direkt über eine Shell verwaltet. Synology Container Manager, QNAP Container Station und vergleichbare Oberflächen können eigene Felder für Protokolltreiber oder Loglimits anbieten. Bei einer Aktualisierung der Anwendung oder beim Wechsel zwischen grafischer Oberfläche und Compose-Datei darfst du nicht voraussetzen, dass beide Stellen synchron bleiben.
Prüfe nach jeder Änderung, ob der Container weiterhin mit den erwarteten Mounts, Ports, Umgebungsvariablen und Berechtigungen läuft. Die Logrotation darf nicht als Anlass dienen, eine funktionierende Bereitstellung vollständig neu aufzubauen.
Wenn der Speicher bereits knapp ist
Bei einem fast vollen Volume steht die sichere Reihenfolge im Vordergrund. Stoppe zunächst den Verursacher, falls er weiterhin unkontrolliert schreibt und der Dienst nicht für den Betrieb benötigt wird. Sichere danach die relevanten Logs, wenn sie für die Fehlersuche oder einen Nachweis gebraucht werden. Erst anschließend solltest du alte oder eindeutig entbehrliche Dateien nach einer geprüften Vorgehensweise entfernen.
Containerlogs im Docker-internen Verzeichnis solltest du nicht mit einem beliebigen Dateimanager löschen. Die Laufzeit kann dadurch inkonsistente Zustände erhalten, und ein späterer Neustart kann unerwartete Fehler zeigen. Nutze bevorzugt die vorgesehene Verwaltungsoberfläche oder dokumentierte Docker-Funktionen. Wenn das System bereits Warnungen wegen eines vollen Volumes ausgibt, erstelle vor riskanten Eingriffen ein Backup der wichtigen Anwendungsdaten.
Bei Datenbanken gilt besondere Vorsicht. Ein Logfile ist nicht automatisch eine Datenbankdatei, aber beide können im selben Volume liegen. Eine pauschale Löschung nach Dateiendung oder Änderungsdatum kann daher zu Datenverlust führen. Prüfe Besitzer, Pfad, Anwendung und Zweck jeder Datei, bevor du sie entfernst.
Eigene Anwendungslogs separat begrenzen
Schreibt die Anwendung in einen gemounteten Ordner, musst du ihre eigene Logverwaltung aktivieren. Viele Dienste bieten Einstellungen für maximale Dateigröße, Anzahl der Archive, Kompression und Aufbewahrungsdauer. Diese Werte findest du in der jeweiligen Dienstkonfiguration; sie sind nicht durch die Docker-Limits vorgegeben.
Bei einem Webserver kann eine Rotation nach Dateigröße oder Tageswechsel sinnvoll sein. Bei einer Datenbank müssen Logarten unterschieden werden: Fehlerprotokolle, Transaktionslogs, Auditdaten und temporäre Diagnoseausgaben haben nicht dieselbe Aufbewahrungslogik. Entferne Dateien nur nach dem Verfahren der jeweiligen Anwendung, weil manche Dienste geöffnete Dateien anders behandeln als bereits geschlossene Archive.
Auch Debug-Modi verdienen Aufmerksamkeit. Eine Anwendung, die dauerhaft ausführliche Diagnosemeldungen schreibt, erzeugt selbst bei funktionierender Rotation unnötigen Speicherverbrauch und erschwert die Fehlersuche durch große Datenmengen. Aktiviere die ausführliche Protokollierung nur für die benötigte Untersuchungszeit und stelle danach den normalen Betriebsmodus wieder her.
Prüfliste nach der Einrichtung
- Ist der betroffene Speicherpool oder das Volume eindeutig bekannt?
- Wurde die größte Logquelle identifiziert und vom Anwendungspfad unterschieden?
- Sind maximale Dateigröße und Anzahl der Archive gesetzt?
- Wurde der Container nach der Änderung tatsächlich neu erstellt?
- Verwendet der Dienst den erwarteten Logging-Treiber?
- Bleiben wichtige Fehlermeldungen lange genug für die Diagnose erhalten?
- Wachsen zusätzlich eigene Logs in gemounteten Ordnern?
- Gibt es eine Warnung für den freien Speicher?
- Wird die Konfiguration nach Updates oder Bereitstellungen weiterhin verwendet?
- Existiert ein getestetes Backup der wichtigen Containerdaten?
Beobachte nach der Änderung mehrere Betriebszyklen. Ein neuer Logeintrag sollte weiterhin sichtbar sein, während alte Dateien die festgelegte Grenze nicht dauerhaft überschreiten. Wenn der Speicher trotzdem wächst, liegt die Ursache wahrscheinlich außerhalb des Docker-Standardlogs oder die Anwendung produziert ungewöhnlich viele Einträge.
Häufige Fragen zu begrenzten Containerprotokollen
Verhindert Logrotation jeden Speicherverbrauch durch Docker?
Nein. Sie begrenzt nur die Logdaten, die vom jeweiligen Treiber verwaltet werden. Container-Volumes, Bind-Mounts, Datenbanken, Caches und Anwendungslogs können weiterhin wachsen.
Werden alte Logs durch das Setzen eines Limits sofort gelöscht?
Das hängt von der Laufzeit und dem Bereitstellungsweg ab. Neue Limits gelten häufig erst nach einer Neuerstellung des Containers und begrenzen dann das weitere Wachstum. Bereits vorhandene übergroße Dateien musst du getrennt und vorsichtig behandeln.
Welche Aufbewahrung ist für Fehlersuchen sinnvoll?
Das hängt von der Häufigkeit des Fehlers und dem verfügbaren Speicher ab. Wähle die Aufbewahrung so, dass ein typischer Fehlerzeitraum abgedeckt wird, und archiviere wichtige Protokolle bei Bedarf außerhalb des Containers.
Warum wachsen die Logs trotz Docker-Limits weiter?
Oft schreibt nicht der Docker-Logging-Treiber, sondern die Anwendung selbst in einen gemounteten Ordner. Möglich sind auch ein anderer Logging-Treiber, eine nicht neu erstellte Bereitstellung oder weitere Container mit ähnlichem Verhalten.
Kann ich Containerlogs während des laufenden Betriebs löschen?
Eine manuelle Löschung im internen Docker-Verzeichnis ist riskant und nicht als Standardmaßnahme geeignet. Stoppe bei akuter Speicherknappheit den Verursacher und nutze die vorgesehene Verwaltung oder eine dokumentierte Vorgehensweise des eingesetzten Systems.
Sind rotierte Logs ein Ersatz für ein Backup?
Nein. Rotation dient der Speicherbegrenzung und hält meist nur einen begrenzten Zeitraum vor. Wichtige Konfigurationen, Datenbanken und Anwendungsdaten brauchen ein unabhängiges Backup mit regelmäßig geprüftem Wiederherstellungsweg.
Gilt dieselbe Einstellung für alle NAS-Systeme?
Die Docker-Grundidee ist ähnlich, die Oberflächen und Speicherpfade unterscheiden sich jedoch. DSM, QTS, QuTS hero, UGOS Pro und TerraMaster OS können unterschiedliche Verwaltungswege und Versionsabhängigkeiten haben.
Was sollte ich bei wiederholten Fehlermeldungen zuerst prüfen?
Suche nach dem gemeinsamen Auslöser, etwa einem falschen Pfad, fehlenden Rechten, einer nicht erreichbaren Adresse oder einem beschädigten Plugin. Ein kleineres Loglimit schützt den Speicher, ersetzt aber nicht die Behebung des Fehlers.
Der nächste sinnvolle Schritt
Beginne mit der Zuordnung des wachsenden Pfads und prüfe danach den Logging-Treiber des betroffenen Containers. Setze erst dann passende Größen- und Aufbewahrungswerte, erstelle den Dienst mit gesicherter Konfiguration neu und kontrolliere anschließend sowohl die Loggröße als auch die freien Speicherreserven. Bleibt das Wachstum bestehen, untersuche die Anwendungslogs und nicht nur die Docker-Ebene.