Speicherfresser finden: effizient analysieren mit du

Gerade auf Linux-Servern wachsen Logdateien oft unbemerkt – bis plötzlich die Platte voll ist. Besonders das Verzeichnis /var/log ist dafür ein klassischer Kandidat. Mit einem einzigen, gut gewählten Kommando lässt sich schnell herausfinden, welche Unterverzeichnisse dort am meisten Speicher verbrauchen.

Das klappt natürlich auch für alle anderen Pfade.. wenn man einfach auf dem root / sucht findet man die Pfade wo der meiste Verbrauch liegt. Dann -x im Hinterkopf behalten 🙂

du -x -m --max-depth=1 /var/log/ | sort -rn | head

Was passiert hier genau?

du (disk usage)
Ermittelt den tatsächlich belegten Speicherplatz auf Dateisystemebene.

• -x
  Bleibt auf dem aktuellen Dateisystem (wichtig bei separaten Mounts).
• -m
  Ausgabe fest in Megabyte – ideal für Vergleiche und Sortierung.
• --max-depth=1
  Zeigt nur die direkte Verzeichnisebene, keine tiefen Rekursionen.
• /var/log/
  Zielverzeichnis der Analyse.

sort -rn
Sortiert numerisch und absteigend – größte Speicherverbraucher zuerst.

head
Begrenzt die Ausgabe auf die Top 10.

Typische Ausgabe

1240    /var/log/journal
380     /var/log/apache2
210     /var/log/mysql
48      /var/log/apt

➡️ Auf einen Blick ist klar, wo der Platz bleibt.

Warum diese Methode praxisnah ist

• Schnell: Keine langlaufenden Vollscans
• Übersichtlich: Eine Ebene, klare Zahlen
• Skriptfähig: Feste Einheit (MB), numerisch sortierbar
• Produktionstauglich: Keine Tools von Drittanbietern nötig

Gerade bei vollgelaufenen Root-Partitionen ist dieser Ansatz oft der erste sinnvolle Diagnose-Schritt.

Best Practice: Iterativ vorgehen

1. Grobanalyse:

du -x -m --max-depth=1 /var/log | sort -rn

2. Verdächtiges Verzeichnis vertiefen:

du -x -m --max-depth=1 /var/log/journal | sort -rn

3. Danach gezielt:

Logging-Level hinterfragen
Logrotate prüfen
alte Logs löschen oder komprimieren

Mit einem einfachen du-Pipeline-Befehl lässt sich Log-Wildwuchs schnell sichtbar machen.
Gerade für Administratoren, DevOps-Teams und Linux-Power-User ist das ein zuverlässiges Werkzeug, um Speicherprobleme proaktiv zu erkennen – bevor sie zum Incident werden.

Wer seine Systeme kennt, lässt sie nicht stillschweigend volllaufen.