PBS después del segundo reboot — 20 octubre 2026¶
Lectura acotada a00:41–00:43CEST. Discovery por skill locate pbs, documentación operativa y checker instalado. Sin iniciar backups, sync, verify, restores, pings, scrub, prune, limpieza o montajes. No se han recorrido datasets NAS ni leído contenido de copias. No hay commit.
Estado posterior al segundo arranque¶
API /cluster/resources, filtrable por VMID: CT186 pbs, running en nodo proxmox/pmx50, uptime945s en la muestra. Config de mounts conservada: mp0 zfs-ha:subvol-186-disk-1 → /datastore,650GiB; mp1 /mnt/pbs-archive → /archive.
| Elemento | Evidencia actual |
|---|---|
| PBS API/daemon | proxmox-backup.service active/running, inicio00:25:59, ExecMainStatus0. |
| PBS proxy | active/running, inicio00:26:00, ExecMainStatus0. |
| NFS del host | /mnt/pve/terramaster desde 192.168.0.XXX:/Volume1/backups, nfs. |
| Archive del host | /mnt/pbs-archive sobre /dev/loop0, ext4rw; unidad mount active/mounted desde00:27:45. |
| Imagen exacta | losetup --list identifica /dev/loop0 → /mnt/pve/terramaster/pbs-archive.img; lectura de metadata, sin attach/detach. |
| Guard existente | timer active, OnBoot2min/OnUnitActive5min; última ejecución00:38:18 success/exit0. No ejecutado manualmente. |
| Datastores PBS | CLI lista main:/datastore y archive:/archive; no añadido ni cambiado ninguno. |
En CT186, findmnt de /archive muestra tanto el bind inicial del directorio del host como la capa ext4 de loop0. La metadata del pathname efectivo confirma device7:0, correspondiente al loop: no se toma el bind inicial como prueba de que PBS esté leyendo el directorio subyacente equivocado. /datastore es ZFS, device0:53. Ambos pathnames son directorios accesibles UID34/modo0755. statvfs informa disponibles213203943424bytes en main y258249400320bytes en archive; sólo metadata.
La primera lectura sólo acreditaba ActiveEnterTimestamp y no permitía inferir el estado del path al arrancar el invitado. La comprobación posterior del journal del boot <REDACTED> sí registra Mounting y Mounted de la unidad exacta mnt-pbs\x2darchive.mount a00:27:45; guard iniciado ese segundo y finalizado00:27:48. CT186 consta Started00:25:55. Eso acredita un evento real de montaje del host posterior al arranque de CT/PBS. El dispositivo que veía /archive en el primer acceso PBS sigue desconocido, igual que posibles accesos o escrituras anteriores: no se ha retenido aquí una muestra mountinfo/dev del invitado de ese instante. No se afirma un fallback efectivo ni un intervalo demostrado de escrituras al directorio subyacente.
Planificación e historial¶
Sync config main-to-archive intacta: pull desde local-self/main hacia archive, horario06:00, rate30MiB. Checker timer active, próximo20oct07:00CEST; LastTrigger19oct07:00:59, contador0. Servicio checker inactive/dead con exit0, esperado fuera de su ejecución programada.
Se ejecutó sólo python3 /usr/local/lib/pbs-sync-check/check.py --inspect, después de comprobar en fuente que no escribe contador ni hace POST. Resultado: collection_ok=true, sync_ok=true, running0, latest_endtime1792384184 y edad65556s, dentro de su política26h. La API de tareas filtrada syncjob confirma worker exacto local-self:main:archive::main-to-archive: inicio19oct06:00, fin19oct06:29:44, statusOK. No consta un sync nuevo provocado por los reboots.
El intento inicial de ejecutar directamente el helper devolvió permission denied porque es0644; invocarlo con Python, como hace el shim existente, funcionó. No se cambió su modo ni la unidad.
Conclusión limitada: PBS y sus dos paths de datastore están accesibles después del segundo reboot, con archive externo montado y calendario/checker conservados. El historial indica un sync previo completado, no una restauración ni una verificación de integridad posterior a los reboots. No se ha enviado ninguna señal de éxito a sistemas externos.
Dependencias y barreras existentes — revisión sólo lectura¶
La unidad de mount tiene Requires/After de mnt-pve-terramaster.mount y RequiresMountsFor de /mnt y /mnt/pve/terramaster/pbs-archive.img. pbs-archive-guard.service tiene After network-online y dependencias normales, sin RequiresMountsFor. pve-container@186.service, proxmox-backup.service y proxmox-backup-proxy.service tampoco declaran RequiresMountsFor para archive en las propiedades efectivas seleccionadas. No se han leído secretos ni configuraciones completas.
Versión instalada leída: proxmox-backup-server4.1.8-1. El datastore archive expone únicamente name/path/gc-schedule, sin backing-device. En la fuente oficial4.1.8-1, la verificación de mount por UUID se activa cuando hay backing-device; sin él devuelve None. La apertura normal aún utiliza ChunkStore::open, que exige metadata accesible de .chunks antes de abrir el almacén; no inicializa automáticamente un chunkstore sobre un directorio vacío. Esto es una barrera real para ese caso vacío, pero no verifica identidad de filesystem si ya existiese otro chunkstore debajo. No se ha desmontado ni inspeccionado el contenido oculto para determinarlo.
No hay prueba aquí de un backup/sync que haya accedido al filesystem incorrecto. Se mantiene la disponibilidad actual comprobada, y se deja como desconocido el primer acceso durante boot. No se propone ni aplica un cambio de fallback o dependencias basándose sólo en timestamps; cualquier protección adicional requeriría justificar el riesgo y revisar su efecto sobre main/PBS.
Quinto arranque: ventana de montaje y recuperación natural¶
Después del arranque834ae68a… de02:13, primera consulta acotada alrededor02:15: NFSterramaster montado, CT186running y ambos serviciosPBSactive, pero findmnt-M /mnt/pbs-archive sin coincidencia. El pathname /archive del invitado tenía device64513 (252:1), UID/GID65534:65534/modo755. Acredita que todavía no veía el ext4/loop esperado; no se abrió .chunks ni se consultaron tareas en esa ventana, por lo que no acredita acceso o escrituras PBS al filesystem subyacente.
Segunda consulta02:16:17.167CEST, mismo boot834ae68a…: findmnt-M confirma /mnt/pbs-archive ext4 /dev/loop0; /archive efectivo devuelve device1792 (7:0), UID/GID34:34/modo755. El guard programado se ejecutó naturalmente02:15:43, Resultsuccess/ExecMainStatus0; timeractive. La propiedad de la unidad mount consultada sigue inactive/sin ActiveEnterTimestamp; no se usa como prueba del montaje, que sí está acreditado por findmnt y el dispositivo efectivo del guest.
Sin montar manualmente, iniciar guard ni backup/sync/verify/restore. Sólo lecturas de metadata. Esta recuperación de disponibilidad no certifica integridad de backups ni estabilidad futura. Los cinco resets conservan causa sin determinar.
Primer ciclo natural posterior: sync de las 06:00 y checker de las 07:00¶
El 20 de octubre se revalidó el propietario de CT186 por API: proxmox, running.
La lectura del historial terminó a 07:06:36.615569 CEST / 05:06:36.615569 UTC:
dos páginas, 187 filas y EOF acreditado, filtrando el worker exacto
local-self:main:archive::main-to-archive. La primera página llena no se tomó
como historial completo. Última tarea completada:
| Campo | Resultado |
|---|---|
| Inicio | 20 oct, 06:00:00 CEST / 04:00:00 UTC; epoch 1792468800 |
| Fin | 20 oct, 06:38:28 CEST / 04:38:28 UTC; epoch 1792471108 |
| Status completado | OK |
La lectura de systemd y del grupo Pushgateway, a 07:06:04.351951 CEST, mostró
la ejecución natural del checker de 07:00:31 a 07:00:32 CEST:
Result=success, ExecMainCode=1 y ExecMainStatus=0. La unidad oneshot estaba
inactive/dead después de terminar; no es un fallo. Timer active/waiting, último
disparo 07:00:31 y siguiente ejecución 21 oct a las 07:00. Contador duradero: 0.
El GET al endpoint existente de métricas devolvió, para job="pbs_sync_check":
| Métrica | Valor observado |
|---|---|
pbs_syncjob_consecutive_failures |
0 |
pbs_syncjob_collection_success |
1 |
pbs_syncjob_check_success |
1 |
pbs_syncjob_latest_completed_timestamp_seconds |
1792470000 |
push_time_seconds |
1792472432.1397634; 07:00:32.139763 CEST |
Esta vez el historial sí acredita un sync nuevo de hoy, además del check natural posterior. No se ejecutó el checker manualmente ni se inició sync, backup, verify, restore, POST o ping de Healthchecks. El status OK no acredita restauración ni integridad independiente del contenido copiado.
Defecto de precisión observado y corrección fuente¶
El timestamp publicado no corresponde a otro sync de las 06:20: es el mismo
fin 1792471108 redondeado a 1792470000 por el formato Python :g, que usa seis
cifras significativas por defecto. Pierde aquí 1108 segundos (18 min 28 s)
y puede mover indebidamente el cruce del warning de 26 h. La evaluación interna
del checker conservó el timestamp real y fue correcta; el defecto afecta a su
serialización métrica.
Se corrigió únicamente esa representación a la conversión numérica por defecto,
que conserva el round-trip del float validado, sin redondear a enteros los tiempos
fraccionarios que la API admite. No se halló otro formato :g de epochs en este
módulo; la salida JSON ya conserva el número y el until entero es un límite de
consulta deliberado, no el timestamp publicado.
Las 17 pruebas previas se conservan y se añaden dos: epochs modernos exactos,
fracciones y cero sin completado; y equivalencia entre la edad publicada y la
evaluación interna justo antes/después de 26 h. 19 pruebas pasan localmente
en Python 3.12 y 3.14. Checker fuente SHA256
<REDACTED>;
tests <REDACTED>.
La corrección quedó publicada en 4e83af8. El
run 39373304025
terminó SUCCESS en sus tres jobs, con la suite PBS de 19 pruebas en Linux Python
3.10 y 3.12, además de los contratos y fixtures promtool.
Instalación acotada de precisión: 07:09:46 CEST¶
A 07:09:46.968412 CEST / 05:09:46.968412 UTC, el coordinador revalidó CT186
running en proxmox por API e instaló sólo el helper corregido mediante CAS,
rename atómico y fsync:
- SHA previo:
<REDACTED>. - SHA instalado:
<REDACTED>. - Archivo regular, UID/GID 0:0, modo 0644, nlink 1, inode instalado 67158.
- Compilación nativa Python 3.13.5 correcta, sin ejecutar el módulo. No equivale a una suite nativa; las suites Linux corresponden al run CI citado.
- Servicio inactive/MainPID 0 antes y después. Shim, contador, servicio y timer conservaron hashes, inodes y metadatos.
- Rollback privado
/root/rollback-pbs-check-precision-20261020-_31zchsn, directorio 0700, copia previa y recibo 0600, persistidos con fsync.
No se ejecutaron checker, POST, jobs ni reload durante la instalación. El valor publicado antiguo 1792470000 permanece sin sobrescribir manualmente. La primera publicación precisa con este helper queda pendiente del próximo check natural, 21 de octubre a las 07:00 CEST; no se adelanta como prueba.
Si se requiere rollback de esta corrección, revalidar propietario, unidad inactiva con MainPID 0 y CAS del helper contra el SHA a54a… instalado. Verificar la copia privada contra el SHA previo 4ebcd… y restaurar sólo ese helper, con los mismos owner/modo y escritura atómica/fsync. Conservar contador, unidades y shim; no usar un rollback histórico completo del checker ni modificar métricas para simular un resultado. Un hash ajeno o actividad concurrente exige detenerse y revisar, sin sobrescribir ni iniciar el servicio.