Timekeeping auf Linux-Servern: Chrony/NTP-Konfiguration, RTC-Drift und Virtualisierungsfallen

„Die Zeit stimmt nicht“ klingt banal, ist im Betrieb aber oft der Anfang einer Kettenreaktion: TLS-Zertifikate werden als ungültig bewertet, Kerberos-Logins scheitern, Cluster-Quoren kippen, Backups laufen in falsche Retention-Fenster und Logs lassen sich nicht mehr sauber korrelieren. Timekeeping auf Linux-Servern ist deshalb weniger eine Komfortfrage als eine grundlegende Betriebsdisziplin. Gleichzeitig ist Zeit ein Thema, das in modernen Umgebungen durch Virtualisierung, Cloud-Images, Snapshot/Restore-Workflows und heterogene Hardware schneller entgleist als früher.

Dieser Beitrag verbindet Praxiswissen zu Chrony/NTP-Konfiguration, zur Rolle der RTC (Real-Time Clock, also die Hardware-Uhr) und zu typischen Virtualisierungsfallen. Ziel ist ein Setup, das in Normalbetrieb stabil ist, Abweichungen früh erkennt und bei Störungen (z. B. nach Resume, Snapshot-Restore oder Host-Migration) kontrolliert reagiert – ohne „Zeit-Sprünge“ als verstecktes Risiko in die Plattform zu tragen.

Timekeeping auf Linux-Servern: Warum korrekte Zeit im Betrieb kritisch ist

Viele Komponenten verlassen sich auf eine monotone, plausible Systemzeit:

• TLS und Zertifikatsprüfungen: Ist die Uhr zu weit in der Zukunft oder Vergangenheit, schlagen Handshakes fehl (Client und Server bewerten „not before/not after“).
• Kerberos/SSO: Ticket-Gültigkeiten tolerieren nur kleine Abweichungen. Zeitdrift wirkt wie ein Authentifizierungsfehler.
• Logs, SIEM, Incident Response: Zeitstempel sind das Rückgrat der Korrelation. Drift macht Root-Cause-Analysen unnötig schwer.
• Datenbanken und Replikation: Timeouts, TTLs, Audit-Trails und geplante Jobs hängen an konsistenter Zeit.
• Scheduler, Cron, systemd-timers: Sprünge können Jobs doppelt ausführen oder auslassen.

Wichtig ist die Unterscheidung zwischen „Zeit stellen“ (Wall clock) und „Zeit messen“ (monotone Zeit). Linux nutzt monotone Zeitquellen für viele Messungen, aber Protokolle, Zertifikate und Logs hängen an der Wall clock. Genau hier wirken sich Sprünge und Drift aus.

Grundlagen: Systemuhr, RTC und Zeitquellen sauber unterscheiden

Auf klassischen Servern existieren mindestens zwei Uhren:

• Systemuhr (Kernel Clock): läuft im RAM und startet beim Booten. Diese Uhr wird von NTP/Chrony laufend korrigiert.
• RTC (Real-Time Clock): eine batteriegepufferte Hardware-Uhr auf dem Mainboard. Sie ist beim Booten die erste Referenz, bevor Netzwerkzeit verfügbar ist.

Die RTC ist berüchtigt für Drift (Abweichung pro Zeit), weil sie oft ein günstiger Quarz ist, Temperatur und Alterung eine Rolle spielen und Server nicht immer in idealen Umgebungen stehen. Drift ist normal – entscheidend ist, wie Sie damit umgehen.

Ein weiterer Begriff ist Stratum: Das ist die „Entfernung“ zur Referenzzeit. Stratum-1-Server hängen direkt an einer Referenz (z. B. GNSS, Funkuhr, PTP/PHC), Stratum-2 beziehen Zeit von Stratum-1 usw. Im Unternehmensbetrieb sind Stratum-2/3 üblich und völlig ausreichend, solange Redundanz und Monitoring stimmen.

Chrony vs. klassisches NTP und systemd-timesyncd: Was passt im Serverbetrieb?

Im Linux-Umfeld begegnen Ihnen typischerweise drei Varianten:

• chronyd (Chrony): moderner NTP-Client/Server, robust bei wechselnder Konnektivität, schnell beim Einregeln und praxistauglich in VMs. Chrony ist in vielen Distributionen Standard.
• ntpd (klassischer NTP-Daemon): solide, aber in vielen Umgebungen zunehmend durch Chrony ersetzt. Funktioniert weiterhin, ist aber oft weniger flexibel bei „nicht idealen“ Bedingungen.
• systemd-timesyncd: einfacher SNTP-Client (vereinfachtes NTP). Für Desktops oder sehr einfache Server-Setups okay, aber im professionellen Betrieb fehlen häufig Diagnose- und Serverfunktionen.

Für Administratoren ist Chrony meist die pragmatische Wahl: gute Status- und Debug-Kommandos, kontrolliertes „Slewing“ (schrittweise Korrektur) und klare Konfigurationsoptionen für Virtualisierungsszenarien.

Bestandsaufnahme: Ist Zeitsynchronisation aktiv und stabil?

Bevor Sie umkonfigurieren: Zustand aufnehmen, damit Sie später vergleichen können.

1) Basisprüfung mit timedatectl

timedatectl status

Achten Sie insbesondere auf:

• System clock synchronized: zeigt, ob der Zeitdienst eine Synchronisation meldet.
• NTP service: welcher Dienst aktiv ist (chronyd, systemd-timesyncd oder anderes).
• RTC in local TZ: sollte in Serverumgebungen typischerweise no sein (RTC in UTC).

2) Chrony-Status: Quellen und Abweichung

chronyc tracking
chronyc sources -v
chronyc sourcestats -v

Interpretation (kurz und praxisnah):

• System time / Last offset: aktuelle Abweichung zur ausgewählten Quelle.
• RMS offset: „typische“ Abweichung, gut für Trendbewertung.
• Frequency: wie stark die lokale Uhr korrigiert werden muss (ppm). Auffällig hohe Werte können auf instabile Taktquelle oder Virtualisierungsprobleme hinweisen.
• sources: zeigt erreichbare Server, Stratum, Delay/Jitter. Wichtig ist Redundanz: mehrere Quellen sollten stabil erreichbar sein.

3) Logs: Sprünge und Resync-Ereignisse finden

journalctl -u chronyd --since "-7 days" | tail -n 200

Suche nach Hinweisen wie „stepped“, „makestep“, „reset“, „time jump“. Wiederkehrende Sprünge sind ein Warnsignal, weil sie Timer, Datenbanken und Security-Mechanismen beeinflussen können.

Chrony konfigurieren: stabile Quellen, saubere Korrekturstrategie

Ein belastbares Setup beginnt mit einer klaren Quellenstrategie. In Unternehmensnetzen sind typische Optionen:

• interne NTP-Server (empfohlen): zentral kontrollierbar, Firewall-freundlich, konsistente Policy.
• öffentliche Pools (nur wenn zulässig): z. B. vendor- oder pool-basierte Quellen, aber mit Policy- und Compliance-Prüfung.
• lokale Referenz (Fallback): z. B. eine „local“ Quelle als letzte Instanz – mit großer Vorsicht, damit Sie nicht versehentlich „falsche Zeit“ im Netz verteilen.

Beispiel: Chrony als Client mit internen Zeitquellen

Pfad und Details variieren je nach Distribution (häufig /etc/chrony/chrony.conf oder /etc/chrony.conf). Das folgende Beispiel zeigt ein typisches Pattern: mehrere Quellen, kontrolliertes Step-Verhalten beim Boot, stabile Drift-Statistik.

# /etc/chrony/chrony.conf (Beispiel)

# Mehrere, voneinander unabhängige NTP-Server (idealerweise unterschiedliche Hosts/Standorte)
server ntp1.example.net iburst
server ntp2.example.net iburst
server ntp3.example.net iburst

# Drift-Datei: Chrony lernt die Frequenzabweichung Ihrer Hardware/VM
# (Pfad je nach Distribution)
driftfile /var/lib/chrony/chrony.drift

# Schnelles Einregeln nach Boot: bei großen Abweichungen wenige Male „step“ erlauben,
# danach nur noch slewing (schrittweise) korrigieren.
makestep 1.0 3

# RTC beim Stop/Start aktualisieren, damit Boot-Zeit plausibler ist
rtcsync

# Optional: Wenn der Host nur selten Netz hat, kann eine Offline-Strategie sinnvoll sein
# (hier nicht aktiviert)
# offline

# Logging sparsam, aber ausreichend für Troubleshooting
logdir /var/log/chrony
# log measurements statistics tracking

Warum diese Parameter? „iburst“ beschleunigt die initiale Messung nach dem Start. „makestep“ erlaubt wenige harte Sprünge am Anfang, um schnell in einen plausiblen Bereich zu kommen. Danach vermeiden Sie Steps, weil sie im laufenden Betrieb Nebenwirkungen haben. „rtcsync“ sorgt dafür, dass die RTC regelmäßig die korrigierte Zeit bekommt, was Boot-Phasen stabilisiert – ohne die RTC als primäre Wahrheit zu idealisieren.

Chrony neu starten und validieren

systemctl enable --now chronyd
systemctl restart chronyd
chronyc tracking
chronyc sources -v

Nach der Umstellung sollte die Synchronisation innerhalb kurzer Zeit stabil werden. Wenn nicht, sind meist Netzwerkpfade (UDP/123), DNS, Firewall-Regeln oder Time-Source-Probleme die Ursache.

RTC-Drift verstehen und beherrschen: UTC, hwclock und typische Fehlerbilder

Viele Zeitprobleme beginnen nicht im NTP, sondern beim Boot: Wenn die RTC deutlich danebenliegt, startet das System mit falscher Zeit. Dienste, die sehr früh laufen (z. B. Logging, frühe Security-Checks, manche Agenten), schreiben dann „falsche“ Zeitstempel, bevor NTP korrigiert.

RTC in UTC betreiben (Standard im Serverbetrieb)

Die saubere Linie ist: RTC in UTC, Zeitzone in Linux per tzdata/Zoneinfo. „RTC in local TZ“ führt gerade bei DST (Sommer-/Winterzeit) und Dual-Boot-Szenarien zu unnötigen Sonderfällen.

timedatectl set-timezone Europe/Berlin
timedatectl set-local-rtc 0

Die Zeitzone ist eine Darstellungsschicht. Für Protokolle, Cluster und verteilte Systeme zählt UTC als gemeinsame Basis.

RTC-Zustand prüfen und Drift sichtbar machen

hwclock --verbose
hwclock --show
date -u

Wenn RTC und Systemzeit deutlich auseinanderlaufen, klären Sie zuerst: Ist NTP/Chrony korrekt? Ist die RTC überhaupt persistent (Batterie/UEFI-Einstellungen)? Bei VMs ist „RTC“ oft virtuell und hängt am Hypervisor-Timing.

Wann „rtcsync“ hilft – und wann nicht

„rtcsync“ (in Chrony) synchronisiert die RTC periodisch aus der Systemzeit. Das hilft, wenn die RTC nur moderat driftet. Wenn die RTC aber extrem instabil ist (Batterie leer, defekte Hardware, aggressive Virtualisierungszeit), dann schreiben Sie mit „rtcsync“ zwar „korrekte“ Werte hinein, aber Sie lösen die Ursache nicht. Dann ist Monitoring und ggf. Hardware-/Host-Fix nötig.

Virtualisierungsfallen: Zeitdrift, TSC-Probleme, Snapshot/Restore und Live-Migration

In VMs kommt eine zusätzliche Ebene dazu: Der Gast sieht eine virtuelle Uhr, die vom Hypervisor beeinflusst wird. Typische Ursachen für Drift und Sprünge:

• Host-Overcommit und CPU-Steal: Wenn vCPUs nicht regelmäßig laufen, „verpasst“ die VM Zeitintervalle.
• Pause/Resume, Suspend: Die VM war angehalten, die Wall clock springt beim Resume.
• Snapshots/Restore: Ein Restore kann die VM in eine „Vergangenheit“ zurücksetzen – Zeitstempel, Zertifikate und Logs wirken dann inkonsistent.
• Live-Migration: Je nach Plattform können Taktquelle und Timer-Emulation wechseln.

Ein wichtiger Begriff ist TSC (Time Stamp Counter): ein CPU-Zähler, der als Zeitbasis dienen kann. In Virtualisierung wird TSC emuliert oder „stabil“ durchgereicht. Wenn TSC nicht stabil ist oder sich beim Migrieren ändert, sieht der Gast Zeit „ruckeln“.

Goldene Regel: Nur eine Instanz darf „hart“ Zeit stellen

Viele Hypervisor bieten „Guest Tools“, die Zeit im Gast aktiv korrigieren (teilweise mit harten Steps). Gleichzeitig läuft im Gast Chrony/NTP. Wenn beide eingreifen, bekommen Sie ein schwer reproduzierbares Mischverhalten: Chrony beobachtet Sprünge, bewertet Quellen als unzuverlässig oder regelt ständig gegen.

Praxisempfehlung:

• In VMs: Chrony als primärer Zeitdienst im Gast nutzen.
• Hypervisor-Zeit-Sync nur dann aktiv, wenn es dafür eine klare Policy gibt (z. B. nur initial beim Boot) und sie nicht mit Chrony konkurriert.

Wie genau Sie das konfigurieren, hängt von VMware, Hyper-V, KVM/QEMU, Proxmox oder Cloud-Hypervisoren ab. Entscheidend ist das Prinzip: keine konkurrierenden „Zeitsteller“.

Nach Snapshot/Restore: kontrolliert prüfen, bevor Anwendungen starten

Ein Restore aus einem Snapshot ist im Kern ein „Zeitsprung“. Wenn die VM in die Vergangenheit springt, können folgende Effekte auftreten:

• Zertifikate erscheinen „noch nicht gültig“ oder bereits abgelaufen (je nach Richtung).
• Journald/Logrotation erzeugt Lücken oder doppelte Zeitbereiche.
• Token-basierte Authentifizierung (OIDC, Kerberos) bricht.

Operational hilfreich ist ein fester Prüfpunkt im Runbook: Nach Restore zuerst Zeitdienst stabilisieren, dann Anwendungen starten. Wenn Sie systemd nutzen, können Sie Abhängigkeiten über „network-online.target“ und Service-Startreihenfolgen abbilden. Wichtig ist die Idee, nicht zwingend ein konkretes Unit-Design.

Troubleshooting-Playbook: Wenn Zeit driftet oder springt

Für den Alltag ist eine reproduzierbare Prüfsequenz wichtiger als „die perfekte“ Theorie. Das folgende Playbook ist so aufgebaut, dass Sie schnell zwischen Netzwerk, Konfiguration, Hypervisor und Hardware unterscheiden können.

Schritt 1: Ist überhaupt ein Zeitdienst aktiv?

timedatectl status
systemctl list-unit-files | grep -E "chrony|ntp|timesync"
systemctl status chronyd --no-pager

Wenn mehrere Dienste aktiv sind (z. B. chronyd und systemd-timesyncd), entscheiden Sie sich bewusst für einen und deaktivieren den anderen, um „Doppelkorrigieren“ zu verhindern.

Schritt 2: Erreichen Sie die NTP-Quellen?

NTP nutzt in der Regel UDP Port 123. Firewalls und Security-Gruppen sind ein häufiger Grund für „unsynchronisiert“.

chronyc sources -v
chronyc activity
ss -anu | grep ":123" || true

Wenn Quellen als unreachable erscheinen: DNS prüfen, Routing/Firewall prüfen, und sicherstellen, dass die Quelle wirklich NTP spricht (nicht SNTP-only hinter einem Load Balancer ohne UDP-Stabilität).

Schritt 3: Große Abweichung nach Boot oder Restore?

Wenn Systeme mit großer Abweichung starten, können Services in den ersten Minuten falsche Zeitstempel schreiben. Prüfen Sie RTC und Chrony-Policy („makestep“). Für einmalige Korrektur kann ein Step sinnvoll sein, aber nicht als Dauerzustand.

chronyc tracking
hwclock --show
journalctl -u chronyd --since "-24 hours" | grep -Ei "step|jump|makestep|reset"

Schritt 4: VM-spezifische Indikatoren

Wenn die Drift vor allem unter Last auftritt, ist CPU-Steal/Overcommit ein Kandidat. Sie sehen dann oft „spikes“ in Offsets, nicht nur einen konstanten Drift.

uptime
vmstat 1 5
chronyc sourcestats -v

Interpretation: Hohe Run-Queue, schwankende Werte und unruhige Jitter/Delay-Muster deuten auf Scheduling-Probleme. In solchen Fällen löst „mehr NTP“ das Problem nicht; Sie brauchen Ressourcen- oder Host-Fixes.

Best Practices für Cloud- und Hybrid-Umgebungen

In Cloud- und Hybrid-Setups treffen zusätzliche Randbedingungen aufeinander: Images werden geklont, Instanzen schlafen ein, Netzwerkpfade ändern sich, und es gibt oft provider-spezifische Zeitservices. Praktische Regeln:

• Mehrere Zeitquellen: mindestens drei, idealerweise aus unterschiedlichen Failure-Domains (z. B. zwei interne, eine externe oder ein provider-naher Dienst – je nach Policy).
• Monitoring statt Bauchgefühl: Offsets, Jitter, Reachability und „unsynchronized“-Zustände gehören in Ihr Monitoring.
• Kein Step im Normalbetrieb: Steps nur kontrolliert (Boot/Initialisierung) oder im Störungsfall nach Runbook.
• Immutable Images berücksichtigen: Drift-Dateien und Persistenzpfade (z. B. /var/lib/chrony) müssen in Image-Strategien eingeplant werden, sonst „lernt“ Chrony nie und verhält sich nach jedem Neustart wie frisch installiert.

Monitoring-Checkliste: Was Sie wirklich alarmieren sollten

Nicht jede Abweichung ist ein Incident. Sinnvolle Alarmkriterien sind eher Zustände und Trends:

• chronyd nicht aktiv oder „System clock synchronized: no“ über längere Zeit.
• Keine erreichbaren Quellen (Reachability bricht weg).
• Offset über Schwellwert über X Minuten (Schwellwert je nach Anwendung, z. B. strenger für Kerberos).
• Häufige Steps/Jumps in Logs (Hinweis auf konkurrierende Zeitsteller oder VM-Probleme).

Für interne Links in Ihrem Magazin bietet sich hier typischerweise eine Verknüpfung zu Monitoring-Runbooks (Metriken, Alerts, Eskalation) an, damit Zeit nicht nur „konfiguriert“, sondern auch „betrieben“ wird.

Rückfallstrategie: Was tun, wenn die Zeit „kaputt“ ist?

Die heikelste Situation ist eine massiv falsche Zeit in produktionsnahen Systemen. Ein unkontrollierter Sprung kann mehr Schaden anrichten als eine langsame Korrektur. Eine praxistaugliche Rückfallstrategie umfasst drei Elemente: Eindämmung, Korrektur, Validierung.

1) Eindämmung: Wirkung begrenzen

• Wenn möglich: betroffene Instanz aus dem Load Balancer nehmen oder Dienste in „read-only“/Wartungsmodus setzen.
• Verhindern, dass die Instanz falsche Zeit an andere verteilt (falls sie selbst NTP-Server ist: NTP-Serving temporär deaktivieren).

2) Korrektur: kontrolliert statt hektisch

Wenn die Abweichung klein bis mittel ist, bevorzugen Sie Slewing (schrittweise Korrektur). Bei sehr großen Abweichungen ist ein Step manchmal unvermeidbar – dann aber planvoll: Anwendungen berücksichtigen, Token/SSO neu bewerten, Log-Konsistenz einplanen.

Ein verbreiteter Weg ist, Chrony die Arbeit machen zu lassen und nur das Step-Verhalten für den Störungsfall temporär zu erlauben. Ändern Sie Policies nicht dauerhaft „auf Verdacht“.

3) Validierung: Was muss nach einem Zeiteingriff geprüft werden?

• Auth: Kerberos/SSO, API-Token, Service-Accounts.
• TLS: kritische Endpunkte mit Zertifikaten testen, insbesondere mTLS-Strecken.
• Scheduler: Cron/systemd-timers auf doppelte Ausführung prüfen, ggf. Job-Runbooks anwenden.
• Logs: Zeitfenster markieren, damit Incident Response die Anomalie korrekt einordnet.

Häufige Stolperfallen aus dem Alltag (und wie Sie sie vermeiden)

Stolperfalle 1: „RTC in local TZ“ und DST-Chaos

Wenn RTC lokalzeitbasiert ist, verschieben sich Zeitstempel beim DST-Wechsel und Boot-Reihenfolgen werden schwer erklärbar. Lösung: RTC in UTC, Zeitzone nur als Darstellung.

Stolperfalle 2: Eine einzige Zeitquelle

Ein einzelner NTP-Server ist ein Single Point of Failure. Selbst wenn er stabil wirkt: Wartung, DNS-Probleme oder Routing-Änderungen reichen für Drift. Lösung: mindestens drei Quellen.

Stolperfalle 3: Konkurrierende Zeit-Synchronisation in VMs

Hypervisor-Tools stellen Zeit, Chrony stellt Zeit, und beides greift mit unterschiedlichen Strategien ein. Lösung: klare Owner-Entscheidung, dokumentiert im Plattform-Standard.

Stolperfalle 4: Snapshots als „sicherer Zustand“ missverstanden

Snapshots sind kein konsistenter Zeitanker. Nach Restore ist Zeit plausibilisieren Pflicht. Lösung: Restore-Runbook mit Zeitprüfung vor Applikationsstart.

Fazit: Zeit ist Infrastruktur – und braucht Betriebsdisziplin

Timekeeping auf Linux-Servern ist dann robust, wenn Sie drei Dinge zusammenbringen: saubere Quellen (redundant und erreichbar), eine kontrollierte Korrekturstrategie (Steps nur gezielt) und eine realistische Sicht auf RTC und Virtualisierung (Drift ist normal, Sprünge sind Risiken). Chrony ist dafür ein praxisnahes Werkzeug, aber entscheidend ist das Betriebsmodell: Monitoring, Runbooks für Störungen und klare Regeln für VM-Zeitmechanismen.

Wenn Sie diese Standards in Build-Templates und Betriebsdokumentation verankern, verschwinden Zeitprobleme nicht „magisch“ – aber sie werden selten, schnell diagnostizierbar und vor allem beherrschbar.

Für dieses Thema sind auch Ntp Server Linux und Zeitsynchronisation Linux wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.