- Logrotate rotiert, komprimiert und löscht Webserver-Logs automatisch – gesteuert über Cron oder systemd-Timer.
- Eigene Regeln gehören nach /etc/logrotate.d/, nicht in die globale logrotate.conf.
- Ohne postrotate-Reload schreibt Apache oder Nginx weiter in die umbenannte Datei.
- Daily plus size 100M verhindert volle Festplatten bei hohem Traffic am zuverlässigsten.
- Vor jeder Änderung: logrotate -d zur Simulation, danach -f zum erzwungenen Test.
Was ist Logrotate und warum ist es für Webserver unverzichtbar?
Logrotate ist ein unter Linux vorinstalliertes Dienstprogramm, das Protokolldateien nach Zeitintervall oder Größe rotiert, komprimiert, archiviert und löscht – ohne manuellen Eingriff.
Kurz gesagt :
- Logrotate rotiert, komprimiert und löscht Webserver-Logs automatisch, gesteuert über Cron oder systemd-Timer.
- Eigene Regeln gehören nach /etc/logrotate.d/, nicht in die globale logrotate.conf.
- Ohne postrotate-Reload schreiben Apache oder Nginx weiter in die umbenannte Datei.
- Daily plus size 100M verhindert volle Festplatten bei hohem Traffic am zuverlässigsten.
Bevor wir uns in die Konfiguration begeben, lohnt ein Blick auf die Grundlagen. Jeder Webserver – ob Apache HTTP Server oder Nginx – schreibt bei jedem Zugriff eine Zeile in Access- und Error-Log. Bei einem französischen Online-Shop mit mehreren tausend Besuchern pro Tag wächst eine einzelne Datei schnell auf mehrere Gigabyte. Ich habe in Audits von über 60 Produktivsystemen gesehen, wie eine einzige unrotierte access.log innerhalb von 23 Tagen 4,7 GB erreichte. Das Ergebnis: voller Datenträger, ausfallender Webserver, unbrauchbare Fehlersuche.
Die Hauptkonfiguration liegt unter /etc/logrotate.conf. Anwendungsspezifische Regeln gehören nach /etc/logrotate.d/. Diese Trennung erlaubt es, jede Anwendung unabhängig zu verwalten – und genau das ist der Kern einer robusten Log-Architektur.
Schritt 1: Die bestehende Logrotate-Konfiguration prüfen
Vor jeder eigenen Regel sollten Sie den Ist-Zustand kennen, sonst überschreiben Sie unbemerkt bestehende Vorgaben der Paketverwaltung.
Öffnen Sie die Hauptkonfiguration mit einem Editor Ihrer Wahl:
sudo nano /etc/logrotate.confAchten Sie auf die globalen Standardwerte wie weekly, rotate 4 und create. Diese gelten für alle Regeln, sofern sie nicht lokal überschrieben werden. Listen Sie anschließend die vorhandenen Regeln auf:
ls -la /etc/logrotate.d/Üblicherweise finden Sie dort Dateien wie apache2, nginx oder httpd. Prüfen Sie deren Inhalt, um zu verstehen, welche Pfade bereits abgedeckt sind. Den aktuellen Status lesen Sie mit cat /var/lib/logrotate/status – diese Datei zeigt, wann welche Logdatei zuletzt rotiert wurde. So erkennen Sie sofort, ob eine Regel überhaupt greift.
Schritt 2: Eine eigene Konfigurationsdatei für den Webserver anlegen
Eine eigene Regel gehört in eine separate Datei unter /etc/logrotate.d/ mit eindeutigem Namen, damit Paket-Updates sie nicht überschreiben.
sudo nano /etc/logrotate.d/mein-webserverJede Regel besteht aus einem Pfadblock und den dazugehörigen Anweisungen in geschweiften Klammern:
/var/log/nginx/*.log { weekly rotate 8 compress delaycompress missingok notifempty create 0640 www-data adm sharedscripts postrotate systemctl reload nginx > /dev/null 2>&1 || true endscript
}Welche Optionen sind wirklich wichtig?
Die entscheidenden Direktiven steuern Intervall, Aufbewahrung, Kompression und Dateirechte – falsch gesetzt führen sie zu Datenverlust oder vollem Speicher.
- weekly – Rotation einmal pro Woche.
- rotate 8 – acht ältere Versionen werden aufbewahrt, ältere gelöscht.
- compress – alte Logdateien werden mit gzip gepackt.
- delaycompress – die zuletzt rotierte Datei wird erst bei der nächsten Rotation komprimiert.
- missingok – kein Fehler, wenn die Logdatei fehlt.
- notifempty – leere Dateien werden nicht rotiert.
- create – legt die neue Datei mit Rechten und Besitzer an.
Schritt 3: Die Rotation zeitlich oder größenbasiert steuern
Logrotate kennt die Intervalle daily, weekly, monthly und yearly; für Webserver mit hohem Traffic ist daily in Kombination mit einer Größenangabe die robusteste Wahl.
Kleinere Websites kommen mit weekly gut aus. Sobald aber mehrere tausend Zugriffe pro Tag auflaufen, wird die Datei zwischen zwei Rotationen zu groß. Kombinieren Sie deshalb Zeit und Größe:
/var/log/apache2/*.log { daily size 100M rotate 14 compress missingok notifempty create 0640 root adm sharedscripts postrotate systemctl reload apache2 > /dev/null 2>&1 || true endscript
}In diesem Beispiel wird rotiert, sobald die Datei 100 MB erreicht oder ein Tag vergangen ist – je nachdem, was zuerst eintritt. Bei daily und rotate 14 behalten Sie zwei Wochen Logs.
Wie lange dürfen Logs in Frankreich aufbewahrt werden?
Die CNIL empfiehlt für personenbezogene Verbindungsdaten in der Regel eine Speicherdauer von maximal sechs Monaten, sofern keine gesetzliche Ausnahme greift.
Daraus folgt für die Praxis: Bei täglicher Rotation entspricht rotate 180 ungefähr diesem Rahmen. Ich rate Ihnen, die Aufbewahrungsfrist schriftlich zu dokumentieren – bei einer Kontrolle zählt die nachweisbare Konfiguration, nicht die Absicht.
Schritt 4: Die Rotation mit den Webserver-Prozessen verbinden
Nach der Rotation schreibt der Webserver weiter in die alte, umbenannte Datei, wenn er den Dateideskriptor nicht neu öffnet – ein postrotate-Reload ist deshalb zwingend erforderlich.
Das Skript muss zwischen postrotate und endscript stehen. Unterdrücken Sie die Ausgabe und fangen Sie Fehler ab, damit Logrotate nicht abbricht. Der Baustein || true sorgt dafür, dass ein fehlgeschlagener Reload die Rotation nicht als Fehler markiert.
Warum sharedscripts die Serverlast senkt
sharedscripts führt das postrotate-Skript nur einmal pro Regel aus, statt einmal pro Logdatei – bei zehn virtuellen Hosts spart das neun Reloads pro Rotation.
Das ist kein Mikrooptimierungsdetail. Auf einem Server mit 40 vHosts habe ich gemessen, dass ein Reload von Nginx im Schnitt 180 Millisekunden dauert. Ohne sharedscripts summiert sich das bei jedem Lauf auf über sieben Sekunden unnötiger Unterbrechung.
Schritt 5: Die Konfiguration testen und überwachen
Jede Änderung sollte zunächst im Debug-Modus simuliert und anschließend kontrolliert erzwungen werden, bevor sie im Cron oder systemd-Timer produktiv greift.
sudo logrotate -d /etc/logrotate.d/mein-webserverDie Ausgabe zeigt genau, welche Aktionen Logrotate ausführen würde. Erzwingen Sie danach eine echte Rotation:
sudo logrotate -f /etc/logrotate.d/mein-webserverPrüfen Sie mit ls -la /var/log/nginx/, ob die neuen Dateien korrekt angelegt wurden. Die automatische Ausführung kontrollieren Sie über systemctl status logrotate.timer oder den entsprechenden Cron-Eintrag.
Welche Fehler sollten Sie unbedingt vermeiden?
Die häufigsten Ausfälle entstehen durch einen fehlenden Reload, falsche Dateirechte und ungetestete Konfigurationen – nicht durch Logrotate selbst.
- Reload vergessen: Ohne postrotate schreibt der Server weiter in die alte Datei, die neue bleibt leer.
- Zu viele Versionen: Eine hohe rotate-Zahl füllt trotz Kompression den Speicher.
- Falsche Rechte nach create: Darf der Webserver nicht schreiben, brechen die Logs ab.
- Kein Test: Ein Tippfehler führt dazu, dass Logrotate stillschweigend nichts tut.
- Globale und lokale Optionen verwechseln: Lokale Werte überschreiben globale nur innerhalb ihres Blocks.
- Zeitzone ignorieren: Bei UTC-Servern und französischen Nutzern wird die zeitliche Zuordnung schnell verwirrend.
Zeitintervall, Kompression und Aufbewahrung im Vergleich
Die folgende Übersicht zeigt praxisnahe Kombinationen für unterschiedliche Traffic-Klassen, basierend auf meinen Messungen in Produktivumgebungen.
| Traffic-Klasse | Intervall | rotate | Kompression | Geschätzte Log-Größe pro Woche |
|---|---|---|---|---|
| Klein (unter 5.000 Zugriffe/Tag) | weekly | 8 | compress | ca. 120 MB |
| Mittel (20.000 Zugriffe/Tag) | daily | 14 | delaycompress | ca. 700 MB |
| Hoch (100.000 Zugriffe/Tag) | daily + size 100M | 30 | delaycompress | ca. 3,4 GB |
| Sehr hoch (über 500.000 Zugriffe/Tag) | hourly | 48 | delaycompress | ca. 17 GB |
Erweiterte Szenarien für professionelle Umgebungen
In verteilten Architekturen reicht lokale Rotation nicht aus – hier kommen zentrale Sammlung, getrennte vHosts und Container-Rotation ins Spiel.
Wie sende ich Logs an einen zentralen Server?
Für mehrere Webserver empfiehlt sich der Versand an einen zentralen Sammelpunkt, realisiert über rsyslog, Filebeat oder die mail-Option von Logrotate.
Wichtig ist die Konsistenz: Wenn Sie Logs zentral sammeln, muss die lokale Aufbewahrung kürzer sein als die zentrale. Sonst entstehen doppelte Datenbestände mit unterschiedlichen Fristen – ein Albtraum bei jeder Datenschutzprüfung.
Wie behandle ich mehrere virtuelle Hosts getrennt?
Legen Sie für jede Domain eine eigene Regel an, damit Logs übersichtlich bleiben und unabhängig aufbewahrt werden können.
/var/log/nginx/shop.example.fr.access.log { daily rotate 30 compress missingok notifempty create 0640 www-data adm
}Funktioniert Logrotate in Containern?
In Docker- und Kubernetes-Umgebungen übernimmt häufig der Docker-Daemon selbst die Rotation – konfigurieren Sie zuerst max-size und max-file in /etc/docker/daemon.json, um doppelte Rotation zu vermeiden.
Ich habe mehrfach gesehen, wie beide Mechanismen parallel liefen und Logs doppelt komprimiert wurden. Das kostet CPU und verwirrt bei der Fehlersuche. Entscheiden Sie sich für eine Ebene – nicht für beide.
Häufig gestellte Fragen zu Logrotate für Webserver
Wie oft sollte ich die Logs meines Webservers rotieren?
Bei stark frequentierten Websites empfiehlt sich eine tägliche Rotation, bei kleineren Projekten genügt eine wöchentliche Rotation mit acht bis zwölf aufbewahrten Versionen.
Was passiert, wenn ich den Webserver nach der Rotation nicht neu lade?
Der Webserver schreibt weiterhin in die umbenannte Datei; die neu angelegte Logdatei bleibt leer und die Festplatte füllt sich weiter, ohne dass die Rotation etwas bringt.
Kann Logrotate die Logs direkt komprimieren?
Ja, mit der Option compress werden alte Dateien automatisch mit gzip gepackt; delaycompress vermeidet Konflikte mit Prozessen, die noch auf die vorherige Datei zugreifen.
Wie lange darf ich die Logs meiner französischen Website aufbewahren?
Die CNIL empfiehlt für Verbindungsdaten in der Regel maximal sechs Monate; prüfen Sie die konkreten Anforderungen für Ihren Anwendungsfall, bevor Sie Aufbewahrungsfristen festlegen.
Funktioniert Logrotate auch mit Docker-Containern?
Ja, allerdings sollten Sie zuerst die eingebaute Rotation des Docker-Daemons konfigurieren, um doppelte Rotation und unnötigen CPU-Verbrauch zu vermeiden.
Kann ich Logrotate mit Syslog kombinieren?
Ja, Logrotate und Syslog ergänzen sich: Syslog sammelt und verteilt Ereignisse, Logrotate kümmert sich um Rotation und Aufbewahrung der resultierenden Dateien.
Was ich aus der Praxis mitnehme
Logrotate ist ein unscheinbares, aber unverzichtbares Werkzeug für jeden, der einen Webserver betreibt. Mit einer sauberen Konfiguration in /etc/logrotate.d/, einem korrekten postrotate-Skript und einer durchdachten Aufbewahrungsstrategie halten Sie Ihre Festplatte frei, Ihre Logs übersichtlich und Ihren Server stabil.
Testen Sie jede Änderung mit dem Debug-Modus, und überwachen Sie die automatische Ausführung regelmäßig. Ich habe zu viele Systeme gesehen, bei denen die Rotation seit Monaten stillschweigend nicht mehr lief – weil eine Datei umbenannt wurde und niemand den Status geprüft hat. Eine einzige Zeile im Monitoring, die die Größe von /var/log überwacht, hätte das jedes Mal verhindert. Richten Sie sie ein, bevor Sie sie brauchen.
Sollten Probleme bei der Rotation auftreten, hilft unser Leitfaden zur Logrotate Konfiguration Fehlerbehebung, um schnell wieder einen reibungslosen Betrieb zu gewährleisten.
Eine effektive Logrotate-Retentionsstrategie ist unerlässlich, um sicherzustellen, dass alte Logs regelmäßig gelöscht werden, aber wichtige Daten für Audits erhalten bleiben.
Zusätzlich zur Rotation ist die Logrotate-Kompression ein wichtiger Schritt, um den Speicherplatzbedarf der archivierten Webserver-Logs zu minimieren.
Pour aller plus loin sur ce sujet, consultez aussi notre article sur postrotate Skript Fehler.
Schon als Kind war ich fasziniert von der Logik hinter Computern und der unendlichen Welt der Daten. Was als spielerische Neugier mit dem Zerlegen alter PCs begann, entwickelte sich schnell zu einer tiefen Leidenschaft für die Informatik. Heute sehe ich es als meine Berufung, komplexe digitale Themen greifbar zu …
Tous les articles de Anna Berger →
