Linux systemd-Timers: der bessere cron

Cron ist seit den 1970er-Jahren ein fester Bestandteil jedes Unix-Systems. Doch wer heute moderne Linux-Server administriert — ob Debian 13, Ubuntu 26.04 LTS oder Rocky Linux 10 — hat mit systemd ein deutlich maechtigeres Werkzeug zur Hand. systemd-Timer-Units loesen klassisches cron in vielen Szenarien ab und bringen Funktionen mit, die in Produktionsumgebungen erheblich Zeit und Nerven sparen.

In diesem Beitrag zeigen wir, warum wir bei DATAZONE neue Server konsequent mit Timer-Units ausstatten, welche Vorteile sich daraus ergeben und wie ein praxistauglicher Backup-Timer in der Praxis aussieht.

Warum cron in modernen Umgebungen an Grenzen stoesst

Cron erledigt seinen Job zuverlaessig — solange das System laeuft, der Cron-Daemon aktiv ist und der Job klar definiert ist. In der Praxis stellen sich aber regelmaessig Fragen, die cron nicht oder nur umstaendlich beantwortet:

• Wurde der naechtliche Backup-Job tatsaechlich ausgefuehrt, obwohl der Server zur geplanten Zeit aus war?
• Warum bricht das Skript ab, obwohl es manuell laeuft? (Antwort: ein anderes Environment, kein PATH, kein TTY.)
• Wie verhindere ich, dass 200 Server zur exakt gleichen Sekunde dasselbe Repository pullen?
• Wo finde ich strukturierte Logs des letzten Laufs, inklusive Exit-Code und Dauer?

Cron liefert hier wenig. Die Ausgaben landen per E-Mail an root, sind selten konfiguriert, und ein nicht ausgefuehrter Job hinterlaesst meist keine Spur. systemd-Timer adressieren genau diese Schwaechen.

Aufbau einer Timer-Unit: Service plus Timer

Jeder systemd-Timer besteht aus zwei Dateien: einer Service-Unit, die definiert, was ausgefuehrt wird, und einer Timer-Unit, die definiert, wann. Beide werden ueblicherweise unter /etc/systemd/system/ abgelegt.

Beispiel: ein taeglicher Backup-Job, der ein Verzeichnis nach /srv/backup/ rsynct.

# /etc/systemd/system/datazone-backup.service
[Unit]
Description=DATAZONE Daily Backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/datazone-backup.sh
Nice=10
IOSchedulingClass=best-effort
IOSchedulingPriority=7

Und der dazugehoerige Timer:

# /etc/systemd/system/datazone-backup.timer
[Unit]
Description=Run DATAZONE Backup daily

[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=30min
Persistent=true
Unit=datazone-backup.service

[Install]
WantedBy=timers.target

Aktivieren laesst sich der Timer mit zwei Kommandos:

systemctl daemon-reload
systemctl enable --now datazone-backup.timer

OnCalendar-Syntax: ausdrucksstaerker als Cron

Die OnCalendar=-Direktive verwendet eine eigene, lesbare Syntax. Sie deckt alle cron-Faelle ab und erlaubt zusaetzlich Konstrukte, die in cron umstaendlich oder gar nicht moeglich sind.

Anwendungsfall	OnCalendar-Ausdruck
Jeden Tag um 02:30	*-*-* 02:30:00
Jeden Montag um 06:00	Mon *-*-* 06:00:00
Werktags stuendlich	Mon..Fri *-*-* *:00:00
Erster Tag jedes Monats	*-*-01 03:00:00
Alle 15 Minuten	*-*-* *:00/15:00
Quartalsweise	*-01,04,07,10-01 04:00:00
Letzter Sonntag im Monat	Sun *-*-22..28 05:00:00

Sehr nuetzlich ist systemd-analyze calendar zum Validieren eines Ausdrucks vor dem Deployment:

systemd-analyze calendar "Mon..Fri *-*-* 02:30:00"

Die Ausgabe zeigt die naechste tatsaechliche Ausfuehrungszeit — ein Detail, das bei cron-Eintraegen oft im Kopf abgeschaetzt werden muss.

Vier Vorteile, die in der Praxis zaehlen

1. Persistent=true: nachgeholte Ausfuehrung

Mit Persistent=true merkt sich systemd den letzten Ausfuehrungszeitpunkt unter /var/lib/systemd/timers/. War der Server zur eigentlichen Zeit aus, wird der Job nach dem Booten nachgeholt. Fuer Laptops, virtuelle Maschinen mit Schedules oder Server in Edge-Standorten ist das ein entscheidender Vorteil gegenueber cron — dort waere der Zeitpunkt einfach verpasst.

2. RandomizedDelaySec: keine Lastspitzen

Ein Klassiker im Rechenzentrum: 50 VMs starten um 02:00 Uhr ihren Backup-Job, hauen gleichzeitig auf den Storage-Pool und verursachen einen massiven I/O-Stau. Mit RandomizedDelaySec=30min verteilt systemd die tatsaechliche Startzeit zufaellig auf das angegebene Intervall. Die Last verteilt sich, der Storage atmet auf.

3. Journal-Logging: strukturiert und durchsuchbar

Jeder Timer-Lauf landet automatisch im systemd-journal. Statt manuell Logfiles zu rotieren, fragen Sie die Daten gezielt ab:

journalctl -u datazone-backup.service --since "yesterday"
journalctl -u datazone-backup.service -p err
systemctl status datazone-backup.timer

Sie sehen Exit-Code, Laufzeit, stdout, stderr und Trigger-Ursache in einem konsistenten Format. Fuer zentrales Monitoring laesst sich das Journal nach Loki, Graylog oder Splunk weiterleiten.

4. Abhaengigkeiten und Ressourcensteuerung

Eine Service-Unit kennt After=, Requires=, Wants=, Conflicts=. Ein Backup-Job kann so explizit auf network-online.target oder einen Mount warten. Ueber Nice=, IOSchedulingClass=, MemoryMax= oder CPUQuota= steuern Sie die Ressourcen praezise — alles, was in cron nur ueber Wrapper-Skripte ginge.

list-timers: alle Schedules auf einen Blick

Der vielleicht meistgenutzte Befehl im Alltag ist systemctl list-timers. Er zeigt alle aktiven Timer, den naechsten und letzten Ausfuehrungszeitpunkt sowie die zugehoerige Unit.

NEXT                        LEFT          LAST                        PASSED       UNIT                          ACTIVATES
Thu 2026-06-04 02:30:00 CEST 8h            Wed 2026-06-03 02:31:14 CEST 15h ago      datazone-backup.timer         datazone-backup.service
Thu 2026-06-04 03:10:00 CEST 9h            Wed 2026-06-03 03:10:00 CEST 14h ago      logrotate.timer               logrotate.service
Thu 2026-06-04 06:00:00 CEST 12h           Wed 2026-06-03 06:00:12 CEST 11h ago      apt-daily-upgrade.timer       apt-daily-upgrade.service
Thu 2026-06-04 18:42:31 CEST 1day 1h       Wed 2026-06-03 18:42:31 CEST 23h ago      fstrim.timer                  fstrim.service
Sun 2026-06-08 00:00:00 CEST 4days         Sun 2026-06-01 00:01:55 CEST 2days ago    snapper-cleanup.timer         snapper-cleanup.service

Sortiert nach naechster Ausfuehrung sehen Sie sofort, was wann laeuft. Mit --all kommen auch inaktive Timer dazu. Diese Uebersicht spart bei Uebergaben und Audits viel Zeit — gerade in Umgebungen, in denen ueber Jahre gewachsene cron-Eintraege oft niemand mehr vollstaendig kennt.

Wann cron trotzdem die richtige Wahl ist

Trotz aller Vorteile gibt es Faelle, in denen klassisches cron weiterhin sinnvoll bleibt: einzelne Ad-hoc-Jobs eines Anwenders ueber crontab -e, sehr alte Distributionen ohne vollstaendige systemd-Integration oder Container, in denen kein systemd laeuft. Auch fuer reine User-Tasks ist crontab oft schneller geschrieben. Fuer alles, was zur Server-Konfiguration gehoert, ist der Timer aber die robustere Wahl.

DATAZONE: Automatisierung sauber aufgesetzt

Wer einen Linux-Stack betreibt — ob als Hypervisor unter Proxmox, als NAS mit TrueNAS oder als Backup-Ziel ueber Proxmox Backup Server — profitiert von konsequent dokumentierten Timer-Units statt verstreuter cron-Eintraege. Wir setzen die Automatisierung beim Onboarding direkt sauber auf: Timer-Units, Journal-Logging, Monitoring-Anbindung, Wiederherstellungstests.

DATAZONE unterstuetzt Sie bei der Linux-Automatisierung, beim Bau eigener Timer-Units und beim Aufraeumen historisch gewachsener cron-Landschaften. Wir kommen aus Neuburg an der Donau, betreuen Kunden im gesamten DACH-Raum und beraten herstellerunabhaengig. Sprechen Sie uns an ueber unsere Linux-Beratung oder direkt ueber das Kontaktformular.