Zum Inhalt springen
myvpsguide

Die Uhr des Servers: Zeitsynchronisation, Zeitzone und warum Minuten zählen

Was eine falsche Uhrzeit auf einem Server kaputtmacht, wie du den Zustand prüfst, wann systemd-timesyncd reicht und wann chrony die bessere Wahl ist.

veröffentlicht 19.09.2026
4 min lesezeit
einsteiger

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#

DienstWas passiert
TLSZertifikate 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-ReplikationKnoten halten sich gegenseitig für fehlerhaft
ProtokolleEreignisse auf zwei Servern lassen sich nicht mehr in Reihenfolge bringen
Sicherungen, Timerlaufen 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/UTC oder Europe/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
Nur ein Dienst gleichzeitig

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#

  • timedatectl zeigt, 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.
MRMedia

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.