Deriva de tiempo en Proxmox: problemas NTP que rompen TLS/PBS y cómo solucionarlo

Por qué la deriva de tiempo rompe Proxmox, TLS y PBS

El tiempo es una dependencia que no figuran en tus diagramas de arquitectura, pero sigue siendo una dependencia. Los certificados TLS
tienen ventanas “notBefore” y “notAfter”. Kerberos, JWT y la mayoría de sistemas de tickets dependen del tiempo. Los clústeres usan el tiempo
como una señal tenue para liveness y orden de eventos. Los sistemas de backup construyen políticas de retención y recolección de basura sobre
la suposición de que el “ahora” es algo monotónico-ish.

Proxmox VE se apoya en Debian. El nodo usa servicios de sistema (chrony o systemd-timesyncd, a veces el antiguo ntpd),
un RTC hardware (reloj de tiempo real) y el timekeeping del kernel. PBS es estricto con TLS porque debe serlo. Así que si el
reloj del nodo está atrasado, obtienes “certificate not yet valid”. Si está adelantado, obtienes “certificate expired” aunque
no lo esté realmente.

Cómo se manifiesta en la práctica

• Las copias en PBS fallan con errores de handshake TLS o fallos de autenticación.
• La interfaz web de Proxmox funciona en un nodo pero no en otro, o los navegadores muestran advertencias inesperadas.
• Nodos del clúster se “pierden” entre sí aleatoriamente, muestran ordenes de log extrañas o eventos confusos de corosync.
• Las VMs se desincronizan incluso si el host está estable, porque los invitados son un universo pequeño con sus propios malos hábitos.

Si tu instinto es “simplemente ajustaré la hora manualmente”, resístete. Los saltos de tiempo pueden romper servicios en ejecución de formas que
parecen corrupción. Las correcciones graduales suelen ser más seguras, y cuando necesitas un ajuste abrupto, hazlo con intención y controlando el radio de impacto.

Una verdad operacional que vale la pena imprimir:
idea parafraseada de Werner Vogels (reliability/operations): todo falla; diseña para que siga funcionando de todos modos.
La sincronización de tiempo forma parte de ese plan de “seguir funcionando”.

Datos interesantes y un poco de historia (porque los relojes son raros)

• NTP es antiguo—realmente antiguo. Es anterior a la mayoría del pensamiento moderno de “cloud”, y sigue siendo uno de los protocolos más desplegados en el mundo.
• Linux mantiene el tiempo con múltiples relojes. Hay tiempo de pared, tiempo monotónico y a veces contadores basados en TSC/HPET—cada uno con garantías diferentes.
• La virtualización complicó el tiempo. Una VM pausada no experimenta tiempo; el mundo sí. Recuperarlo no es trivial.
• Los segundos intercalados existen y son molestos. Algunos sistemas hacen step; otros smear. Las estrategias mixtas pueden causar desviaciones transitorias extrañas.
• El drift del RTC es normal. Los osciladores baratos se desvían con la temperatura y la edad; unos pocos segundos por día pueden ocurrir en placas de consumo.
• Corosync no “necesita” tiempo perfecto, pero depurar comportamiento de clúster sin timestamps consistentes es como hacer cirugía con gafas empañadas.
• TLS es sensible al tiempo por diseño. No es exagerado; “notBefore” previene la reproducción de certificados emitidos en el futuro y mitiga ciertos ataques.
• PTP existe porque NTP no siempre es suficiente. Cuando necesitas sincronización sub-milisegundo (trading, telecom, medición), PTP con timestamping hardware es la opción.
• La smear de Google popularizó la idea de que hacer step al tiempo es peligroso a escala; muchas empresas copiaron la estrategia sin entender los tradeoffs.

Broma #1: La sincronización de tiempo es el único lugar donde “lo suficientemente cercano” y “criptografía” se encuentran, y enseguida empiezan a discutir.

Guía rápida de diagnóstico

Cuando Proxmox/PBS empieza a lanzar errores TLS, quieres la ruta más corta a “¿es el tiempo?” sin caer en una excavación arqueológica de una semana por los registros.

Primero: confirma la desviación y si el sistema cree que está sincronizado

1. Comprueba la hora local frente a la realidad (y confirma zona horaria/modo RTC).
2. Comprueba el estado de sincronización NTP (chrony o systemd-timesyncd).
3. Comprueba si el tiempo está dando saltos o ajustándose lentamente (los offsets grandes tienden a realizar step a menos que se configure lo contrario).

Segundo: identifica la fuente de tiempo y si es accesible

1. ¿Qué servicio gestiona NTP? chrony vs systemd-timesyncd vs ntpd: elige uno.
2. ¿Tus servidores configurados son alcanzables? DNS, firewall, enrutamiento, ACLs de VLAN.
3. ¿El host tiene permiso para fijar la hora? contenedores y algunas configuraciones endurecidas pueden bloquearlo.

Tercero: revisa problemas específicos de virtualización

1. Host estable, invitados desincronizados? Entonces debes arreglar el timekeeping del invitado, no el NTP en el host.
2. ¿Tras suspend/resume o migración en caliente? Eso es un problema de clocksource/guest-agent/política de stepping.
3. ¿Nodos del clúster en desacuerdo? Normaliza la hora en todos los nodos antes de tocar la configuración de corosync.

La regla: no depures TLS hasta que hayas probado que el tiempo es correcto. Los errores TLS son sinceros: tu reloj miente, no tus certificados.

Tareas prácticas (comandos, salidas, decisiones)

Has pedido algo de grado producción. Aquí tienes tareas reales que puedes ejecutar en nodos Proxmox y PBS. Cada una incluye:
comando, salida de ejemplo, qué significa y qué decisión tomar.

Tarea 1: Verificación rápida de sanidad: hora local y tiempo del kernel

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

Significado: Este es el tiempo de pared con desplazamiento de zona. Si no es obviamente “ahora”, detente y corrige la hora antes de cualquier otra cosa.

Decisión: Si está desviado por más de unos pocos segundos en un entorno de centro de datos, procede a comprobar el estado de NTP. Si está desviado por minutos/horas, espera fallos TLS y probablemente una corrección por step.

Tarea 2: Confirma si el sistema cree que está sincronizado

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

Significado: “System clock synchronized: yes” es una buena señal. “RTC in local TZ: no” es el valor sensato por defecto para servidores Linux (RTC en UTC).

Decisión: Si synchronized: no, no supongas. Identifica el cliente NTP y la alcanzabilidad de sus servidores a continuación.

Tarea 3: Identifica quién gestiona NTP (chrony vs systemd-timesyncd vs ntpd)

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

Significado: chrony está activo; los demás no. Bien: un solo servicio de tiempo.

Decisión: Si hay más de uno activo, soluciona eso primero. Clientes NTP peleándose entre sí generan jitter, stepping y miseria operativa.

Tarea 4: Revisa el tracking de chrony (offset, frecuencia, estado de leap)

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

Significado: El offset es ínfimo; chrony está bloqueado en 10.10.10.1. La frecuencia se está ajustando. Esto es saludable.

Decisión: Si el “System time” muestra un offset de segundos o más, probablemente tengas mala alcanzabilidad, una fuente mala o un problema de clocksource.

Tarea 5: Revisa las fuentes de chrony y su alcanzabilidad

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

Significado: ^* es la fuente seleccionada, Reach 377 significa respuestas exitosas. Un Reach cercano a 0 significa que no estás hablando con ese servidor.

Decisión: Si todas las fuentes muestran ? o el reach es bajo, investiga la red/DNS/firewall de inmediato.

Tarea 6: Confirma que el puerto NTP (UDP/123) no está bloqueado

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

Significado: Esto no prueba respuestas NTP correctas, pero sí la alcanzabilidad básica a UDP/123.

Decisión: Si falla, deja de afinar chrony y arregla la política de red/ enrutamiento primero.

Tarea 7: Detecta eventos de stepping y reinicios de hora en los logs

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

Significado: chrony ajustó el reloj por step en 3.421 segundos. Los pasos son a veces correctos, pero los pasos frecuentes indican inestabilidad.

Decisión: Si ves stepping repetido, investiga pausas/migraciones de virtualización, RTC defectuoso o múltiples clientes de tiempo.

Tarea 8: Verifica el reloj hardware y el modo RTC (UTC vs localtime)

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

Significado: El RTC está cerca del tiempo del sistema y en UTC.

Decisión: Si el RTC es muy distinto, corrige el RTC y asegura que Linux use UTC. RTC malo + reinicio = viaje en el tiempo.

Tarea 9: Forzar una corrección única de forma segura (chrony)

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

Significado: chrony realizó un step del reloj si era necesario, según su política.

Decisión: Usa esto cuando tengas una gran desviación y necesites restaurar la cordura ahora. Luego corrige la causa subyacente.

Tarea 10: Verifica que el error TLS esté relacionado con la hora (lado cliente PBS)

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

Significado: “Not yet valid” es un letrero neón de desfase de reloj en el cliente (este nodo Proxmox) o a veces en el servidor (pbs01).

Decisión: Comprueba la hora en ambos extremos. Arregla la hora primero; no vuelvas a emitir certificados como primer movimiento.

Tarea 11: Confirma la hora en 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

Significado: PBS está sincronizado. Si el cliente no lo está, el problema es del cliente.

Decisión: Si PBS también está desincronizado, arregla PBS primero: tu target de backup debe ser una “autoridad de tiempo”, no otro participante que deriva.

Tarea 12: Revisa la salud del clúster Proxmox y correlaciónalo con problemas de tiempo

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

Significado: Si la “Date” difiere significativamente entre nodos cuando ejecutas esto en cada uno, tienes deriva. El quórum puede seguir siendo “Yes”, pero vives de prestado.

Decisión: Normaliza la hora en todos los nodos antes de investigar rarezas intermitentes del clúster.

Tarea 13: Detecta deriva de invitados desde el host usando QEMU guest agent (cuando esté instalado)

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

Significado: Has obtenido el tiempo epoch del invitado. Compáralo con el epoch del host (date +%s) para estimar el desfase.

Decisión: Si los invitados están desincronizados mientras el host es estable, arregla NTP/herramientas del invitado y considera habilitar la estrategia de sincronización de tiempo del guest agent (depende del SO).

Tarea 14: Revisa el clocksource del kernel y flags de estabilidad de timekeeping

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

Significado: Usar TSC es común y rápido. En CPUs modernas suele ser estable. En algunas plataformas/ajustes de BIOS puede ser problemático.

Decisión: Si ves saltos de tiempo frecuentes correlacionados con estados de potencia CPU o migraciones, valida la configuración de BIOS y considera otro clocksource solo con evidencia.

Broma #2: Si alguna vez quieres sentirte poderoso, adelanta el reloj de un servidor cinco minutos y observa cómo todos los sistemas de seguridad se convierten de repente en filósofos.

Causas raíz: los sospechosos habituales en entornos Proxmox

1) Múltiples clientes NTP peleándose

Debian facilita terminar con systemd-timesyncd, chrony y un ntpd antiguo instalados tras upgrades y migraciones.
Cuando dos servicios creen que son los dueños del tiempo, obtendrás oscilación: uno hace slew, el otro hace step y tus logs parecerán una nota de rescate.

Guía con opinión: elige chrony para servidores e hipervisores a menos que tengas una razón muy específica para no hacerlo. Maneja bien la conectividad intermitente,
offsets grandes y entornos virtualizados.

2) Fuentes de tiempo malas o inalcanzables

“Usamos pool servers” está bien para portátiles; es descuidado para hipervisores de producción. Tus nodos Proxmox deberían usar:
servidores NTP internos (o un par de fuentes ascendentes bien controladas) alcanzables en cada VLAN relevante.

Si tu fuente NTP está detrás de un firewall que a veces bloquea UDP/123 (o maneja mal timeouts stateful), chrony fluctuará entre fuentes,
incrementando jitter. PBS lo notará en forma de fallos TLS intermitentes, porque los certificados no se preocupan por tu ventana de cambio de firewall.

3) RTC mal configurado (localtime) o con mucho drift

RTC en localtime es una convención de Windows. Los servidores Linux quieren RTC en UTC. Si alguna vez hiciste dual-boot, reutilizaste una estación de trabajo o
importaste una imagen sospechosa, puedes heredar el modo RTC equivocado. El problema aparece al reiniciar: el sistema arranca con una base equivocada,
luego NTP intenta corregirla. La corrección puede ser un step. Algunos servicios odian los steps.

4) Pausas/migraciones de virtualización e invitados con timekeeping débil

Los invitados se pausan durante snapshots, backups, migraciones o contención del host. Algunos SO de invitados se recuperan con gracia; otros se desincronizan, luego vuelven.
Si haces backup de una VM a PBS mientras su reloj es inestable, puedes tener problemas de autenticación dentro del invitado también (TLS a nivel de app, Kerberos,
replicación de bases de datos).

5) Gestión de energía, ajustes de BIOS y clocksources inestables

Las CPUs modernas hacen magia con scaling de frecuencia y estados de potencia. Normalmente está bien. A veces interactúa mal con el timekeeping en generaciones de hardware concretas.
Si ves drift correlacionado con deep C-states, actualizaciones de microcódigo BIOS o mensajes raros del kernel, trátalo como problema de hardware/firmware,
no de configuración NTP.

6) “Endurecimiento” de seguridad que bloquea la sincronización de tiempo

Algunos entornos cierran capacidades, permisos de contenedores o tráfico saliente tan estrictamente que la sincronización de tiempo no puede funcionar.
Entonces los operadores compensan ajustando la hora manualmente. Eso no es endurecimiento; es autolesión con pasos adicionales.

Patrones de solución que realmente funcionan

Elige un cliente de tiempo y configúralo limpiamente

En hosts Proxmox y PBS, prefiero chrony. Es robusto ante jitter, maneja offsets grandes y suele comportarse bien en VMs también.
La configuración más importante es la gobernanza: un servicio, gestionado de forma consistente, mismas fuentes ascendentes en toda la flota.

Usa fuentes NTP internas (y hazlas aburridas)

Un par de servidores NTP internos, cada uno sincronizado a fuentes fiables ascendentes (GPS, PTP grandmaster o fuentes de internet verificadas), es el patrón empresarial correcto y aburrido.
Si no puedes ejecutar servidores de tiempo internos, al menos elige múltiples ascendentes y asegura que la política de firewall sea estable.

Controla la política de stepping vs slewing

Los offsets grandes obligan a decidir: hacer step ahora, o hacer slew lentamente. Para hipervisores, el step es aceptable durante ventanas de mantenimiento o justo después del arranque,
pero el stepping frecuente durante el estado estable indica un problema más profundo.

chrony soporta stepping controlado (ejemplo: permitir step durante las primeras actualizaciones). La meta es: arrancar rápido y luego ser suave.

Haz el RTC sensato y mantenlo así

Define RTC en UTC y mantenlo así a través de rebuilds. Si tu RTC es poco fiable (algunas placas de servidor están bien, algunas cosas embebidas no lo están),
considera disciplinarlo con mayor frecuencia o reemplazar la plataforma en nodos críticos. Los hipervisores no son el lugar para osciladores “suficientemente buenos”.

Gestiona los invitados explícitamente

Para invitados Linux: ejecuta chrony o systemd-timesyncd en el invitado; no confíes únicamente en las pistas proporcionadas por el host. Para invitados Windows: asegúrate de que el servicio de tiempo
esté configurado correctamente y evita apilar herramientas “útiles” que ambas intenten fijar la hora.

Si usas QEMU guest agent, úsalo para visibilidad de gestión, no como sustituto de una sincronización de tiempo correcta en el invitado.

Estabiliza la ruta de red hacia NTP

NTP es sensible a picos de latencia y enrutamiento asimétrico. Puede tolerar mucho, pero si tu política de red trata UDP/123 como opcional,
se comportará como una dependencia defectuosa—porque la hiciste así.

Tres micro-historias corporativas desde las trincheras del desfase horario

Micro-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana ejecutaba un clúster Proxmox de tres nodos con PBS en un rack separado. Tras una auditoría de seguridad rutinaria, alguien apretó las reglas de egress.
La suposición: “NTP es interno, así que bloquear el tráfico saliente no importa”. Sonaba razonable. Estaba equivocado en dos formas.

Los “servidores NTP internos” eran en realidad VMs en el mismo clúster Proxmox. Estaban configuradas para sincronizarse desde fuentes externas. Con UDP/123 saliente bloqueado,
las VMs de tiempo se desviaron lentamente. Chrony en los nodos Proxmox se bloqueó en esas fuentes internas—porque eran alcanzables y estables,
pero estables en la dirección equivocada.

Dos semanas después, las copias en PBS empezaron a fallar con errores TLS “not yet valid” en algunos nodos y “expired” en otros. La deriva no fue idéntica entre nodos.
Los operadores rotaron certificados porque, claro, parecía un problema de certificados. Eso no ayudó. No podía ayudar.

La solución fue aburrida: restaurar el NTP saliente para las VMs internas de tiempo o, mejor, ejecutar fuentes de tiempo en appliances dedicados pequeños con política de red explícita.
Luego forzar una corrección controlada (makestep) durante una ventana de mantenimiento. Sin heroísmos, solo eliminar una suposición rota.

Micro-historia 2: La optimización que salió mal

Otra organización quería “migración más rápida” y afinó la gestión de energía agresivamente. Se permitieron estados de sueño profundos en CPUs y se cambiaron defaults de BIOS
para reducir consumo. El clúster quedó más silencioso y frío. Todos se felicitaron.

Luego vino lo raro: tras migraciones en caliente, un subconjunto de VMs reportaba fallos de autenticación con servicios internos durante unos minutos.
No siempre. No en todos los hosts. Parecía DNS. Parecía bugs de aplicación. Parecía “la red haciendo de la suyas”.

El culpable real fue la inestabilidad del timekeeping bajo ciertas transiciones de estado de potencia en esa generación de hardware. Los invitados se desincronizaban durante migración/pausa,
luego volvían. Algunos servicios (notablemente los que usan tokens de corta vida) rechazaban peticiones porque los clientes estaban “en el futuro” o “en el pasado”.

La resolución no fue deshabilitar la gestión de energía globalmente para siempre, sino aplicar actualizaciones de BIOS/firmware sensatas, validar el comportamiento estable del TSC
y dejar de optimizar sin medir. Reintrodujeron una alerta más estricta de monitoreo de tiempo: umbrales de offset por nodo y por invitados clave.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una empresa más grande tenía una práctica que parecía casi demasiado conservadora: cada hipervisor y nodo PBS apuntaba al mismo par de servidores NTP internos,
y esos servidores de tiempo se trataban como infraestructura crítica. Tenían monitoreo de alcanzabilidad, offset y cambios de stratum. Nada llamativo.

Durante una caída del proveedor, la conectividad externa se volvió problemática. Algunos sitios perdieron acceso a referencias de tiempo ascendentes. Los servidores internos
entraron en un estado degradado, pero se mantuvieron consistentes dentro del sitio, y las alertas saltaron temprano: “upstream perdido; sirviendo último bueno conocido con dispersión creciente”.

El punto clave: los nodos Proxmox permanecieron consistentes entre sí. TLS siguió funcionando porque los relojes no saltaron. Las copias continuaron porque PBS y PVE coincidían
en lo que significaba “ahora”. Los operadores tuvieron tiempo (la ironía es inevitable) para responder antes de que ventanas de expiración y vidas de tokens se convirtieran en un problema.

Su práctica era aburrida: dos fuentes internas, gestión de configuración coherente y alarmas sobre offset y reach. No era glamorosa. Era sobrevivible.

Errores comunes: síntoma → causa raíz → solución

1) “Certificate is not yet valid” en un repositorio PBS

Síntoma: El cliente PBS falla con “certificate is not yet valid”.

Causa raíz: Reloj del cliente atrasado respecto a PBS (o ambos mal en direcciones distintas). A veces RTC equivocado tras un reinicio.

Solución: Verifica timedatectl en ambos, corrige NTP y luego ejecuta chronyc -a makestep durante una ventana segura.

2) “Certificate has expired” pero acabas de renovarlo

Síntoma: TLS dice expirado inmediatamente tras la renovación.

Causa raíz: El reloj del sistema está adelantado; la renovación no arregló la línea temporal.

Solución: Arregla la hora primero. Luego verifica las ventanas de validez. Reemite certificados solo si realmente están mal tras acordar los relojes.

3) Chrony muestra fuentes pero nunca selecciona una

Síntoma: chronyc sources muestra servidores alcanzables pero no hay un * seleccionado.

Causa raíz: Los checks de calidad del servidor fallan (mal stratum, falseticker, jitter excesivo), o el reloj local está tan mal que necesita un step y el stepping está deshabilitado.

Solución: Inspecciona chronyc tracking, habilita una política de stepping controlado y arregla los servidores de tiempo (o elige mejores).

4) La sincronización de tiempo funciona hasta reiniciar, luego vuelve a estar mal

Síntoma: Tras reinicio, la hora está horas fuera antes de que NTP la corrija.

Causa raíz: RTC equivocado, RTC en localtime, pila CMOS muerta o firmware que no persiste correctamente el reloj.

Solución: Establece RTC en UTC, corrige el reloj hardware, reemplaza la batería si hace falta, valida ajustes de BIOS.

5) Eventos del clúster muestran orden incorrecto entre nodos

Síntoma: Correlación de logs imposible; eventos aparecen “antes” de sus causas.

Causa raíz: Los relojes de los nodos no coinciden por segundos/minutos; no necesariamente rompe el clúster pero sí tu cabeza.

Solución: Impón consistencia NTP en todos los nodos; alerta sobre deltas de offset entre nodos.

6) Los invitados se desincronizan mucho durante backups o snapshots

Síntoma: El tiempo del invitado salta tras la ventana de backup; las apps dentro de la VM fallan en autenticación.

Causa raíz: Invitado pausado, timekeeping débil del invitado, sin NTP en el invitado o contención del host.

Solución: Ejecuta sincronización de tiempo adecuada dentro del invitado; reduce tiempos de pausa (mejora rendimiento de almacenamiento) y confirma instalación del guest agent para observabilidad.

7) “Endurecimos el tráfico saliente” y ahora el tiempo es inestable

Síntoma: La sincronización de tiempo falla intermitentemente en la flota.

Causa raíz: UDP/123 bloqueado o firewall stateful manejado de forma inconsistente; DNS para servidores NTP falla.

Solución: Permite NTP a tus servidores aprobados; prefiere IPs o DNS interno estable; monitoriza reach y offset.

8) Cambiar de chrony a timesyncd “para simplificar”

Síntoma: Funciona en laboratorio, deriva en producción con jitter y pérdida de paquetes.

Causa raíz: timesyncd está bien para muchos casos, pero chrony es generalmente más resiliente para redes de servidor y gestión de offsets.

Solución: Usa chrony en hipervisores y PBS salvo que tengas una razón medida para no hacerlo. Mantén consistencia entre nodos.

Listas de verificación / plan paso a paso (el camino aburrido hacia tiempo estable)

Paso 0: Decide qué significa “correcto” en tu entorno

• Usa UTC en todas partes en servidores (zona horaria UTC, RTC en UTC).
• Define offset aceptable: típicamente < 100 ms entre nodos para infraestructura general; más estricto si ejecutas apps sensibles a latencia.
• Elige una estrategia de tiempo: servidores NTP internos, o conexión directa a upstreams confiables si es necesario.

Paso 1: Estandariza el cliente NTP en nodos Proxmox

1. Elige chrony o systemd-timesyncd. No ejecutes ambos.
2. Asegura que solo un servicio esté habilitado y activo.
3. Configura los mismos servidores ascendentes en cada nodo.

Paso 2: Valida la alcanzabilidad y calidad de las fuentes de tiempo

1. Confirma que UDP/123 hacia tus fuentes de tiempo está permitido desde cada nodo y PBS.
2. Confirma que la resolución DNS es estable si usas nombres.
3. Confirma que tienes al menos 2 fuentes (preferible 3) para evitar mentiras de un solo servidor.

Paso 3: Arregla la línea base (RTC y offset actual)

1. Confirma que RTC está en UTC, no en localtime.
2. Si el offset es grande, programa una corrección por step controlada.
3. Tras la corrección, vigila stepping repetido; es un síntoma, no una característica.

Paso 4: Endurece PBS y PVE para sanidad operativa

• Pon PBS bajo la misma política de tiempo que el clúster.
• Monitorea offset NTP y reach para PBS y PVE.
• Cuando las copias fallen por TLS, comprueba la hora antes de rotar secretos/certs.

Paso 5: Trata a los invitados como consumidores de tiempo de primera clase

• Ejecuta NTP dentro de los invitados (chrony/timesyncd).
• Instala QEMU guest agent para visibilidad.
• Vigila la deriva tras migraciones y ventanas con muchos snapshots.

Paso 6: Operationalízalo (alertas y runbooks)

• Alerta sobre offset (absoluto), tasa de cambio (drift) y reach (conectividad).
• Alerta cuando la fuente NTP seleccionada cambie con frecuencia.
• Escribe un runbook que empiece con timedatectl y termine con remediación controlada.

Preguntas frecuentes

1) ¿Por qué la deriva de tiempo rompe TLS tan confiablemente?

La validación de certificados TLS depende de la visión temporal del cliente. Si el cliente cree que está antes de notBefore,
el certificado es “not yet valid”. Si cree que está después de notAfter, está “expired”. No importa el “funciona en mi portátil”—
tu portátil tiene sincronización de tiempo operativa.

2) ¿Debo reemitir certificados de PBS o Proxmox cuando veo errores TLS?

Normalmente no. Primero prueba que los relojes sean correctos en ambos extremos. Reemitir certificados sin arreglar el tiempo solo te dará certificados nuevos que también serán “inválidos”
en tu línea temporal rota.

3) chrony o systemd-timesyncd en Proxmox?

chrony para la mayoría de nodos Proxmox y PBS. Es robusto frente al jitter y la conectividad intermitente y proporciona mejores diagnósticos.
timesyncd puede ser suficiente en setups más simples, pero la consistencia y la observabilidad importan más que el minimalismo aquí.

4) ¿Cuánta deriva es “demasiada” para Proxmox y PBS?

Para TLS, incluso segundos pueden perjudicar según las ventanas de validez de certificados y el comportamiento del cliente. Operativamente, mantén nodos dentro de decenas de milisegundos
si puedes. Si ves > 1 segundo entre nodos, trátalo como un incidente, no una curiosidad.

5) ¿Por qué las VMs se desincronizan aunque el host esté sincronizado?

Los invitados tienen sus propios kernels y su propio timekeeping. Las pausas (snapshots, migraciones, contención del host) pueden causar deriva. Si el invitado carece de un cliente de tiempo funcional
o tiene servicios de tiempo en conflicto, se comportará mal independientemente de la estabilidad del host.

6) ¿Puede una migración en caliente causar errores TLS dentro de la VM?

Sí. Si la migración o snapshot pausa la VM y el reloj del invitado salta o se ajusta agresivamente después, los tokens de corta duración y las comprobaciones de certificados dentro del invitado pueden fallar.
La solución es sincronización de tiempo adecuada en el invitado y minimizar tiempos de pausa, no culpar a PBS.

7) ¿Es aceptable usar servidores NTP públicos para Proxmox?

Es aceptable si no tienes alternativa, pero no es lo ideal. Las empresas prefieren servidores de tiempo internos por consistencia, rendimiento y control de políticas.
Si debes usar fuentes públicas, usa múltiples, asegura DNS estable y no cambies reglas de firewall a la ligera.

8) ¿Cuál es la forma más segura de corregir una gran desviación de reloj en un nodo de producción?

Prefiere hacerlo en una ventana de mantenimiento. Usa chrony para realizar un step controlado (chronyc -a makestep) en lugar de date -s manual.
Luego vigila logs por stepping repetido, lo que indica que la causa raíz persiste.

9) ¿Necesito PTP en lugar de NTP?

Para la mayoría de despliegues Proxmox y PBS, NTP es suficiente. Considera PTP cuando necesites sincronización sub-milisegundo y puedas soportarlo de extremo a extremo (timestamping hardware,
diseño de red apropiado). Hacer PTP a medias es solo una forma cara de equivocarse más rápido.

10) ¿Cómo evito que esto vuelva a ocurrir?

Estandariza el cliente NTP, usa fuentes internas estables, monitoriza offset/reach y trata el tiempo como una dependencia de nivel 0. La parte técnica es fácil.
La disciplina es la parte difícil.

Siguientes pasos que puedes hacer hoy

1. Ejecuta las comprobaciones rápidas de diagnóstico en cada nodo Proxmox y tu caja PBS: timedatectl, chronyc tracking, chronyc sources -v.
2. Elimina servicios de tiempo en pugna: asegúrate de que solo chrony/timesyncd/ntpd esté activo uno a la vez.
3. Estandariza los upstreams: apunta todos los nodos y PBS a las mismas dos o tres fuentes de tiempo confiables.
4. Arregla el RTC: asegura reloj hardware en UTC y verifica que sobreviva a reinicios.
5. Operationaliza: alerta sobre offset y reach antes de que TLS y backups empiecen a gritar.

La deriva de tiempo es uno de esos problemas que parece menor hasta que te arruina el día. Haz que sea aburrido. Tu yo futuro te lo agradecerá en silencio.