Зсув часу в Proxmox: проблеми NTP, що ламають TLS/PBS, і як виправити

Чому зсув часу ламає Proxmox, TLS і PBS

Час — це залежність, яку ви не вказуєте в діаграмах архітектури, але вона все одно є залежністю. TLS‑сертифікати
мають вікна «notBefore» і «notAfter». Kerberos, JWT та більшість систем квитків прив’язані до часу. Кластери використовують час
як слабкий сигнал для живучості та порядку подій. Системи резервного копіювання будують політики зберігання і збір сміття,
припускаючи, що «тепер» — монотонно‑схоже.

Proxmox VE базується на Debian. Вузол використовує системні служби (chrony або systemd‑timesyncd, інколи старий ntpd),
апаратний RTC (real‑time clock) і ядрове відлічування часу. PBS суворо ставиться до TLS, і правильно. Тому якщо
годинник вузла відстає — ви бачите «certificate not yet valid». Якщо випереджає — «certificate expired», навіть якщо сертифікат
насправді дійсний.

Як це проявляється на практиці

• Резервні копії PBS не проходять через помилки TLS‑handshake або помилки автентифікації.
• Веб‑інтерфейс Proxmox працює на одному вузлі, але не на іншому, або браузери раптово показують попередження.
• Вузли кластера випадково «втрачають» один одного, показують дивний порядок записів у логах або незрозумілі події corosync.
• ВМ відстають, навіть якщо хост стабільний, тому що гості — це свої маленькі всесвіти з власними звичками.

Якщо ваша інтуїція каже «я просто встановлю час вручну», стримуйтеся. Скачки часу можуть порушити працюючі сервіси таким чином,
що виглядає як корупція. Поступові корекції зазвичай безпечніші, а коли потрібен крок — робіть його навмисно й із контрольованою зоною впливу.

Одна операційна істина варта друку:
перефразована ідея від Werner Vogels (reliability/operations): все ламається; проєктуйте так, щоб воно все одно працювало.
Синхронізація часу — частина цього плану «залишатися працездатним».

Цікаві факти та невелика історія (тому що годинники дивні)

• NTP дуже старий—дуже старий. Він з’явився раніше за більшість сучасних «хмарних» підходів, і досі один із найпоширеніших протоколів у світі.
• Linux тримає час кількома годинниками. Є системний (wall) час, монотонний час і інколи лічильники на базі TSC/HPET — кожен має різні гарантії.
• Віртуалізація ускладнила час. Призупинена ВМ не відчуває часу; час іде в світі. Наздоганяти — нетривіально.
• Кроки високосних секунд реальні й дратівливі. Деякі системи роблять крок, інші «розмазують»; змішані стратегії дають дивні тимчасові розбіжності.
• Дрейф RTC — нормальний. Дешеві генератори коливань гуляють з температурою й віком; кілька секунд на день можуть траплятися на звичайних платах.
• Corosync не «потребує» ідеального часу, але відлагодження кластера без узгоджених часових міток — як хірургія в тумані.
• TLS за своєю суттю чутливий до часу. Це не перебільшення; «notBefore» запобігає повторному відтворенню майбутніх сертифікатів і пом’якшує певні атаки.
• PTP існує тому, що NTP не завжди достатній. Коли потрібна синхронізація підмілісекунди (торгівля, телеком, вимірювання), PTP із апаратною маркуванням пакетів — це рішення.
• Leap smear від Google популяризував ідею, що кроки часу небезпечні на масштабі; багато підприємств скопіювали стратегію без розуміння компромісів.

Жарт №1: Синхронізація часу — єдине місце, де «достатньо близько» і «криптографія» зустрічаються, і вони одразу починають сперечатися.

Швидкий план діагностики

Коли Proxmox/PBS починає кидати помилки TLS, вам потрібен найкоротший шлях до відповіді «це час?» без занурення в тижневу археологію логів.

По-перше: підтвердьте зсув і чи система вважає, що синхронізована

1. Перевірте локальний час проти реального часу (і підтвердьте часовий пояс/режим RTC).
2. Перевірте стан синхронізації NTP (chrony або systemd‑timesyncd).
3. Перевірте, чи час стрибає чи повільно згладжується (великі відхилення зазвичай стрибають, якщо не налаштовано інакше).

По‑друге: визначте джерело часу і чи воно досяжне

1. Який сервіс керує NTP? chrony vs systemd‑timesyncd vs ntpd: оберіть один.
2. Чи досяжні ваші конфігуровані сервери? DNS, фаєрвол, маршрутизація, VLAN ACL.
3. Чи дозволено хосту встановлювати час? Контейнери та деякі жорсткі конфіги можуть це блокувати.

По‑третє: перевірте специфіку віртуалізації

1. Хост стабільний, гості відстають? Тоді ви виправляєте годинники гостей, а не NTP на хості.
2. Після suspend/resume або live migration? Це питання джерела годинника/guest‑agent/політики кроків.
3. Вузли кластера не погоджуються? Вирівняйте час на всіх вузлах перед тим, як торкатися налаштувань corosync.

Правило: не відлагоджуйте TLS, доки не доведете, що час коректний. TLS‑помилки чесні — ваш годинник брешить, а не ваші сертифікати.

Практичні завдання (команди, виводи, рішення)

Ви просили про промисловий рівень. Ось реальні дії, які можна виконати на вузлах Proxmox і PBS. Кожне містить:
команду, приклад виводу, що це означає, і яке рішення прийняти.

Завдання 1: Швидка перевірка здорового глузду: локальний і системний час

cr0x@server:~$ date -Ins
2025-12-26T10:14:32,118962+00:00

Значення: Це системний (wall) час із зсувом часової зони. Якщо це не очевидно «зараз», зупиніться й виправте час перед подальшими діями.

Рішення: Якщо різниця більша за кілька секунд у датацентрі, переходьте до перевірки стану NTP. Якщо відхилення в хвилинах/годинах — очікуйте TLS‑помилок і, мабуть, крокової корекції.

Завдання 2: Підтвердьте, чи система вважає себе синхронізованою

cr0x@server:~$ timedatectl status
               Local time: Fri 2025-12-26 10:14:36 UTC
           Universal time: Fri 2025-12-26 10:14:36 UTC
                 RTC time: Fri 2025-12-26 10:14:35
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Значення: «System clock synchronized: yes» — хороший знак. «RTC in local TZ: no» — розумний дефолт для Linux‑серверів (RTC у UTC).

Рішення: Якщо synchronized: no, не гадіть. Визначте NTP‑клієнта та перевірте досяжність серверів наступним кроком.

Завдання 3: Визначте, хто володіє NTP (chrony vs systemd-timesyncd vs ntpd)

cr0x@server:~$ systemctl is-active chronyd systemd-timesyncd ntp
active
inactive
inactive

Значення: chrony активний; інші — ні. Добре: один сервіс часу.

Рішення: Якщо активних більше одного — виправте це спочатку. Конкуруючі NTP‑клієнти дають джиттер, скачки та операторські страждання.

Завдання 4: Перевірте відстеження chrony (зсув, частота, стан високосності)

cr0x@server:~$ chronyc tracking
Reference ID    : 0A0A0A01 (10.10.10.1)
Stratum         : 3
Ref time (UTC)  : Fri Dec 26 10:14:44 2025
System time     : 0.000123456 seconds fast of NTP time
Last offset     : +0.000081234 seconds
RMS offset      : 0.000210987 seconds
Frequency       : 12.345 ppm fast
Residual freq   : +0.010 ppm
Skew            : 0.120 ppm
Root delay      : 0.002345678 seconds
Root dispersion : 0.001234567 seconds
Leap status     : Normal

Значення: Відхилення малі; chrony прив’язаний до 10.10.10.1. Частота підлаштовується. Це здорово.

Рішення: Якщо «System time» відхиляється на секунди або більше — ймовірно проблема з досяжністю, джерелом або джерелом годинника ядра.

Завдання 5: Перевірте джерела chrony і їх досяжність

cr0x@server:~$ chronyc sources -v
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 10.10.10.1                    2   6   377    18   +0.0001[+0.0001] +/- 0.0008
^+ 10.10.10.2                    2   6   377    17   -0.0002[-0.0002] +/- 0.0012
^- 192.0.2.20                    3   6   377    19   +0.0030[+0.0030] +/- 0.0100

Значення: ^* — вибране джерело, Reach 377 означає успішні відповіді. Reach близько до 0 — ви не зв’язуєтеся з сервером.

Рішення: Якщо всі джерела показують ? або низький reach — одразу усувайте проблеми мережі/DNS/фаєрволу.

Завдання 6: Підтвердьте, що порт NTP (UDP/123) не заблокований

cr0x@server:~$ nc -uvz 10.10.10.1 123
Connection to 10.10.10.1 123 port [udp/ntp] succeeded!

Значення: Це не доводить коректних NTP‑відповідей, але підтверджує базову досяжність UDP/123.

Рішення: Якщо не вдається, не налаштовуйте chrony — виправляйте мережеву політику/маршрутизацію спочатку.

Завдання 7: Виявлення подій кроків та скидів часу в логах

cr0x@server:~$ journalctl -u chronyd -S -2h --no-pager | tail -n 20
Dec 26 09:12:01 server chronyd[821]: Selected source 10.10.10.1
Dec 26 09:12:01 server chronyd[821]: System clock wrong by -3.421 seconds
Dec 26 09:12:01 server chronyd[821]: System clock was stepped by 3.421 seconds
Dec 26 09:12:11 server chronyd[821]: Source 10.10.10.1 online

Значення: chrony зробив крок годинника на 3.421 секунди. Кроки іноді коректні, але часті кроки означають нестабільність.

Рішення: Якщо бачите повторювані кроки — дослідіть призупинення/міграції віртуалізації, поганий RTC або кілька клієнтів часу.

Завдання 8: Перевірте апаратний годинник і режим RTC (UTC vs localtime)

cr0x@server:~$ hwclock --show
2025-12-26 10:14:57.123456+00:00

Значення: RTC близький до системного часу і в UTC.

Рішення: Якщо RTC дуже відрізняється — виправте RTC і забезпечте, щоб Linux використовував UTC. Поганий RTC + перезавантаження = подорож у часі.

Завдання 9: Безпечне одноразове виправлення (chrony)

cr0x@server:~$ chronyc -a makestep
200 OK

Значення: chrony зробив крок годинника, якщо це було потрібно, згідно з політикою.

Рішення: Використовуйте це при великому зсуві, коли потрібно негайно повернути порядок. Потім все одно виправте підлягаючу причину.

Завдання 10: Перевірте, чи TLS‑помилка пов’язана з часом (на боці клієнта PBS)

cr0x@server:~$ proxmox-backup-client status --repository pbs@pam@pbs01:datastore
Error: TLS handshake failed: certificate verify failed: certificate is not yet valid

Значення: «Not yet valid» — неоновий знак для зсуву годинника на клієнті (цей вузол Proxmox) або інколи на сервері (pbs01).

Рішення: Перевірте час на обох кінцях. Виправте час спершу; не перевидавайте сертифікати як першу дію.

Завдання 11: Підтвердьте час на PBS

cr0x@server:~$ ssh pbs01 'timedatectl status'
               Local time: Fri 2025-12-26 10:14:59 UTC
           Universal time: Fri 2025-12-26 10:14:59 UTC
                 RTC time: Fri 2025-12-26 10:15:00
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Значення: PBS синхронізований. Якщо клієнт ні — проблема на боці клієнта.

Рішення: Якщо PBS теж не синхронізований, виправляйте PBS спочатку — ваша ціль резервування має бути «авторитетом часу», а не ще одним дрейфуючим учасником.

Завдання 12: Перевірте здоров’я кластера Proxmox і скорельуйте з проблемами часу

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   27
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Dec 26 10:15:04 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2c
Quorate:          Yes

Значення: Якщо «Date» значно відрізняється між вузлами при виконанні на кожному, у вас є дрейф. Кворум може бути «Yes», але ви живете тимчасовою удачею.

Рішення: Вирівняйте час на всіх вузлах перед подальшим розслідуванням періодичних проблем кластера.

Завдання 13: Виявлення дрейфу гостьової ВМ через QEMU guest agent (якщо встановлено)

cr0x@server:~$ qm agent 104 get-time
{
  "seconds": 1766744105,
  "nanoseconds": 123000000
}

Значення: Ви отримали епохальний час гостя. Порівняйте з часом хоста (date +%s), щоб оцінити зсув.

Рішення: Якщо гості відстають, поки хост стабільний — виправляйте NTP/інструменти всередині гостя і розгляньте ввімкнення стратегії синхронізації через guest agent (залежно від ОС).

Завдання 14: Перевірте джерело годинника ядра і прапорці стабільності

cr0x@server:~$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

Значення: Використовується TSC — це поширено й швидко. На сучасних CPU зазвичай стабільно. На деяких платформах/BIOS може викликати проблеми.

Рішення: Якщо бачите часті стрибки часу, що корелюють із енергетичними станами CPU або міграціями, перевірте налаштування BIOS і розгляньте зміну джерела годинника лише на підставі доказів.

Жарт №2: Якщо хочете відчути себе всемогутнім, виставте годинник сервера на п’ять хвилин уперед і спостерігайте, як усі системи безпеки раптом стають філософами.

Корені проблем: звичні підозрювані в середовищах Proxmox

1) Кілька NTP‑клієнтів, що конфліктують

Debian полегшує ситуацію, коли після оновлень і міграцій на системі опиняються systemd‑timesyncd, chrony і старий ntpd.
Коли два сервіси одночасно вважають, що вони «власники» часу, виникає осциляція: один згладжує, інший робить кроки — логи виглядають як лист вимог.

Моя рекомендація: обирайте chrony для серверів і гіпервізорів, якщо немає вагомих причин інакше. Він краще справляється з переривчастою
доступністю мережі, великими зсувами і віртуалізованими середовищами.

2) Погані або недосяжні джерела часу

«Ми використовуємо pool‑сервери» — прийнятно для ноутбуків; для продукційних гіпервізорів це недбало. Ваші вузли Proxmox повинні використовувати:
внутрішні NTP‑сервери (або пару контрольованих зовнішніх джерел), досяжних у кожній відповідній VLAN.

Якщо джерело NTP за фаєрволом іноді блокує UDP/123 (або має погану стан‑обробку), chrony буде «гойдатись» між джерелами,
збільшуючи джиттер. PBS помітить це як періодичні TLS‑помилки, бо сертифікати не звертають увагу на ваші вікна фаєрволу.

3) RTC налаштовано неправильно (localtime) або дуже дрейфує

RTC у localtime — це конвенція Windows. Linux‑сервери хочуть RTC в UTC. Якщо ви колись двічі завантажували ОС, перетворили робочу станцію в сервер
або імпортували сумнівний образ — ви могли успадкувати неправильний режим RTC. Проблема проявляється при перезавантаженні: система стартує з неправильної основи,
потім NTP намагається виправити. Корекція може бути кроковою. Деякі сервіси ненавидять кроки.

4) Призупинення/міграція віртуалізації і гості з поганим відліком часу

Гості призупиняються під час створення знімків, резервного копіювання, міграції або при навантаженні хоста. Деякі ОС гостей відновлюються плавно; інші дрейфують, потім «винаймуться».
Якщо ви робите резервне копіювання ВМ до PBS у період нестабільності годинника, внутрішні додатки теж можуть отримати проблеми автентифікації (TLS, Kerberos,
реплікація БД).

5) Енергоменеджмент, налаштування BIOS і нестабільні джерела годинника

Сучасні CPU роблять фокус із регулюванням частоти та енергетичних станів. Зазвичай це нормально. Іноді це погано взаємодіє з відліком часу на певних платформах.
Якщо ви бачите кореляцію дрейфу з глибокими C‑станами, оновленнями мікрокоду BIOS або дивними повідомленнями ядра — сприймайте це як проблему апаратного/прошивкового рівня,
а не налаштування NTP.

6) «Загартування безпеки», що блокує синхронізацію часу

Деякі середовища настільки суворо обмежують можливості, дозволи контейнерів або вихідний трафік, що синхронізація часу просто не працює.
Тоді оператори компенсують це ручною установкою часу. Це не загартування — це самопаті з додатковими кроками.

Шаблони виправлення, що дійсно працюють

Оберіть один клієнт часу і налаштуйте його чисто

На хостах Proxmox і PBS я надаю перевагу chrony. Він більш стійкий до джиттера, краще працює з великими відхиленнями і зазвичай поводиться добре в ВМ.
Найважливіша «налаштувальна» частина — управління: один сервіс, керований послідовно, однакові upstream‑джерела по всьому парку.

Використовуйте внутрішні NTP‑джерела (і зробіть їх нудними)

Пара внутрішніх NTP‑серверів, кожен синхронізований із надійним upstream (GPS, PTP grandmaster або перевірені інтернет‑джерела), — це нудний, але правильний
корпоративний підхід. Якщо не можете запускати внутрішні сервери часу, хоча б оберіть кілька upstream і забезпечте стабільну політику фаєрволу.

Керуйте політикою кроків проти згладжування

Великі відхилення вимагають рішення: зробити крок зараз або згладжувати повільно. Для гіпервізорів кроки допустимі під час вікон обслуговування або одразу після завантаження,
але часті кроки в steady‑state вказують на глибшу проблему.

chrony підтримує контрольовані кроки (приклад: дозволяти кроки на перших кількох оновленнях). Мета: швидко ініціалізуватися при завантаженні, потім працювати плавно.

Зробіть RTC адекватним і зберігайте його таким

Встановіть RTC в UTC і тримайте так під час реконструкцій. Якщо RTC ненадійний (деякі серверні плати годяться, деякі вбудовані — ні),
розгляньте частішу дисципліну часу або заміну платформи для критичних вузлів. Гіпервізори — не місце для «достатньо хороших» осциляторів.

Обробляйте гості явно

Для Linux‑гостей: запускайте chrony або systemd‑timesyncd в гостьовій ОС; не покладайтеся лише на підказки від хоста. Для Windows‑гостей: переконайтесь, що сервіс часу налаштований правильно і уникайте одночасного запуску кількох «корисних» інструментів, що обидва намагаються ставити час.

Якщо ви використовуєте QEMU guest agent — використовуйте його для видимості управління, а не як заміну належної гостьової синхронізації.

Стабілізуйте мережевий шлях до NTP

NTP чутливий до стрибків затримки і асиметричної маршрутизації. Воно може терпіти багато чого, але якщо ваша мережна політика ставить UDP/123 як опціональний,
ви отримаєте ненадійну залежність — бо ви її такою зробили.

Три корпоративні міні‑історії з траншей зсуву часу

Міні‑історія 1: Інцидент через хибне припущення

Середня компанія мала три вузли Proxmox і PBS на окремому стелажі. Після рутинного аудиту безпеки хтось посилив правила egress.
Припущення: «NTP внутрішній, тому блокувати вихід не важливо». Звучить розумно. Неправильно в обох сенсах.

«Внутрішні» сервери NTP були насправді ВМ у тому самому кластері Proxmox. Вони були налаштовані синхронізуватися з зовнішніми джерелами. Коли зовнішній UDP/123 почали блокувати,
ці NTP‑ВМ повільно дрейфували. Chrony на вузлах Proxmox охоче прив’язувався до цих внутрішніх джерел — бо вони були досяжні і «стабільні», але стабільні в неправильному напрямку.

Через два тижні резервні копії PBS почали падати з TLS «not yet valid» на деяких вузлах і «expired» на інших. Дрейф не був ідентичним для всіх вузлів.
Оператори оновили сертифікати, бо, звичайно, здавалося, що справа в сертифікатах. Це не допомогло. Не могло допомогти.

Виправлення було нудним: відновити зовнішній NTP для внутрішніх NTP‑ВМ або, краще, запускати джерела часу на виділених невеликих апаратах із явною політикою мережі.
Потім зробити контрольований крок (makestep) у вікні техобслуговування. Ніяких героїчних дій — просто прибрали хибне припущення.

Міні‑історія 2: Оптимізація, що відбилася боком

Інша компанія хотіла «швидшу міграцію» і агресивно налаштувала енергоменеджмент. CPU могли входити в глибокі стани, і деякі дефолти BIOS змінили для зниження споживання.
Кластер став тихішим і холоднішим. Усім це сподобалось.

Потім почалися дивності: після live‑міграцій частина ВМ повідомляла помилки автентифікації до внутрішніх сервісів на кілька хвилин.
Не завжди. Не на всіх хостах. Здавалось, як DNS, як баги в додатках, або «мережа як мережа».

Насправжній винуватець — нестабільність відліку часу при певних переходах енергетичних станів на тій апаратній генерації. Гості дрейфували під час пауз/міграцій, потім поверталися.
Деякі сервіси (особливо з короткоживучими токенами) відкидали запити, бо клієнти були «у майбутньому» або «у минулому».

Рішенням не стало глобальне відключення енергоменеджменту назавжди, а застосування адекватних оновлень BIOS/прошивки, валідація стабільності TSC
і припинення оптимізацій без вимірювань. Вони додали строгіші сповіщення про зсув: пороги відхилення для вузлів і ключових гостей.

Міні‑історія 3: Нудна, але правильна практика, що врятувала день

Велике підприємство мало практику, яка здавалася надто консервативною: кожен гіпервізор і вузол PBS вказували на ту саму пару внутрішніх NTP‑серверів,
а ці сервери вважалися критичною інфраструктурою. Було моніторинг на досяжність, зсув і зміни stratum. Нічого фантастичного.

Під час збою провайдера зовнішня конективність порушилась. Деякі сайти втратили доступ до upstream‑джерел часу. Внутрішні сервери увійшли в деградований стан,
але залишалися консистентними в межах сайту, і сповіщення спрацювали рано: «upstream втрачені; служимо останній відомий добрий стан із зростаючою дисперсією».

Ключовий момент: вузли Proxmox залишалися узгодженими між собою. TLS продовжував працювати, бо годинники не стрибали. Резервні копії йшли, бо PBS і PVE погоджувалися,
що означає «тепер». Операторам вистачило часу (іронія неминуча) реагувати до того, як вікна дії сертифікатів і терміни токенів стали проблемою.

Їхня практика була нудною: два внутрішні джерела, єдина конфігурація, і тривоги на зсув і досяжність. Це не було гламурно. Це було стабільно.

Поширені помилки: симптом → причина → виправлення

1) «Certificate is not yet valid» при доступі до репозиторію PBS

Симптом: PBS‑клієнт падає з «certificate is not yet valid».

Причина: Годинник клієнта відстає від PBS (або обидва різні в різні боки). Іноді RTC неправильний після перезавантаження.

Виправлення: Перевірте timedatectl на обох кінцях, виправте NTP, потім виконайте chronyc -a makestep у безпечне вікно.

2) «Certificate has expired», хоча ви його щойно поновили

Симптом: TLS каже, що сертифікат прострочено одразу після оновлення.

Причина: Системний годинник випереджає; оновлення не вирішило часову лінію.

Виправлення: Виправте час спершу. Потім перевірте вікна дійсності. Поновлюйте сертифікати тільки якщо вони дійсно некоректні після узгодження годинників.

3) Chrony показує джерела, але ніколи не вибирає одне

Симптом: chronyc sources показує доступні сервери, але немає * у вибраному джерелі.

Причина: Перевірки якості джерел падають (поганий stratum, falseticker, надмірний джиттер), або локальний годинник настільки неправильний, що потрібен крок, але кроки вимкнені.

Виправлення: Перевірте chronyc tracking, увімкніть контрольовані кроки, і виправте сервери часу (або оберіть кращі).

4) Синхронізація часу працює до перезавантаження, потім знову неправильна

Симптом: Після перезавантаження час на кілька годин неправильний до виправлення NTP.

Причина: Неправильний RTC, RTC у localtime, сівша батарея CMOS або прошивка не зберігає час.

Виправлення: Встановіть RTC у UTC, виправте апаратний годинник, замініть батарею за потреби, перевірте налаштування BIOS.

5) Події кластера виглядають у невірному порядку між вузлами

Симптом: Кореляція логів неможлива; події виглядають «перед» причинами.

Причина: Годинники вузлів розбіжні на секунди/хвилини; це не обов’язково ламає кластер, але ламає ваш мозок.

Виправлення: Забезпечте однаковий NTP на всіх вузлах; налаштуйте сповіщення про дельту відхилення між вузлами.

6) Гості сильно дрейфують під час резервних копій або знімків

Симптом: Час гостя стрибає після вікна резервного копіювання; додатки всередині ВМ падають від автентифікації.

Причина: Гість призупиняється, у гостя слабке відлічування часу, немає NTP у гості або є навантаження на хост.

Виправлення: Запустіть належну синхронізацію часу в гості; зменшіть час пауз (продуктивність сховища) і переконайтесь, що guest agent встановлений для видимості.

7) «Ми загартували вихідний трафік» і тепер час ненадійний

Симптом: Синхронізація часу періодично падає по всьому парку.

Причина: UDP/123 блокується або станова обробка фаєрволу непослідовна; DNS для NTP‑серверів ламається.

Виправлення: Дозвольте NTP до ваших затверджених серверів; віддавайте перевагу IP або стабільному внутрішньому DNS; моніторьте досяжність і зсув.

8) Перехід з chrony на timesyncd «щоб спростити»

Симптом: Працює в лабораторії, але в проді дрейфує при джиттері і втраті пакетів.

Причина: timesyncd підходить у багатьох випадках, але chrony загалом більш витривалий для серверних мереж і управління відхиленнями.

Виправлення: Використовуйте chrony на гіпервізорах і PBS, якщо немає виміряних причин інакше. Тримайте це послідовно по вузлах.

Контрольні списки / покроковий план (нудкий шлях до стабільного часу)

Крок 0: Визначте, що означає «коректно» у вашому середовищі

• Використовуйте UTC скрізь на серверах (часовий пояс UTC, RTC у UTC).
• Визначте прийнятне відхилення: зазвичай < 100 ms між вузлами для загальної інфраструктури; жорсткіше для чутливих ЗП.
• Оберіть стратегію часу: внутрішні NTP‑сервери або пряме підключення до довірених upstream, якщо потрібно.

Крок 1: Стандартизуйте NTP‑клієнта на вузлах Proxmox

1. Оберіть chrony або systemd‑timesyncd. Не запускайте обидва.
2. Переконайтесь, що лише один сервіс увімкнений і активний.
3. Сконфігуруйте однакові upstream‑сервери на кожному вузлі.

Крок 2: Перевірте досяжність і якість джерела часу

1. Підтвердьте, що UDP/123 до ваших джерел часу дозволений із кожного вузла і PBS.
2. Підтвердьте стабільність резолвінгу DNS, якщо використовуєте імена.
3. Переконайтесь, що у вас щонайменше 2 джерела (краще 3), щоб уникнути обману одного сервера.

Крок 3: Виправте базу (RTC і поточний зсув)

1. Підтвердьте, що RTC у UTC, а не localtime.
2. Якщо відхилення велике — заплануйте контрольований крок корекції.
3. Після корекції спостерігайте за повторними кроками; це симптом, а не фіча.

Крок 4: Загартуйте PBS і PVE для експлуатаційної адекватності

• Поставте PBS на ту саму політику часу, що і кластер.
• Моніторьте зсув часу і досяжність NTP для PBS і PVE.
• Коли резервні копії падають із TLS, перевірте час перед тим, як обертати секрети/сертифікати.

Крок 5: Ставте гостей у перший клас споживачів часу

• Запускайте NTP всередині гостей (chrony/timesyncd).
• Встановіть QEMU guest agent для видимості.
• Спостерігайте за дрейфом після міграцій і інтенсивних знімків.

Крок 6: Операціалізуйте це (сповіщення і рукбуки)

• Сповіщайте про відхилення (абсолютне), швидкість зміни (дрейф) і досяжність (reach).
• Сповіщайте, коли вибране джерело NTP часто змінюється.
• Напишіть рукбук, який починається з timedatectl і закінчується контрольованою ремедіацією.

FAQ

1) Чому зсув часу так надійно ламає TLS?

Перевірка TLS‑сертифікатів залежить від погляду клієнта на час. Якщо клієнт думає, що зараз до notBefore,
сертифікат «ще не дійсний». Якщо думає, що після notAfter — «прострочений». Жодне «але на моєму ноуті працює» не змінить цього — у вас просто працює синхронізація часу на ноутбуці.

2) Чи перевидавати сертифікати PBS або Proxmox, коли бачу TLS‑помилки?

Зазвичай ні. Спочатку доведіть, що годинники коректні на обох кінцях. Перевидача сертифікатів без виправлення часу дасть свіжі сертифікати, які також будуть «недійсними»
у вашій зламаній часовій лінії.

3) chrony чи systemd‑timesyncd на Proxmox?

chrony для більшості вузлів Proxmox і PBS. Він більш стійкий до джиттера і непостійної доступності мережі та дає кращу діагностику.
timesyncd може бути достатнім для простіших середовищ, але послідовність і видимість важливіші за мінімалізм.

4) Який зсув часу «занадто великий» для Proxmox і PBS?

Для TLS навіть секунди можуть зашкодити залежно від вікон валідності сертифікатів і поведінки клієнтів. Операційно тримайте вузли в межах десятків мілісекунд,
якщо можливо. Якщо бачите > 1 секунди між вузлами — це інцидент, а не цікавинка.

5) Чому ВМ дрейфують, якщо хост синхронізований?

Гості мають свої ядра і свій відлік часу. Призупинення (snapshots, migrations, host contention) можуть спричинити дрейф. Якщо гість не має працюючого клієнта часу
або має конфліктуючі служби, він поводитиметься некоректно незалежно від стабільності хоста.

6) Чи може live migration викликати TLS‑помилки всередині ВМ?

Так. Якщо міграція або знімок призупиняє ВМ, а годинник гостя стрибає або інтенсивно згладжується після — короткоживучі токени і перевірки сертифікатів всередині гостя можуть не пройти.
Виправлення — належна гостьова синхронізація часу і мінімізація часу пауз, а не звинувачення PBS.

7) Чи прийнятно використовувати публічні NTP‑сервери для Proxmox?

Це прийнятно, якщо немає альтернативи, але не ідеально. Підприємства віддають перевагу внутрішнім серверам часу для консистентності, продуктивності і контролю політики.
Якщо мусите використовувати публічні джерела — використовуйте кілька, забезпечте стабільний DNS і не змінюйте правила фаєрволу випадково.

8) Який найбезпечніший спосіб виправити великий зсув годинника у проді?

Переважно робіть це у вікні технічного обслуговування. Використовуйте chrony для контрольованого кроку (chronyc -a makestep) замість ручного date -s.
Потім спостерігайте логи на предмет повторних кроків — це вказівка, що причина ще не виправлена.

9) Чи потрібен PTP замість NTP?

Для більшості розгортань Proxmox і PBS NTP достатній. Розгляньте PTP, коли потрібна підмілісекундна синхронізація і ви можете підтримувати його енд‑ту‑енд
(апаратна маркування, відповідний дизайн мережі). PTP, виконаний наполовину — просто дорогий спосіб помилитися швидше.

10) Як запобігти повторенню цієї проблеми?

Стандартизуйте NTP‑клієнт, використовуйте стабільні внутрішні джерела, моніторьте зсув/досяжність і ставте час як зависимість рівня tier‑0.
Технічна частина проста. Дисципліна — складніша.

Наступні кроки, які можна зробити сьогодні

1. Запустіть швидкі перевірки діагностики на кожному вузлі Proxmox і вашій PBS: timedatectl, chronyc tracking, chronyc sources -v.
2. Виключіть дуелі сервісів часу: переконайтесь, що лише один з chrony/timesyncd/ntpd активний.
3. Стандартизуйте upstream: вкажіть усім вузлам і PBS ті самі два‑три довірені часові сервери.
4. Виправте RTC: забезпечте апаратний годинник у UTC і перевірте, що він зберігається після перезавантаження.
5. Операціалізуйте: налаштуйте сповіщення по відхиленню і досяжності перед тим, як TLS і резервні копії почнуть кричати.

Зсув часу — одна з тих проблем, що здається незначною, поки не зіпсує ваш день. Зробіть її нудною. Ваш майбутній я тихо схвалить.