1br.de

Category: Linux

  • Festplatte voll? So findest du die Ursache – und löst das Problem dauerhaft

    Eine volle Festplatte ist kein Schönheitsfehler, sondern ein akutes Betriebsrisiko.
    Sobald / oder /var auf 100 % laufen, beginnen Dienste zu spinnen, Logs reißen ab, Datenbanken stoppen, SSH-Logins schlagen fehl. Die gute Nachricht: Linux lügt nicht – man muss nur wissen, wo man hinschaut. Dieser Artikel zeigt ein bewährtes Vorgehen, mit dem du in wenigen Minuten:

    • den Platzfresser findest
    • die Ursache verstehst
    • und verhinderst, dass es wieder passiert

    1. Erste Bestandsaufnahme: Welche Partition ist voll?

    df -h

    Wichtig ist nicht die Gesamtkapazität, sondern:

    • Welche Partition
    • Welcher Mountpoint
    • Wie viel „Avail“ wirklich noch da ist

    Typischer Notfall:

    /dev/nvme0n1p3  1,7T  1,6T  0 100% /

    Ab hier gilt: Nicht raten – messen.

    2. Wo liegt der Platz? Grober Überblick auf Root-Ebene

    sudo du -xh --max-depth=1 / | sort -h

    Das zeigt dir sofort, welche Verzeichnisse relevant sind.

    Unkritisch:

    • /bin, /sbin, /lib, /etc

    Verdächtig:

    • /var
    • /home
    • /root
    • /mnt
    • /opt
    • /usr (nur bei ungewöhnlich großen Werten)

    👉 Alles, was zweistellig in GB oder gar TB geht, ist ein Kandidat.

    3. Der Klassiker: /mnt ist kein Mountpoint (mehr)

    Wenn du so etwas siehst:

    1,2T /mnt

    … dann ist fast sicher Folgendes passiert:

    Ein Ziel-Laufwerk war nicht gemountet, aber Prozesse haben fröhlich weitergeschrieben.

    Linux schreibt stumpf ins Verzeichnis, egal ob dort eigentlich ein Mount geplant war.

    Prüfen:

    mount | grep mnt
lsblk -f

    Wenn dort kein Device auftaucht → Ursache gefunden.

    Lehre:

    • /mnt ohne aktiven Mount ist gefährlich
    • Skripte müssen Mounts prüfen, bevor sie schreiben
    • systemd-Mounts oder nofail + Checks verwenden

    4. Tiefenanalyse: Der Übeltäter im Detail

    Beispiel /mnt:

    sudo du -xh --max-depth=1 /mnt | sort -h

    Oder gezielt große Dateien:

    sudo find /mnt -type f -size +10G -exec ls -lh {} \;

    Typische Inhalte:

    • Backups
    • Datenbank-Dumps
    • VM-Images
    • Docker-Volumes
    • Log-Exporte
    • KI-Datasets (ja, die fressen brutal)

    5. /root größer als ein paar GB? Alarmstufe Gelb

    sudo du -xh --max-depth=1 /root | sort -h

    Root wird oft versehentlich als Ablage missbraucht durch:

    • scp als root
    • rsync mit falschem Ziel
    • Cronjobs
    • Testdaten
    • Docker Builds

    /root > 10 GB ist fast nie normal.

    6. Logs: Wenn Fehler sich selbst vervielfältigen

    sudo du -xh /var/log | sort -h

    Journal prüfen:

    journalctl --disk-usage

    Aufräumen:

    sudo journalctl --vacuum-size=1G

    Oder zeitlich:

    sudo journalctl --vacuum-time=7d

    Dauerhafte Lösung:

    /etc/systemd/journald.conf

    SystemMaxUse=1G

    7. Docker – der leise Killer

    Docker belegt Platz, auch wenn keine Container laufen.

    docker system df

    Aufräumen:

    docker system prune -a
docker volume prune

    Pfad:

    /var/lib/docker

    Wenn das zweistellig GB hat → völlig normal, aber muss gemanagt werden.

    8. Der fieseste Fall: Gelöschte Dateien, die noch offen sind

    du zeigt sie nicht. df schon.

    sudo lsof | grep deleted

    Wenn dort große Dateien stehen:

    • Prozess hält File-Handle offen
    • Platz wird erst nach Prozessende freigegeben

    Lösung: Dienst neu starten oder Prozess beenden.

    9. Komfortabler Überblick mit ncdu (empfohlen)

    sudo apt install ncdu
sudo ncdu /

    ncdu ist:

    • schnell
    • ehrlich
    • gnadenlos klar

    Ideal für Post-Mortem-Analysen.

    10. Erst löschen, wenn die Ursache klar ist

    Regel Nr. 1:

    Lösche nichts, solange du nicht weißt, warum es da ist.

    Fragen vor dem Löschen:

    • Sollte das auf ein anderes Laufwerk?
    • Gehört das zu einem Service?
    • Ist das ein Backup?
    • Läuft ein Cronjob dahinter?

    11. Dauerhafte Prävention (der wichtigste Teil)

    ✔ Mounts absichern

    • systemd .mount Units
    • Skripte mit mountpoint -q /mnt || exit 1

    ✔ Logging begrenzen

    • journald Limits
    • logrotate prüfen

    ✔ Monitoring

    • df -h via Cron
    • Alert bei >80 %

    ✔ Root disziplinieren

    • Keine Datenablage
    • Kein „mal eben scp nach /root“

    Fazit

    Eine volle Festplatte ist kein Zufall.
    Sie ist immer das Ergebnis von:

    • fehlenden Checks
    • stillen Annahmen
    • oder vergessenen Mounts

    Linux gibt dir alle Werkzeuge an die Hand –
    du musst sie nur konsequent nutzen.

    Wenn du systematisch vorgehst, ist das Problem:

    • schnell gefunden
    • sauber gelöst
    • dauerhaft verhindert