Linux-Serverwartung: Wöchentliche Checkliste

Was Linux-Serverwartung tatsächlich bedeutet

Linux-Serverwartung besteht aus einer kurzen Liste von Prüfungen, die nach einem festen Zeitplan ausgeführt werden. Sie ist kein Projekt mit einem Endpunkt. Wöchentlich prüfen Sie, ob Updates installiert wurden, ob auf dem Datenträger ausreichend Speicherplatz verfügbar ist, ob kein Dienst ausgefallen ist und ob der Backup-Auftrag erfolgreich abgeschlossen wurde. Monatlich testen Sie eine Wiederherstellung, prüfen den Ablauf von Zertifikaten, kontrollieren Konten und kryptografische Schlüssel und entfernen alte Kernel sowie Logs. Einmal pro Distributionsversion planen Sie das Versionsupgrade und führen den Reboot durch, den Sie immer wieder verschieben.

Das Einrichten des Servers ist eine andere Aufgabe. Die ersten zehn Minuten auf einem neuen VPS behandelt diesen Teil. Diese Seite beschreibt das Jahr danach. Jeder folgende Punkt nennt den Fehler, den er verhindert. Eine Checkliste ohne erkennbare Folgen wird stillschweigend nicht mehr ausgeführt.

Die Befehle hier dienen als Beispiele und sollten vor der Ausführung gelesen werden. Vergleichen Sie die Ausgabe mit Ihrem eigenen Server. Ein gesunder Wert für freien Speicherplatz oder die Anzahl der Prozesse hängt von der Aufgabe des Servers ab. Wenn sich eine Prüfung zwischen Distributionen unterscheidet, wird darauf hingewiesen. Die Beispiele verwenden Debian und Ubuntu mit apt. In der RHEL-Familie wird dnf verwendet, und mehrere Pfade unterscheiden sich.

So wählen Sie einen Wartungsrhythmus für Linux-Server, den Sie einhalten

Wöchentliche Prüfungen decken Dinge ab, die sich ohne Ihr Zutun ändern: Pakete, Speicherplatz, Dienststatus und geplante Jobs. Diese Werte ändern sich selbstständig. Eine Woche ist daher ungefähr der längste Zeitraum, über den Sie sie ungeprüft lassen sollten.

Monatliche Prüfungen decken schleichende Veränderungen ab: Zertifikate, deren Ablauf näher rückt, Konten, die niemand entfernt hat, sich in /boot ansammelnde Kernel und Logdateien, die über eine Rotationsregel hinauswachsen, die nicht mehr greift. Nichts davon führt morgen zu einem Ausfall. Alles davon führt irgendwann zu einem Ausfall.

Release-Prüfungen richten sich nach dem Kalender. Ein Distributions-Release ist der einzige Wartungspunkt mit einer externen Frist, weil der Support für Ihre aktuelle Version endet, unabhängig davon, ob Sie bereit sind.

Legen Sie einen festen Zeitpunkt fest: Montagmorgen für die wöchentliche Prüfung und der erste Tag des Monats für die monatliche Prüfung. Eine Checklistenprüfung nach dem Motto „wenn ich dazu komme“ ist keine Checkliste. Sobald Sie mehr als eine Handvoll Rechner verwalten, führen Sie diese Prüfungen zentral statt manuell aus. Das ist das Thema von mehrere Linux-Server zentral verwalten.

Wöchentlich: Wurden die Updates tatsächlich installiert?

unattended-upgrades zu aktivieren bedeutet nicht, dass der Dienst erfolgreich ausgeführt wurde. Der Dienst kann maskiert sein, die Konfiguration kann auf eine Quelle beschränkt sein, die Sie nicht verwenden, und ein zurückgehaltenes Paket kann jeden weiteren Lauf verhindern. Die Installation wird unter automatische Sicherheitsupdates unter Ubuntu beschrieben. Der wöchentliche Auftrag weist nach, dass die installierte Automatisierung tatsächlich funktioniert.

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable ist das maßgebliche Kriterium, weil der Befehl den aktuellen Zustand und nicht die Absicht anzeigt. Sicherheitsupdates, die weiterhin in dieser Liste stehen, zeigen, dass die Automatisierung nicht ordnungsgemäß arbeitet. Lesen Sie daher das Protokoll, bevor Sie davon ausgehen, dass der Rechner gepatcht ist. Ein mit apt-mark hold festgehaltenes Paket wird dauerhaft übersprungen und erzeugt keine Meldung. Deshalb gehört apt-mark showhold in denselben Prüflauf.

Das verhindert folgenden Fehler: Sie führen monatelang ein bekanntermaßen verwundbares Paket aus, weil Sie davon ausgehen, dass die Updates automatisch installiert werden.

Wöchentlich: Reserven bei Speicherplatz und Inodes

Ein volles Root-Dateisystem verursacht Probleme, die nicht unmittelbar mit Speicherplatz in Verbindung gebracht werden. Die Datenbank verweigert Schreibvorgänge, die Protokollierung stoppt, ein Paket-Upgrade bricht nach einer nur teilweise abgeschlossenen Konfiguration ab, und auf manchen Systemen können Sie keine neue Sitzung öffnen, weil dafür eigene Dateien geschrieben werden müssen.

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i ist der Teil, den die meisten überspringen. Inodes sind Strukturen mit fester Anzahl, die Dateimetadaten enthalten. Ein Dateisystem kann keine Inodes mehr haben, während df -h weiterhin freie Gigabytes meldet. Schreibvorgänge schlagen dann mit No space left on device fehl, obwohl die Ausgabe freien Speicherplatz anzeigt. Beim ersten Auftreten kostet das meist eine verwirrende Stunde. Millionen kleiner Dateien sind die übliche Ursache, beispielsweise aus einer blockierten Mail-Warteschlange oder einem Sitzungsverzeichnis, das niemand bereinigt.

du -xh bleibt auf einem Dateisystem. Das ist auf einem System mit Bind-Mounts oder angeschlossenem Speicher erwünscht. Auf einem Docker-Host liegt die Ursache meist in Image-Layern und nicht mehr verwendeten Volumes. Sie können sie wie unter Docker-Speicherplatz auf einem VPS bereinigen beschrieben entfernen.

Freier Speicherplatz informiert über die Kapazität. Der darunterliegende Speicher kann unabhängig davon ausfallen. Das ist eine separate Prüfung, die unter Speicherzustand auf einem VPS überwachen beschrieben wird.

Wöchentlich: Was ist unbemerkt ausgefallen?

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

Eine Unit, die abgestürzt ist und ihr Neustartlimit erreicht hat, bleibt im Status failed und verharrt dort. Niemand informiert Sie per E-Mail darüber. list-timers ist die nützlichere Ergänzung: Der Befehl zeigt, wann jeder Timer zuletzt ausgeführt wurde und wann er als Nächstes ausgelöst wird. Ein LAST-Wert, der älter ist als das eigene Intervall des Timers, bedeutet daher, dass der betreffende Job überhaupt nicht ausgeführt wurde.

Lesen Sie das Journal der Unit, bevor Sie sie neu starten, mit journalctl -u <unit> -n 100 --no-pager. Ein Neustart beseitigt nur das Symptom. Danach gibt es keinen Grund mehr, erneut nachzusehen, bis dasselbe Problem zu einem ungünstigeren Zeitpunkt wieder auftritt.

Der dadurch verhinderte Ausfall: Ein Monitoring-Agent, ein Warteschlangen-Worker oder ein Backup-Dienst, der seit einer Speicherspitze vor drei Wochen nicht mehr läuft.

Wöchentlich: Wurde der Backup-Job tatsächlich abgeschlossen?

Ein geplanter Backup-Job und ein abgeschlossenes Backup sind zwei verschiedene Dinge. Nur eines davon lässt sich wiederherstellen. Prüfen Sie den Abschluss.

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

Bestätigen Sie zwei Dinge. Der letzte Lauf muss mit Exit-Code 0 beendet worden sein. Das neueste Archiv muss außerdem aktuell sein und ungefähr die erwartete Größe haben. Eine Backup-Datei, die plötzlich nur ein Zehntel ihrer üblichen Größe hat, ist ein fehlgeschlagener Dump, der trotzdem eine Datei geschrieben hat. Das ist die gefährlichste Form eines Backup-Fehlers, weil alle nachgelagerten Schritte normal aussehen.

Wenn Ihr Skript einen Dump an einen Kompressor weiterleitet, fügen Sie oben set -o pipefail ein. Ohne diese Option ist der Exit-Status der Pipeline der des Kompressors. Der Kompressor war erfolgreich: Er hat die Fehlermeldung komprimiert. Der Job meldet dann jede Nacht Erfolg und schreibt dabei ein kleines Archiv mit keinen Nutzdaten.

Monatlich: Ein Backup an einem anderen Ort wiederherstellen

Diesen Punkt überspringen die meisten. Er entscheidet jedoch darüber, ob die übrigen Punkte der Liste überhaupt relevant waren.

Stellen Sie das Backup auf einer anderen Maschine oder in einem neuen Container wieder her, niemals über den aktiven Daten. Öffnen Sie anschließend die wiederhergestellten Daten und prüfen Sie, ob sie tatsächlich verwendbar sind. Zählen Sie die Zeilen in einer Tabelle. Öffnen Sie ein Dokument. Melden Sie sich bei der wiederhergestellten Anwendung an. Eine abgeschlossene Extraktion beweist nur, dass das Archiv lesbar ist, und nicht mehr.

Repository-Tools verfügen über eine eigene Verifizierung: restic check --read-data-subset=5% und borg check --verify-data lesen die gespeicherten Daten statt des Index. Führen Sie sie aus und betrachten Sie sie als Smoke-Test, nicht als Ersatz für eine Wiederherstellung. Die Verifizierung prüft, ob die Bytes erhalten geblieben sind. Eine Wiederherstellung prüft, ob es sich um die Bytes handelt, die Ihre Anwendung benötigt.

Zwei Details lernen viele erst auf die harte Tour. Testen Sie die Entschlüsselungs-Passphrase auf einer Maschine, auf der der Schlüssel nicht bereits in einem Agent gespeichert ist. Ein Backup, das Sie nicht entschlüsseln können, ist kein Backup. Messen Sie außerdem die Dauer der Wiederherstellung. Diese Dauer entspricht Ihrer tatsächlichen Wiederherstellungszeit. Meist wird sie erst während eines Ausfalls ermittelt.

Monatlich: Welche Zertifikate laufen bald ab?

Die automatische Erneuerung kann unbemerkt fehlschlagen. Der certbot-Timer kann die Datei auf dem Datenträger erneuern, während der Webserver weiterhin das alte Zertifikat aus dem Speicher ausliefert, weil der Deploy-Hook zum Neuladen des Dienstes nicht ausgeführt wurde. Fragen Sie daher den laufenden Server von außerhalb des Systems ab, welches Zertifikat er ausliefert.

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Das Flag -servername setzt SNI (Server Name Indication). SNI ist für jede Adresse erforderlich, auf der mehrere Websites gehostet werden. Andernfalls erhalten Sie das Standardzertifikat statt Ihres Zertifikats. Wenn certbot aus einem snap installiert wurde, heißt der Timer anders. Suchen Sie daher nach dem Wort und nicht nach einer Unit, deren Namen Sie angenommen haben.

Denken Sie auch an Zertifikate ohne jede Automatisierung: ein Mailserver, ein VPN oder eine interne Zertifizierungsstelle. Diese Zertifikate laufen am Wochenende ab. Browser und Clients lehnen sie dann vollständig ab, statt nur eine Warnung anzuzeigen.

Monatlich: Benutzer, sudo-Zugriff und SSH-Schlüssel

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T gibt die effektive Konfiguration aus, nachdem alle Include zusammengeführt wurden. Diese Konfiguration verwendet der Daemon tatsächlich. Aktuelle Ubuntu-Images enthalten Drop-in-Dateien in /etc/ssh/sshd_config.d/. Diese können die Hauptdatei überschreiben. Wenn Sie nur sshd_config lesen, kann das daher zum gegenteiligen Ergebnis führen. In der RHEL-Familie heißt die administrative Gruppe wheel statt sudo. Passen Sie die Zeile getent entsprechend an.

Lesen Sie anschließend die Dateien authorized_keys selbst. Der Zugriff wird über den Schlüssel gewährt, nicht über das Benutzerkonto. Ein Schlüssel, den ein vor sechs Monaten ausgeschiedener Auftragnehmer hinterlassen hat, ermöglicht weiterhin eine Anmeldung. In keiner Benutzerliste fällt er auf. Schlüssel enthalten ein Kommentarfeld. Verwenden Sie dieses Feld. Löschen Sie alle Schlüssel, die Sie keiner Person zuordnen können.

Für die Anmeldehistorie sucht journalctl -t sshd --since "30 days ago" | grep -i accepted anhand des Syslog-Bezeichners und nicht anhand eines Unit-Namens. Das ist relevant, weil Ubuntu 24.04 SSH über einen Socket aktiviert. Dadurch wird jede Verbindung unter einer eigenen, automatisch erzeugten Unit protokolliert. Ein einfaches journalctl -u ssh kann diese Einträge daher übersehen.

Monatlich: alte Kernel und ein volles /boot

/boot ist auf einem Standard-VPS-Image häufig eine eigene Partition mit einigen hundert Megabytes. Jedes Kernel-Update fügt dort ein Image und ein initramfs hinzu. Wenn die Partition voll läuft, schlägt das nächste Upgrade teilweise fehl und lässt Pakete unkonfiguriert zurück. Das ist ein problematischer Zustand, wenn er am Freitag unerwartet auftritt.

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

Prüfen Sie zuerst immer uname -r: Damit wird der Kernel angezeigt, den Sie aktuell ausführen. Dieser Kernel muss alle Bereinigungen überstehen. apt autoremove deckt den Normalfall unter Debian und Ubuntu ab, weil Kernel als automatisch installiert markiert sind und der aktuelle Kernel geschützt wird. Sonderfälle, etwa ein manuell installierter Kernel oder ein /boot, das bereits so voll ist, dass apt selbst blockiert wird, werden unter alte Kernel unter Ubuntu entfernen behandelt.

Monatlich: Log-Wachstum und das systemd-Journal

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

logrotate --debug ist ein Probelauf und schreibt nichts. Der Befehl kann daher sicher auf einem laufenden System ausgeführt werden. Der Probelauf ist sinnvoll, weil Rotationsregeln anhand von Pfaden greifen: Wenn eine Anwendung ihren Log-Pfad während eines Upgrades geändert hat, wird sie von ihrer eigenen Regel nicht mehr erfasst. Die Datei wächst dann unbegrenzt weiter, bis die Festplatte voll ist.

Das Journal wird von systemd begrenzt, allerdings anhand eines Anteils des Dateisystems und nicht anhand einer von Ihnen festgelegten Größe. Setzen Sie SystemMaxUse= in /etc/systemd/journald.conf und starten Sie systemd-journald neu, wenn Sie eine bestimmte Obergrenze festlegen möchten. sudo journalctl --vacuum-time=14d gibt sofort Speicherplatz frei. Der Befehl ist jedoch eine einmalige Aktion und keine Richtlinie. Führen Sie ihn daher zusammen mit der Konfigurationsänderung aus.

Pro Release: der immer wieder aufgeschobene Reboot

Ein aktualisiertes Kernelpaket auf der Festplatte ist kein laufender Kernel. Bis zum Reboot verwendet die Maschine weiterhin den alten Kernel. Live-Patching deckt, sofern verfügbar, außerdem nur einen Teil der Fehlerbehebungen ab.

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

Diese Flag-Datei ist eine von Paketskripten geschriebene Konvention von Debian und Ubuntu. Systeme der RHEL-Familie legen sie nicht an. Die entsprechende Abfrage erfolgt dort mit needs-restarting -r, das aus dnf-utils stammt. needrestart, das auf aktuellen Ubuntu-Server-Images standardmäßig installiert ist, beantwortet die darunterliegende Ebene des Kernels: Es listet Prozesse auf, die weiterhin eine Bibliothek verwenden, die auf der Festplatte ersetzt wurde. Deshalb wird ein gepatchtes OpenSSL erst wirksam, wenn die entsprechenden Dienste neu gestartet werden.

Planen Sie den Reboot, statt ihn zu vermeiden. Mit /etc/apt/apt.conf.d/50unattended-upgrades, Unattended-Upgrade::Automatic-Reboot "true"; und Unattended-Upgrade::Automatic-Reboot-Time "03:00"; übergeben Sie die Entscheidung an einen von Ihnen festgelegten Zeitpunkt. Ein geplanter Reboot ist außerdem der einzige Test dafür, ob die Maschine wieder startet. Ein fehlerhafter fstab-Eintrag oder ein Dienst, den Sie nie aktiviert haben, zeigt sich beim Boot und sonst nirgendwo.

Pro Release: Planung des Distributions-Upgrades

Ubuntu-LTS-Releases erhalten fünf Jahre Standardsupport, Interim-Releases neun Monate. Diese Entscheidung bestimmt Ihren Upgrade-Aufwand für mehrere Jahre. Dieser Zielkonflikt wird unter LTS- und Interim-Releases auf einem Server erläutert.

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade liest diese Datei ein, und Prompt=lts beschränkt sie auf Wechsel von LTS zu LTS. Der Pfad von einer LTS-Version zur nächsten wird normalerweise erst mit dem ersten Point-Release der neuen Version freigeschaltet, nicht am Tag der Veröffentlichung. Prüfen Sie daher, welche Version Ihrem Rechner tatsächlich angeboten wird, statt mit einem angenommenen Datum zu planen. Die einzelnen Schritte des Upgrades werden unter Ubuntu 24.04 auf 26.04 upgraden beschrieben.

Planen Sie einen Puffer von drei Monaten ein. Erstellen Sie einen Snapshot und testen Sie dessen Wiederherstellung. Listen Sie Ihre Drittanbieter-apt-Repositorys auf. Das Upgrade deaktiviert diese Repositorys, und für jedes Repository benötigen Sie ein neues Ziel für die neue Release-Version. Legen Sie den Rollback fest, bevor Sie beginnen. Im August 2026 erhält Ubuntu 24.04 LTS noch bis April 2029 Standardsupport. Daher handelt es sich um eine Zeitplanung und nicht um einen Notfall.

Was Sie automatisieren sollten und was manuell bleiben sollte

Automatisieren Sie die Entscheidungen, die Sie bereits getroffen haben: Sicherheitsupdates, Logrotation, Zertifikatserneuerung und Backup-Jobs. Automatisieren Sie auch die Alarmierung, denn eine Prüfung, die davon abhängt, dass Sie sich an sie erinnern, findet um 2 Uhr nachts nicht statt. Ein externer Monitor, beispielsweise Self-Hosting einer Statusüberwachung mit Uptime Kuma, erkennt den einen Zustand, den kein Skript auf dem Server melden kann: Der Server ist nicht erreichbar.

Zwei Dinge sollten manuell bleiben: der Restore-Test und die Kontenprüfung. In beiden Fällen muss eine Person entscheiden, ob das Ergebnis korrekt ist. Wenn Sie den Systemzustand lieber in einem Browser als in einem Terminal prüfen, vergleicht Cockpit und Webmin für die Serververwaltung die beiden üblichen Webkonsolen.

Auch die Automatisierung selbst muss geprüft werden. Deshalb steht die Überprüfung des Updaters als erster wöchentlicher Punkt auf dieser Liste. Eine Automatisierung, die unbemerkt fehlschlägt, ist schlechter als keine Automatisierung, weil sie gleichzeitig den Fehler und die Gewohnheit beseitigt, regelmäßig nachzusehen.

Die gesamte Checkliste an einer Stelle

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

Wie oft sollte ich Linux-Server warten?

Wöchentlich bei allem, was sich selbstständig ändert: Update-Status, freier Speicherplatz und verfügbare Inodes, fehlgeschlagene Units sowie die Frage, ob der Backup-Job abgeschlossen wurde. Monatlich bei schleichenden Problemen: ein Restore-Test, das Ablaufdatum von Zertifikaten, die Prüfung von Konten und SSH-Schlüsseln, alte Kernel und das Log-Wachstum. Einmal pro Distribution-Release für das Versionsupgrade und den Reboot in den aktuellen Kernel. Die wöchentliche Prüfung dauert auf einem gesunden System nur wenige Minuten. Genau deshalb sollte sie wöchentlich erfolgen und nicht erst, wenn etwas fehlerhaft aussieht.

Warum sollte ich einen Restore testen, wenn der Backup-Job Erfolg meldet?

Weil der Job nur seinen eigenen Exit-Status meldet. Dieser Status kann erfolgreich sein, obwohl das Archiv unbrauchbar ist. Ein Dump, der ohne set -o pipefail in einen Kompressor geleitet wird, liefert den Status des Kompressors zurück. Ein fehlgeschlagener Dump, der nur eine Fehlermeldung erzeugt, kann dadurch trotzdem mit Exit-Status 0 enden und eine kleine Datei schreiben. Führen Sie den Restore auf einem anderen System durch, öffnen Sie die Daten und zählen Sie einen Wert. Beim Restore wird außerdem die Dauer gemessen. Diese Dauer ist Ihre tatsächliche Wiederherstellungszeit.

Muss ich nach jedem Kernel-Update einen Reboot durchführen?

Sie müssen einen Reboot durchführen, bevor der neue Kernel der laufende Kernel ist. Auf Debian und Ubuntu zeigt das Vorhandensein von /var/run/reboot-required, dass ein Paket dies angefordert hat. /var/run/reboot-required.pkgs nennt das betreffende Paket. In der RHEL-Familie existiert diese Datei nicht. needs-restarting -r aus dnf-utils beantwortet dort dieselbe Frage. Legen Sie in /etc/apt/apt.conf.d/50unattended-upgrades ein automatisches Reboot-Zeitfenster fest, statt den Reboot dauerhaft aufzuschieben. Ein System, das seit einem Jahr nicht neu gestartet wurde, hat neben einem alten Kernel auch einen nicht getesteten Bootpfad.

Welche dieser Prüfungen kann ich sicher automatisieren?

Automatisieren Sie Aktionen, deren Entscheidung bereits feststeht: Sicherheitsupdates, Log-Rotation, die Erneuerung von Zertifikaten und geplante Backups. Automatisieren Sie auch die Benachrichtigung, damit Sie von einer fehlgeschlagenen Unit oder einem vollen Datenträger erfahren, ohne dass jemand manuell einen Befehl ausführen muss. Lassen Sie den Restore-Test und die Prüfung der Schlüssel manuell durchführen. Für beide muss eine Person beurteilen, ob das Ergebnis korrekt ist. Fügen Sie anschließend eine Prüfung der Automatisierung selbst hinzu. Ein unbemerktes Versagen des Update-Mechanismus sieht sonst genauso aus wie ein ordnungsgemäß laufender Betrieb.