Eine Zeit für alle: Zeitzone und NTP im Homelab

Wenn eine geplante Aufgabe im Protokoll um 03:00 Uhr auftaucht, will ich nicht erst nachschlagen, ob dieser Host in UTC oder in Mitteleuropäischer Zeit zählt. Im Homelab liefen die Proxmox-Knoten und Windows-Server in Europe/Berlin, während die Firewall, mehrere Linux-VMs und einige LXC-Container auf Etc/UTC standen. Dazu fragte jedes Linux-System eigene öffentliche NTP-Pools ab, obwohl im Netz längst zwei Windows-Domänencontroller als lokale Zeitserver liefen. Vor dem Wechsel auf die Winterzeit habe ich Zeitzonen, Zeitquellen und Nachtläufe im gesamten Bestand vereinheitlicht.

Bestandsaufnahme: gemischte Zeitzonen und getrennte NTP-Wege

Vor der ersten Änderung habe ich alle Systeme im Bestand nur lesend per SSH, pct exec und WinRM abgefragt. Das Bild war typisch für eine gewachsene Umgebung: Die Proxmox-Knoten und ein Teil der Debian-VMs standen auf Europe/Berlin, andere Linux-VMs, die Firewall und mehrere Container liefen auf Etc/UTC. Home Assistant OS meldete Europe/Paris – gleicher Versatz wie Berlin, aber eine andere Kennung. Unter Windows nutzte einer der Domänencontroller Central Europe Standard Time statt W. Europe Standard Time. Beides hat dieselbe Uhrzeit und dieselben Umschalttage, erzeugt aber unnötige Abweichungen in Prüfskripten und lässt sich per Set-TimeZone -Id "W. Europe Standard Time" angleichen.

Bei den LXC-Containern ist die Trennung zwischen Uhr und Zeitzone wichtig: Ein Container hat keinen eigenen Kernel und damit keine eigene Systemuhr. Er übernimmt den Takt des Proxmox-Knotens, auf dem er läuft, und braucht keinen eigenen Zeitdienst. Die Zeitzone liegt dagegen im Dateisystem des Containers unter /etc/localtime und weicht vom Host ab, wenn das Template mit Etc/UTC ausgeliefert wurde.

Die Windows-Domäne als Zeitgeber

In einer Active-Directory-Domäne gibt der Domänencontroller mit der Rolle des PDC-Emulators (hier dc1.example.lan) den Takt an. Alle weiteren Domänencontroller (dc2.example.lan) und Mitgliedsserver folgen ihm über die Domänenhierarchie (NT5DS). Damit die Domäne nicht auf ihrer lokalen Hardware-Uhr (Free-running System Clock) auseinanderläuft, braucht der PDC-Emulator eine verlässliche externe Quelle.

In meinem Aufbau steht der PDC-Emulator auf AnnounceFlags=5 und fragt mit dem Flag 0x8 (Client-Modus) die lokale Firewall unter firewall.example.lan ab. Die Firewall synchronisiert selbst per ntpd mit externen Pool-Servern. So hängt die gesamte Umgebung an einer definierten Wurzel.

# Auf den Windows-DCs die Hierarchie prüfen:
w32tm /monitor
w32tm /query /status

# Von einem Proxmox-Knoten ohne Verstellen der Uhr messen:
chronyd -Q 'server dc1.example.lan iburst' 'server dc2.example.lan iburst' 'server firewall.example.lan iburst'

Auf den Windows-VMs unter Proxmox ist standardmäßig oft noch der VMICTimeProvider aktiv. Unter KVM liefert dieser Anbieter keine Zeit (er greift nur unter Hyper-V), verursacht also keine Zeitsprünge durch den Host.

Für die Linux-Clients gilt eine wichtige Einschränkung bei der Quellenwahl: Trägt man in chrony nur zwei Domänencontroller ein und fällt einer davon aus oder verliert seine Synchronisation, bleibt nur eine Quelle übrig. Bei zwei Quellen kann chrony im Fehlerfall außerdem keinen Mehrheitsentscheid treffen, welche Uhr falsch geht. Deshalb nimmt man die Firewall als dritte Quelle hinzu. Umgekehrt darf die Firewall selbst keinesfalls auf die Domänencontroller zeigen – sonst entsteht eine geschlossene Schleife ohne externe Referenz.

Falle 1: Geplante Aufgaben unter Windows mit festem UTC-Versatz

Der dringendste Befund der Bestandsaufnahme lag nicht bei NTP, sondern in der Windows-Aufgabenplanung. Mehrere eigene Aufgaben auf den Windows-Servern hatten im Trigger den Haken „Über Zeitzonen synchronisieren“ gesetzt. Im XML-Export der Aufgabe erkennt man das am angehängten UTC-Versatz in StartBoundary, während der Sommerzeit also +02:00:

<StartBoundary>2026-10-15T04:30:00+02:00</StartBoundary>

Ist dieser Versatz eingetragen, rechnet Windows den Startzeitpunkt intern fest auf UTC um (hier 02:30 Uhr UTC). Schaltet die Systemuhr Ende Oktober auf Normalzeit (UTC+1) zurück, bleibt die Aufgabe bei 02:30 Uhr UTC – und startet plötzlich eine Stunde früher um 03:30 Uhr Ortszeit. Aufgaben, die eigentlich nach 04:00 Uhr geplant waren, rutschen damit mitten in das Backup-Fenster von 02:00 bis 04:00 Uhr, in dem der Proxmox Backup Server die VMs sichert.

Vor jeder Änderung habe ich die jeweilige Aufgabe per Export-ScheduledTask als XML-Datei gesichert, damit jederzeit ein Rückfall auf den alten Stand möglich ist. Anschließend wird im Trigger nur der Suffix +02:00 aus StartBoundary entfernt und die Aufgabe mit Set-ScheduledTask zurückgeschrieben:

# Sicherung vor der Änderung
Export-ScheduledTask -TaskName "Mein-Wartungsjob" | Out-File "C:\Sicherung\Mein-Wartungsjob.xml"

# Trigger ohne festen UTC-Versatz setzen (läuft immer zur lokalen Uhrzeit)
$t = (Get-ScheduledTask -TaskName "Mein-Wartungsjob").Triggers[0]
$t.StartBoundary = "2026-10-15T04:30:00"
Set-ScheduledTask -TaskName "Mein-Wartungsjob" -Trigger $t

Solange die Aufgaben unter dem Konto SYSTEM laufen, lässt sich das per WinRM ohne erneute Kennworteingabe erledigen.

Linux-Systeme auf die Domänencontroller umstellen

Auf den Proxmox-Knoten und einer Ubuntu-VM läuft chrony. Dort habe ich die öffentlichen Pool-Zeilen in /etc/chrony/chrony.conf auskommentiert (unter Ubuntu liegen die NTS-Pools in /etc/chrony/sources.d/ubuntu-ntp-pools.sources) und eine eigene Datei unter /etc/chrony/sources.d/ angelegt:

# /etc/chrony/sources.d/local-ntp.sources
server dc1.example.lan iburst
server dc2.example.lan iburst
server firewall.example.lan iburst

Im ursprünglichen Plan stand chronyc reload sources, um den Dienst nicht neu starten zu müssen. Der Befehl liest zwar neue Dateien in sources.d/ ein, verwirft aber bereits aktive Pools nicht, die man in chrony.conf auskommentiert hat. Erst ein systemctl restart chrony räumt die alten Pool-Server wirklich ab. Unter Ubuntu gehört die Datei /etc/chrony/sources.d/ubuntu-ntp-pools.sources außerdem keinem Paket direkt als klassische Konfigurationsdatei; ein späteres Paket-Update von chrony kann die Pools wiederherstellen. Nach Updates lohnt sich dort ein Blick auf chronyc sources.

Auf schlankeren Debian-VMs läuft systemd-timesyncd. Dort stehen oft gar keine Pools in der Konfigurationsdatei – die Debian-Pools sind als FallbackNTP einkompiliert und werden ignoriert, sobald man eigene Server per Drop-in hinterlegt:

# /etc/systemd/timesyncd.conf.d/local-ntp.conf
[Time]
NTP=dc1.example.lan dc2.example.lan
FallbackNTP=firewall.example.lan

Nach systemctl restart systemd-timesyncd zeigt timedatectl timesync-status sofort den gewählten Zeitserver. Anders als chrony spricht timesyncd immer nur mit einem Server gleichzeitig. Home Assistant OS lässt sich wegen des schreibgeschützten Dateisystems auf diesem Weg nicht umstellen und übernimmt eigene NTP-Server über die DHCP-Option 042.

Falle 2: Zeitzonenwechsel verschiebt UTC-Crons ins Backup-Fenster

Stellt man ein Linux-System während der Sommerzeit von Etc/UTC auf Europe/Berlin um, ohne die Crontab anzufassen, laufen alle Einträge plötzlich zwei Stunden früher. Ein Backup-Job mit dem Eintrag 0 3 * * * startete unter UTC um 05:00 Uhr Ortszeit – weit nach dem Proxmox-Backup-Fenster. Mit dem Wechsel auf Europe/Berlin bedeutet 0 3 dagegen 03:00 Uhr Ortszeit: mitten während der VM-Sicherung auf den Proxmox Backup Server.

Deshalb gilt für die Umstellung während der Sommerzeit: Jeder Job, der seine bisherige Ortszeit behalten soll, bekommt beim Wechsel von UTC auf Europe/Berlin in der Crontab zwei Stunden aufaddiert (Stunde H wird zu H+2). Um Überraschungen in der Nacht zu vermeiden, erledigt man die Umstellung tagsüber und sichert vorher alle Crontabs sowie die Ausgabe von timedatectl.

# Auf Linux-Systemen:
timedatectl set-timezone Europe/Berlin
systemctl restart cron

# Auf der Firewall (OPNsense) nach der Änderung in der GUI:
configctl cron restart
configctl syslog restart

Auch auf Systemen ohne eigene Einträge in /etc/crontab sollte man systemctl list-timers prüfen: Ein wöchentlicher Dateisystem-Prüfjob wie xfs_scrub_all.timer um 03:10 Uhr lief unter UTC um 05:10 Uhr Ortszeit, nach der Umstellung aber mitten im Backup-Fenster. Ein kurzes Drop-in mit OnCalendar=Sun *-*-* 05:10 hält ihn auf seiner alten Zeit. Der ähnliche Timer e2scrub_all in LXC-Containern läuft ohne LVM ohnehin ins Leere.

Auf Systemen mit eigenen Wartungs- und Sicherungsjobs habe ich Crontab-Anpassung, Zeitzonenwechsel und Cron-Neustart in einem Zug ausgeführt:

System	Aufgabe	Vorher (UTC)	Neu (Europe/Berlin)
git.example.lan	Anwendungs-Backup	0 3 * * *	0 5 * * *
admin.example.lan	Backup-Abholung	40 3 * * *	40 5 * * *
admin.example.lan	Täglicher Konfigurationsabgleich	15 4 * * *	15 6 * * *

Bei GitLab habe ich zunächst nur die Systemzeitzone des Betriebssystems geändert. Die Einstellung gitlab_rails['time_zone'] in der Omnibus-Konfiguration blieb vorerst auf UTC, weil ein anschließendes gitlab-ctl reconfigure den Dienst kurz unterbricht und keinen Einfluss auf den System-Cron hat. Einen Nachzügler gab es in der eigenen Auswertung für den Betriebskalender, die geplante Läufe in einer Datenbank abgleicht: Während entfernte Hosts sauber über timedatectl abgefragt wurden, war für das lokale System noch fest UTC hinterlegt. Erst nachdem auch dort timedatectl abgefragt wurde, stimmte der automatische Soll-Ist-Vergleich der Startzeiten wieder.

Als nächster Schritt steht auf den Domänencontrollern die Verteilung der NTP-Server per DHCP-Option 042 an, damit auch Systeme mit schreibgeschütztem Dateisystem wie Home Assistant OS automatisch die lokalen Zeitserver nutzen. Außerdem kann das tägliche Anwendungs-Backup von 05:00 Uhr auf 04:30 Uhr vorrücken, weil die nächtliche VM-Sicherung auf den Proxmox Backup Server regelmäßig schon vor 03:30 Uhr durch ist.