Die Uhrzeit ist die unauffälligste Einstellung eines Servers, bis sie falsch geht. Dann schlagen Dinge fehl, die scheinbar nichts miteinander zu tun haben: TLS-Verbindungen, Zwei-Faktor-Codes, Cluster, Sicherungen. Die Einrichtung dauert zwei Minuten, die Fehlersuche ohne diesen Hinweis Stunden.
Was eine falsche Uhr kaputtmacht#
| Dienst | Was passiert |
|---|---|
| TLS | Zertifikate gelten „noch nicht“ oder „nicht mehr“, Verbindungen scheitern |
| TOTP (Zwei-Faktor-Codes) | Codes werden abgelehnt, weil sie in einem Zeitfenster von 30 Sekunden gelten |
| Proxmox-Cluster, Datenbank-Replikation | Knoten halten sich gegenseitig für fehlerhaft |
| Protokolle | Ereignisse auf zwei Servern lassen sich nicht mehr in Reihenfolge bringen |
| Sicherungen, Timer | laufen zur falschen Zeit oder vergleichen Dateien falsch |
Auf virtuellen Servern kommt ein eigener Grund dazu: Nach einer Live-Migration oder einem angehaltenen Gast kann die Uhr springen. Ohne laufende Synchronisation bleibt sie dann falsch.
Den Zustand prüfen#
timedatectl
Die Ausgabe zeigt drei wichtige Zeilen:
- Time zone: die Zeitzone, zum Beispiel
Etc/UTCoderEurope/Berlin - System clock synchronized: yes: Die Uhr wird tatsächlich abgeglichen
- NTP service: active: Ein Synchronisationsdienst läuft
Steht bei „synchronized“ ein no, ist das der erste Befund.
Die einfache Lösung: systemd-timesyncd#
Auf Debian ist systemd-timesyncd meist schon installiert. Er fragt einen Zeitserver ab und stellt die Uhr nach, mehr nicht. Für einen einzelnen VPS reicht das.
apt install systemd-timesyncd
timedatectl set-ntp true
timedatectl timesync-status
Die Zeitserver stehen in /etc/systemd/timesyncd.conf. Ohne Eintrag nutzt Debian die Server von debian.pool.ntp.org. Viele Anbieter betreiben eigene Zeitserver im Rechenzentrum, die näher und damit genauer sind; die Adresse steht meist in der Dokumentation des Anbieters.
# /etc/systemd/timesyncd.conf.d/server.conf
[Time]
NTP=ntp.dein-anbieter.example
FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org
Die gründliche Lösung: chrony#
chrony gleicht nicht nur ab, sondern misst, wie schnell die Uhr des Rechners läuft, und korrigiert das laufend. Es kommt mit Sprüngen nach Migrationen besser zurecht und kann selbst Zeitserver für andere Maschinen sein.
chrony lohnt sich, wenn du einen Proxmox-Cluster, eine replizierte Datenbank oder mehrere Server betreibst, deren Protokolle zusammenpassen müssen. Proxmox VE setzt seit Version 7 selbst auf chrony.
apt install chrony # ersetzt systemd-timesyncd
systemctl status chrony
chronyc tracking # Abweichung und Qualität
chronyc sources -v # abgefragte Server und ihr Zustand
In chronyc tracking ist die Zeile System time die interessante: Sie zeigt, wie weit die Uhr gerade von der Referenz entfernt ist. Auf einem gesunden Server liegt der Wert im Bereich von Millisekunden oder darunter.
Eigene Server trägst du in /etc/chrony/sources.d/ ein:
# /etc/chrony/sources.d/anbieter.sources
server ntp.dein-anbieter.example iburst
chronyc reload sources
Laufen timesyncd und chrony parallel, stellen beide an der Uhr und arbeiten gegeneinander. Das Paket chrony entfernt timesyncd bei der Installation. Prüfe trotzdem mit systemctl is-active systemd-timesyncd chrony, dass nur einer aktiv ist.
Zeitzone: UTC oder Ortszeit?#
timedatectl set-timezone Etc/UTC # oder
timedatectl set-timezone Europe/Berlin
Die Uhr selbst läuft intern immer in UTC; die Zeitzone ändert nur die Anzeige. Für Server spricht einiges für UTC: keine Sprünge bei der Zeitumstellung, gleiche Zeitstempel auf allen Servern, egal wo sie stehen. Timer, die „um 02:30“ laufen sollen, laufen in der Nacht der Umstellung mit Ortszeit entweder doppelt oder gar nicht.
Wer lieber Ortszeit liest: journalctl rechnet für die Anzeige um, wenn deine Sitzung eine andere Zeitzone hat (TZ=Europe/Berlin journalctl …).
Die Firewall nicht vergessen#
Zeitabfragen laufen über UDP-Port 123 ausgehend. Wer ausgehenden Verkehr begrenzt, und das ist eine gute Idee, siehe Firewall auf dem VPS, muss NTP ausdrücklich erlauben. Sonst läuft die Synchronisation still ins Leere, und timedatectl zeigt irgendwann synchronized: no.
Häufige Fragen#
Die Uhr geht um Stunden falsch. Springt sie jetzt sofort?#
timesyncd stellt große Abweichungen beim Start direkt um. chrony tut das standardmäßig nur in den ersten Messungen (makestep in der Konfiguration), danach korrigiert es langsam, damit laufende Dienste keinen Zeitsprung sehen. Bei großer Abweichung hilft einmalig chronyc makestep.
Braucht ein Container eine eigene Zeitsynchronisation?#
Nein. Container nutzen die Uhr des Hosts. Die Synchronisation gehört auf den Host, bei LXC also auf den Proxmox-Knoten.
Und virtuelle Maschinen?#
Ja, jede VM hat ihre eigene Uhr und braucht eine eigene Synchronisation.
Wie prüfe ich die Uhr von außen?#
date -u auf dem Server mit einer verlässlichen Quelle vergleichen, etwa curl -sI https://www.debian.org | grep -i ^date. Der Date-Kopf der Antwort ist die Uhrzeit des Webservers in UTC.
Kurz gesagt#
timedatectlzeigt, ob die Uhr synchronisiert wird.- Für einen einzelnen VPS reicht
systemd-timesyncd. - Für Cluster, Replikation und mehrere Server:
chrony. - UTC auf Servern vermeidet Sprünge bei der Zeitumstellung.
- Ausgehend UDP 123 erlauben, sonst läuft die Synchronisation ins Leere.
Geschrieben aus dem laufenden Betrieb: MRMedia betreibt eigene Proxmox- Hosts, einen Backup-Server und Kundendienste in der EU. Fehler in einer Anleitung sind Fehler im eigenen Betrieb. Korrekturen bitte über Discord.