Linux monatlich aufräumen: Altlasten finden, beseitigen und automatisieren

Warum überhaupt aufräumen?

Alle Beispiele in diesem Artikel sind echte Kandidaten – in der Reihenfolge, in der sie üblicherweise Platz freigeben:

Erst messen, dann löschen

Wer blind löscht, löscht irgendwann das Falsche. Deshalb zuerst die Bestandsaufnahme:

Paket-Altlasten: Debian und Arch

Der größte Einzelposten ist fast immer der Paketcache. Beide Familien haben dafür ihre eigenen Werkzeuge – und bei beiden gibt es eine „sanfte“ und eine „radikale“ Stufe.

Alte Kernel und /boot

Auf UEFI-Systemen ist /boot oft nur 512 MB groß – und jeder Kernel plus Initramfs belegt dort 50 bis 150 MB. Läuft die Partition voll, schlägt das nächste Kernel-Update fehl, und das System bleibt mit einem halben Update zurück.

# Wie voll, und was liegt dort?
df -h /boot
ls -1 /boot/vmlinuz-* /boot/initrd.img-* 2>/dev/null

# Was läuft gerade? (nur dieser Kernel ist unantastbar)
uname -r

# Debian: alte Kernel werden von apt selbst verwaltet
sudo apt autoremove --purge

# Arch: installierte Kernel-Pakete anzeigen
pacman -Q | grep -E '^linux'

Logs und das Journal

Das Journal ist der bequemste Posten überhaupt – es räumt sich selbst auf, wenn man ihm Grenzen setzt. Ohne Grenzen wächst /var/log/journal bis zu 10 % des Dateisystems.

# Bestand
journalctl --disk-usage

# Nach Alter oder Größe begrenzen (sofort wirksam)
sudo journalctl --vacuum-time=14d
sudo journalctl --vacuum-size=500M

# Dauerhaft begrenzen – die bessere Lösung
sudo nano /etc/systemd/journald.conf
#   SystemMaxUse=500M
#   MaxRetentionSec=1month
sudo systemctl restart systemd-journald

# Klassische Logdateien (rsyslog)
sudo du -sh /var/log
sudo find /var/log -type f -name '*.gz' -mtime +30 -ls    # erst ansehen

Caches: Benutzer, Flatpak, Container

Caches sind ein Minenfeld: Browser-Caches sind harmlos, Caches von Entwicklungswerkzeugen können Build-Zeit kosten, und ~/.cache pauschal zu löschen wirft bei manchen Anwendungen die Anmeldung weg. Deshalb gezielt statt pauschal:

/tmp, Papierkorb, verwaiste Dateien

/tmp muss man bei systemd-Systemen nicht selbst aufräumen: Es gibt bereits einen Dienst dafür, gesteuert über /usr/lib/tmpfiles.d/tmp.conf und aktiviert durch systemd-tmpfiles-clean.timer.

# Läuft der Aufräum-Timer? (Standard: alle 15 Minuten prüfen, löschen ab 10 Tagen Alter)
systemctl status systemd-tmpfiles-clean.timer

# Konfiguration ansehen und bei Bedarf verschärfen
cat /usr/lib/tmpfiles.d/tmp.conf
sudo systemd-tmpfiles --clean          # sofort aufräumen

# Verwaiste Dateien: gehört diese Datei überhaupt zu einem Paket?
dpkg -S /pfad/zur/datei          # Debian
pacman -Qo /pfad/zur/datei       # Arch

# Optional für Arch: Dateien ohne Paketbesitz finden (extra installieren)
sudo pacman -S lostfiles && sudo lostfiles

Der letzte Punkt ist der interessante: Reste von Programmen, die nie per Paketmanager installiert wurden, findet man nur so. Auf lostfiles-Ausgaben sollte man allerdings nie blind rm anwenden – darunter sind auch selbst erstellte Dateien, Docker-Volumes und Benutzerdaten.

Dienste, Units und Autostarts

# Was ist fehlgeschlagen?
systemctl --failed
systemctl --user --failed

# Was startet wie lange? (Kandidaten zum Deaktivieren)
systemd-analyze blame | head -20

# Laufen noch Timer, die ich mal eingerichtet habe?
systemctl list-timers --all

# Eigene Units, die niemand mehr braucht
systemctl list-unit-files --state=enabled | grep -v '@'

# Crons, die sich angesammelt haben
crontab -l
ls -la /etc/cron.d/ /etc/cron.daily/

Fehlgeschlagene Units aus systemctl --failed haben meist eine echte Ursache (fehlende Datei, Port belegt, Rechte) – die findet man mit journalctl -u dienst -n 50. Es lohnt sich, sie nicht zu ignorieren: Sie kosten bei jedem Start Zeit und verstecken echte Probleme.

Der wichtigste Punkt: Backup prüfen

Wartung heißt nicht nur Platz schaffen. Der wichtigste monatliche Termin ist die Kontrolle, ob dein Backup wirklich funktioniert – denn genau hier verstecken sich die Probleme, die man erst merkt, wenn es zu spät ist:

# Existiert das Repository und sind die Archive lesbar?
borg list /mnt/backup/borg-repo

# Integrität prüfen (dauert – aber einmal im Monat ist es das wert)
sudo borg check --verify-data /mnt/backup/borg-repo

# Wie viel liegt drin, wie viel ist neu?
borg info /mnt/backup/borg-repo

Und einmal im Quartal der eigentliche Test: eine Datei oder einen Ordner wirklich zurückholen – nicht nur „das Archiv ist da“. Wie das mit extract und mount geht, steht im Borg-Artikel dieser Reihe.

systemd-Timer ausführlich erklärt

Ein systemd-Timer besteht aus zwei Dateien: einer Unit, die die Arbeit beschreibt (.service) und einem Timer, der sagt, wann sie läuft (.timer). Beide gehören zusammen und tragen denselben Namen.

# /etc/systemd/system/systempflege.service
[Unit]
Description=Monatliche Systempflege
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/systempflege.sh
Nice=10
IOSchedulingClass=idle

# /etc/systemd/system/systempflege.timer
[Unit]
Description=Monatlicher Aufruf der Systempflege

[Timer]
OnCalendar=monthly
Persistent=true
RandomizedDelaySec=30m
AccuracySec=1min

[Install]
WantedBy=timers.target

Aktivieren, prüfen, beobachten:

sudo systemctl daemon-reload
sudo systemctl enable --now systempflege.timer

# Wann läuft er das nächste Mal? (Spalte NEXT)
systemctl list-timers systempflege.timer

# Was hat er beim letzten Mal getan?
journalctl -u systempflege.service -n 100 --no-pager

# Sofort testen, ohne auf den Termin zu warten
sudo systemctl start systempflege.service

Die Zeitangaben: OnCalendar verstehen

Das Format ist Wochentag Jahr-Monat-Tag Stunde:Minute:Sekunde – nicht angegebene Teile bedeuten „egal“. Am schnellsten lernt man es mit dem Prüfwerkzeug, das die nächsten Ausführungszeiten ausrechnet:

systemd-analyze calendar "monthly"
systemd-analyze calendar "*-*-* 04:30"
systemd-analyze calendar "Mon..Fri *-*-* 08:00"

Die wichtigsten Timer-Optionen

Cron als Alternative

Cron ist älter, einfacher und auf jedem Unix zu finden. Auf Arch/CachyOS ist es nicht vorinstalliert (sudo pacman -S cronie), auf Debian ist es Teil des Basissystems. Ein Cronjob ist eine Zeile mit fünf Zeitfeldern:

# ┌ Min (0-59)
# │ ┌ Std (0-23)
# │ │ ┌ Tag des Monats (1-31)
# │ │ │ ┌ Monat (1-12)
# │ │ │ │ ┌ Wochentag (0-7, 0 und 7 = Sonntag)
# │ │ │ │ │
  0 5 1 * *   root  /usr/local/bin/systempflege.sh >/dev/null 2>&1

Wo Cronjobs hingehören:

Timer oder Cron?

Meine Empfehlung: auf systemd-Systemen Timer. Sie sind nicht komplizierter – nur ausführlicher geschrieben – und sie protokollieren von allein. Cron behält seinen Platz für /etc/cron.daily-Ablagen und für Systeme, auf denen systemd fehlt. Beides parallel zu betreiben ist selten sinnvoll, zwei Stellen für dieselbe Aufgabe verwirren nur.

Das monatliche Aufräum-Skript

Ein Skript für beide Welten: Es erkennt die Distribution selbst und führt nur aus, was vorhanden ist. Mit DRY=1 läuft es im Probelauf und zeigt nur, was es tun würde – der wichtigste Schalter überhaupt.

#!/usr/bin/env bash
# /usr/local/bin/systempflege.sh - monatliche Systempflege
set -euo pipefail

DRY="${DRY:-0}"                       # DRY=1 ./systempflege.sh  -> nur anzeigen
run() {
  if [ "$DRY" = "1" ]; then echo "[dry] $*"; else echo "[run] $*"; "$@"; fi
}
have() { command -v "$1" >/dev/null 2>&1; }

echo "=== Systempflege auf $(hostname) - $(date '+%F %T') ==="
echo "--- vorher ---"; df -h / | tail -1

# 1) Logs begrenzen (unabhaengig von der Distribution)
if have journalctl; then
  echo "Journal bisher: $(journalctl --disk-usage 2>/dev/null | tail -1)"
  run journalctl --vacuum-time=14d
  run journalctl --vacuum-size=500M
fi

# 2) Paketverwaltung
if have apt-get; then
  echo "--- Debian-Familie ---"
  run apt-get -y autoremove --purge
  run apt-get -y clean
  run apt-get -y autoclean
  run apt-get -y --fix-broken install
elif have pacman; then
  echo "--- Arch-Familie ---"
  ORPHANS="$(pacman -Qdtq || true)"
  if [ -n "$ORPHANS" ]; then
    echo "Verwaiste Pakete:"; echo "$ORPHANS" | sed 's/^/  - /'
    if [ "$DRY" = "1" ]; then echo "[dry] pacman -Rns $ORPHANS"
    else run pacman -Rns --noconfirm $ORPHANS; fi
  else echo "keine verwaisten Pakete"; fi

  if have paccache; then run paccache -rk2; run paccache -ruk0
  else echo "Hinweis: pacman-contrib fehlt (paccache)"; fi

  [ -d /var/cache/pacman/pkg ] && echo "Paketcache: $(du -sh /var/cache/pacman/pkg | cut -f1)"
fi

# 3) Flatpak
if have flatpak; then run flatpak uninstall --unused --noninteractive; fi

# 4) Container - ohne Volumes!
if have docker; then
  run docker container prune -f
  run docker image prune -f
  run docker network prune -f
fi

# 5) Benutzer-Caches des aufrufenden Kontos
if [ -n "${HOME:-}" ] && [ "$(id -u)" != "0" ]; then
  run rm -rf "$HOME/.cache/thumbnails"/* 2>/dev/null || true
  [ -d "$HOME/.local/share/Trash/files" ] && run rm -rf "$HOME/.local/share/Trash/files"/*
fi

# 6) Backup-Kontrolle (nur pruefen, nicht schreiben)
if have borg && [ -d /mnt/backup/borg-repo ]; then
  echo "--- Borg ---"; run borg list /mnt/backup/borg-repo | tail -3
fi

echo "--- nachher ---"; df -h / | tail -1
echo "=== fertig ==="

Ausführbar machen und erst im Probelauf, dann echt:

sudo install -m 755 systempflege.sh /usr/local/bin/systempflege.sh

# Probelauf als root (zeigt nur, was passieren wuerde)
sudo DRY=1 /usr/local/bin/systempflege.sh

# Echt laufen lassen
sudo /usr/local/bin/systempflege.sh

Und die Aktivierung – einmal systemweit, einmal für dein Konto:

sudo systemctl daemon-reload
sudo systemctl enable --now systempflege.timer

# User-Variante (Datei unter ~/.config/systemd/user/systempflege-user.timer)
systemctl --user daemon-reload
systemctl --user enable --now systempflege-user.timer

# Kontrolle
systemctl list-timers 'systempflege*'
systemctl --user list-timers 'systempflege*'

Was du nicht löschen solltest

Häufige Fragen (FAQ)

Fazit

Aufräumen ist kein Spektakel, sondern eine Routine aus fünf Befehlen, die man in ein Skript packt – und ein Skript, das man von systemd ausführen lässt. Debian und Arch unterscheiden sich dabei nur in der Paketverwaltung; alles andere (Journal, Caches, Container, Backups) ist identisch.

Der Timer ist dabei die eigentliche Erkenntnis: Zwei kleine Dateien, eine klare Zeitangabe und Persistent=true – danach musst du nie wieder daran denken. Und wenn du das Muster einmal verstanden hast, nutzt du es für alles: Backups, Zertifikate, Aufräumen.