- Logrotate rotiert, komprimiert und löscht Logdateien automatisch – das schützt vor vollen Festplatten und erfüllt gleichzeitig die gesetzlichen Aufbewahrungspflichten.
- Die zentrale Konfiguration liegt in /etc/logrotate.conf, individuelle Regeln für Dienste wie Nginx oder MySQL legen Sie in /etc/logrotate.d/ ab.
- Die Anzahl der Archive bestimmen Sie mit der Direktive ‘rotate’ – kombiniert mit ‘weekly’ ergibt ‘rotate 52’ genau ein Jahr Aufbewahrung.
- Ein Trockenlauf mit ‘logrotate -d’ zeigt Ihnen vorab, ob Ihre Konfiguration korrekt ist, ohne dass Dateien verändert werden.
- Vergessen Sie nicht, nach der Rotation ein Signal an den Dienst zu senden (postrotate), sonst schreibt er in die falsche Datei und Logs gehen verloren.
Warum Ihre aktuelle Log-Retention ein Sicherheitsrisiko darstellt
Logdateien sind das Gedächtnis Ihres Servers – sie dokumentieren Zugriffe, Fehler und Sicherheitsvorfälle. Ohne eine durchdachte Aufbewahrungsstrategie (Retention) werden sie jedoch zur Gefahr: Sie füllen die Festplatte, verlangsamen das System und verletzen im schlimmsten Fall die Datenschutz-Grundverordnung (DSGVO).
Kurz gesagt :
- Logrotate rotiert, komprimiert und löscht Logdateien automatisch, um volle Festplatten und DSGVO-Verstöße zu vermeiden.
- Die zentrale Konfiguration liegt in /etc/logrotate.conf, individuelle Regeln in /etc/logrotate.d/, mit Direktiven wie 'rotate 52' für ein Jahr Aufbewahrung.
- Ein Trockenlauf mit 'logrotate -d' prüft die Konfiguration, und 'postrotate' sendet Signale an Dienste, um Logverluste zu verhindern.
- Unbegrenzte Log-Aufbewahrung riskiert Bußgelder bis zu 4 % des Jahresumsatzes, da IP-Adressen als personenbezogene Daten gelten.
In Frankreich überwacht die CNIL die Einhaltung der DSGVO und empfiehlt, personenbezogene Daten – dazu zählen auch IP-Adressen in Logs – nur so lange zu speichern, wie es für den Zweck erforderlich ist. Für Verbindungsdaten gilt häufig eine maximale Dauer von zwölf Monaten. Wer seine Logs unbegrenzt aufbewahrt, riskiert Abmahnungen und Bußgelder, die nach DSGVO bis zu 4 % des weltweiten Jahresumsatzes betragen können.
Ich habe in meiner Laufbahn als Systemarchitekt schon oft erlebt, dass ein Server wegen überquellender Logdateien zusammenbrach – einmal füllte eine fehlerhafte Anwendung innerhalb weniger Stunden 80 GB Logdaten, bis die Platte voll war. Genau dafür wurde Logrotate entwickelt.
Verstehen, was Logrotate ist und wie es funktioniert
Logrotate ist ein Standardwerkzeug auf Linux-Systemen, das Logdateien regelmäßig rotiert, komprimiert und alte Archive löscht – so bleibt die Menge an Logdaten kontrollierbar.
Der Prozess läuft in vier Schritten ab: Zuerst wird die aktuelle Logdatei umbenannt (z. B. in access.log.1), dann wird eine neue leere Datei mit dem ursprünglichen Namen erstellt. Anschließend werden ältere Archive durchnummeriert und je nach Konfiguration komprimiert. Schließlich werden die ältesten Dateien gelöscht, wenn die maximale Anzahl überschritten ist.
Die Grundlagen der Logrotation (daily, weekly, monthly)
Die Frequenz der Rotation legen Sie mit den Direktiven ‘daily’, ‘weekly’ oder ‘monthly’ fest – das ist die Basis jeder Retentionsstrategie.
- daily: Rotation einmal pro Tag – ideal für stark frequentierte Server mit hohem Logaufkommen.
- weekly: Rotation einmal pro Woche – der Standard für die meisten Produktivsysteme.
- monthly: Rotation einmal im Monat – geeignet für Systeme mit geringem Logvolumen.
Warum nicht einfach ein Cron-Skript? Logrotate ist nativ in Linux integriert, robust und verwaltet Berechtigungen korrekt – ein selbstgebautes Skript müsste all das erst nachbilden.
Die zentrale Konfigurationsdatei analysieren (/etc/logrotate.conf)
Die Datei /etc/logrotate.conf enthält die globalen Einstellungen, die für alle Logdateien gelten, sofern sie nicht in den spezifischen Konfigurationen überschrieben werden.
Hier ist die Grundstruktur, die Sie kennen sollten:
- daily / weekly / monthly – bestimmt die Rotationsfrequenz.
- rotate 7 – legt fest, wie viele Archive aufbewahrt werden, bevor das älteste gelöscht wird.
- compress – komprimiert die Archive mit gzip, das spart bis zu 70 % Speicherplatz.
- delaycompress – verschiebt die Komprimierung um einen Zyklus, damit Dienste, die noch schreiben, nicht gestört werden.
- missingok – unterdrückt Fehlermeldungen, wenn die Logdatei nicht existiert.
- notifempty – rotiert nicht, wenn die Logdatei leer ist.
- create 0640 www-data adm – erstellt nach der Rotation eine neue Datei mit den angegebenen Rechten und Eigentümern.
Diese Direktiven sind das Fundament – mit ihnen bauen Sie jede Retentionsstrategie.
Die Retentionsstrategie nach Ihren Bedürfnissen definieren
Die optimale Aufbewahrungsdauer hängt von Ihren betrieblichen Anforderungen und den gesetzlichen Vorgaben ab – in Frankreich ist besonders die CNIL-Richtlinie zu beachten.
Für die meisten Server in Produktion empfehle ich eine Aufbewahrung von 3 bis 12 Monaten. Das deckt sowohl die Diagnose von Problemen ab als auch die Anforderungen der DSGVO, die eine Speicherung personenbezogener Daten nur so lange erlaubt, wie es für den Zweck erforderlich ist.
Welche Daten, wie lange aufbewahren? (Die rechtliche Frage in Frankreich)
Die CNIL empfiehlt für Verbindungsdaten eine maximale Speicherdauer von zwölf Monaten – länger dürfen Sie Logs nur speichern, wenn eine gesetzliche Ausnahme vorliegt.
Prüfen Sie, welche Logs personenbezogene Daten enthalten: IP-Adressen, User-Agent-Strings oder Benutzernamen fallen darunter. Für reine Systemlogs wie Kerneldaten gilt diese Einschränkung nicht, aber Vorsicht ist besser als Nachsicht.
Die “Rotate”-Direktive anpassen (Anzahl der Archive)
Die Anzahl der Archive berechnen Sie einfach: Multiplizieren Sie die Rotationsfrequenz mit der gewünschten Aufbewahrungsdauer.
- rotate 12 mit weekly = 12 Wochen ≈ 3 Monate Aufbewahrung.
- rotate 52 mit weekly = 52 Wochen = 1 Jahr Aufbewahrung.
- rotate 90 mit daily = 90 Tage ≈ 3 Monate.
In meinen Projekten hat sich ‘rotate 8’ mit ‘weekly’ als guter Kompromiss erwiesen – etwa zwei Monate Daten, ohne dass die Platte überläuft.
Konkrete Beispiele für gängige Server-Dienste (Nginx, Apache, MySQL)
Jeder Dienst hat eigene Anforderungen – ich zeige Ihnen die gängigsten Konfigurationen für Nginx, Apache und MySQL, die Sie direkt übernehmen können.
Beispiel für Nginx (Webserver)
Nginx schreibt Logs in /var/log/nginx/, und nach der Rotation muss das Signal USR1 gesendet werden, damit der Prozess die neue Datei öffnet.
/var/log/nginx/*.log { daily rotate 14 compress delaycompress missingok notifempty create 0640 www-data adm sharedscripts postrotate [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid` endscript
}Diese Konfiguration rotiert täglich und behält 14 Archive – das entspricht zwei Wochen. Die Datei ‘postrotate’ ist entscheidend: Ohne das Signal schreibt Nginx weiter in die umbenannte Datei, und Sie verlieren alle neuen Einträge.
Beispiel für MySQL/MariaDB (Datenbank)
Bei MySQL müssen Sie vor der Rotation alle Logs leeren, sonst bleiben die Dateien offen und es kommt zu Inkonsistenzen.
/var/log/mysql/mysql.log { weekly rotate 4 compress missingok notifempty create 0640 mysql adm postrotate mysqladmin flush-logs endscript
}Der Befehl ‘mysqladmin flush-logs’ schließt die aktuelle Logdatei und öffnet eine neue – genau das, was für eine saubere Rotation nötig ist.
Die Rotation testen und überwachen (Trockenlauf)
Bevor Sie die Konfiguration in Produktion übernehmen, testen Sie sie mit einem Trockenlauf – so vermeiden Sie böse Überraschungen.
- sudo logrotate -d /etc/logrotate.conf – zeigt, was passieren würde, ohne Dateien zu verändern.
- cat /var/lib/logrotate/status – zeigt den aktuellen Status aller Rotationen.
- sudo logrotate -f /etc/logrotate.conf – erzwingt eine Rotation sofort, nützlich zum Testen.
Ich empfehle, nach der ersten Rotation die Logdateien zu prüfen: Stimmen die Zeitstempel? Sind die Berechtigungen korrekt? Nur so stellen Sie sicher, dass alles reibungslos läuft.
Die Logs der Rotation selbst überwachen (Logwatch, journalctl)
Überwachen Sie die Rotation selbst, indem Sie die Logs von Logrotate auswerten – zum Beispiel mit Logwatch oder journalctl.
Logrotate schreibt seine eigenen Meldungen normalerweise nach /var/log/logrotate.log oder in den systemd-Journal. Richten Sie einen Cron-Job ein, der diese Datei auf Fehler prüft, und lassen Sie sich bei Problemen per E-Mail benachrichtigen.
Häufige Fehler, die Sie unbedingt vermeiden sollten
Aus meiner Beratungspraxis kenne ich vier Fehler, die immer wieder auftreten und zu Datenverlust oder Sicherheitslücken führen.
Fehler 1: Die Rotation zu selten planen (nur monatlich)
Eine monatliche Rotation führt bei stark frequentierten Servern schnell zu riesigen Logdateien, die den Speicherplatz sprengen.
Prüfen Sie das Logvolumen Ihrer Dienste und wählen Sie die Frequenz entsprechend. Ein Nginx-Server mit hohem Traffic sollte täglich rotieren, nicht monatlich.
Fehler 2: Das Postrotate-Skript vergessen (Signal an den Dienst)
Ohne das Signal an den Dienst nach der Rotation schreibt dieser weiter in die alte Datei – alle neuen Logeinträge landen im falschen Archiv und gehen verloren.
Das passiert besonders häufig bei Diensten, die ihre Logdatei nicht automatisch neu öffnen. Lesen Sie die Dokumentation Ihres Dienstes und fügen Sie das richtige Signal hinzu.
Fehler 3: Die Rechte der Logdateien nicht überprüfen (Sicherheitslücke)
Wenn die neue Logdatei nach der Rotation mit falschen Berechtigungen erstellt wird, können Angreifer möglicherweise sensible Daten lesen oder Logs manipulieren.
Verwenden Sie die ‘create’-Direktive mit den korrekten Benutzer- und Gruppenrechten, und prüfen Sie, dass nur autorisierte Prozesse Zugriff haben.
Fehler 4: Die DSGVO-Konformität ignorieren (Logs zu lange speichern)
In Frankreich kann die unbegrenzte Speicherung von personenbezogenen Logdaten zu Bußgeldern führen – die CNIL verlangt eine klare Aufbewahrungsfrist.
Definieren Sie eine maximale Aufbewahrungsdauer von zwölf Monaten und setzen Sie sie konsequent mit Logrotate um. Das schützt Sie rechtlich und spart Speicherplatz.
Häufig gestellte Fragen (FAQ)
Was passiert, wenn ich ‘rotate 0’ setze?
Bei ‘rotate 0’ wird die Logdatei nach der Rotation sofort gelöscht – es wird kein Archiv angelegt.
Das ist nur sinnvoll, wenn Sie Logs überhaupt nicht aufbewahren möchten, was aber in den meisten Fällen keine gute Idee ist.
Kann ich Logrotate für Anwendungen wie Docker verwenden?
Ja, Sie können Logrotate für Docker-Container verwenden, indem Sie die Logdateien auf dem Host mounten oder den json-file-Driver mit Rotationseinstellungen konfigurieren.
Für Docker empfiehlt sich die Verwendung des ‘json-file’-Logging-Drivers mit Optionen wie ‘max-size’ und ‘max-file’, die eine ähnliche Rotation ermöglichen.
Wie kann ich die Logs zentralisieren (z.B. nach Graylog oder ELK)?
Logrotate kann die Logs komprimieren und über rsyslog an einen zentralen Server wie Graylog oder ELK senden.
Konfigurieren Sie rsyslog so, dass es die Logdateien nach der Rotation liest und an die zentrale Instanz weiterleitet – so haben Sie alle Logs an einem Ort.
Was ist der Unterschied zwischen ‘copytruncate’ und ‘create’?
‘copytruncate’ kopiert den Inhalt der Logdatei und leert dann die Originaldatei, während ‘create’ eine neue Datei erstellt und die alte umbenennt.
‘copytruncate’ ist nützlich für Dienste, die ihr Logfile nicht neu öffnen können – es kann jedoch zu Datenverlust kommen, wenn zwischen Kopieren und Leeren geschrieben wird.
So bauen Sie eine robuste Retentionsstrategie auf
Eine effektive Retentionsstrategie basiert auf drei Säulen: der richtigen Rotationsfrequenz, der passenden Anzahl an Archiven und der Beachtung rechtlicher Vorgaben.
Beginnen Sie mit einer Analyse Ihrer aktuellen Logdateien: Wie groß sind sie? Welche Daten enthalten sie? Wie lange müssen Sie sie aufbewahren? Auf dieser Basis konfigurieren Sie Logrotate.
Ich empfehle, die Rotation monatlich zu überprüfen und die Konfiguration an veränderte Bedingungen anzupassen. Testen Sie neue Einstellungen immer zuerst in einer Staging-Umgebung.
Mit einer durchdachten Retentionsstrategie vermeiden Sie Speicherplatzprobleme, erfüllen die DSGVO-Anforderungen und behalten die Kontrolle über Ihre Logdaten – das ist ein wichtiger Baustein für einen robusten Linux-Server.
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 →
