Expectativa de publicación del dump de Immich¶
20 de octubre de 2026. Preparación inicial sólo fuente, seguida de revisión y despliegue explícito por Root documentados al final. No se han leído datos privados ni ejecutado jobs de copia o publicación para probar esta regla.
La activación real del publicador deja un requisito operativo: primer éxito antes del 20 de octubre de 2026 a las 16:30 Europe/Madrid (14:30 UTC, epoch 1792506600), y después ningún intervalo sin publicación verificada mayor de 26 horas. La primera fecha permite el job natural de las 11:10, su timeout de cinco horas y veinte minutos de margen.
El hueco acreditado está en las métricas anteriores: enabled describe la última ejecución, y Stale exige un éxito previo. Activar el flag no modifica last.json. Si todo el job deja de ejecutarse, OriginalsStale avisaría a las 48 horas del último éxito de originales; si éstos siguen funcionando pero pierden el flag, sus éxitos pueden ocultar indefinidamente la ausencia del dump. El colector puede seguir sano en ambos casos. RunWispUnavailable comprueba el daemon, no una ejecución concreta.
La regla nueva OriginalsDumpPublicationRequired, warning con for: 10m, evalúa dos alternativas sin depender de enabled:
- Sin primer éxito (timestamp cero o serie ausente), sólo después del plazo absoluto indicado.
- Con éxito previo, cuando tiene más de 93.600 segundos, incluso si desaparece el flag.
Es una expectativa explícita de servicio, no una métrica de activación ni evidencia de éxito inventada. Serie ausente significa falta de evidencia, no pérdida demostrada del respaldo. No cambia OriginalsDumpPublicationFailed, OriginalsDumpPublicationStale, jobs, receptores, notificaciones, horarios, ni el estado de copias.
Las reglas de scripts/original-backups/alerts.yml y del template Ansible son iguales. Cinco pruebas locales pasan: fecha de Madrid, paridad y unicidad, conservación de las dos reglas anteriores, coherencia de fixtures y generación exclusiva de reglas de prueba. Los fixtures promtool cubren antes/después del plazo y su espera, métrica ausente, disabled sin éxito, éxito fresco y disabled con éxito envejecido.
Durante la preparación no había promtool local y no se autorizó ejecución remota en esa fase. La sintaxis PromQL y los fixtures se validaron después en la fase nativa autorizada documentada al final. Para evitar millones de evaluaciones desde epoch cero, sólo la copia temporal de prueba sustituye el escalar absoluto 1792506600 por 3600; la fuente productiva conserva la fecha real, comprobada por test. Preparación en un directorio temporal vacío:
python3 scripts/original-backups/test_dump_required.py --write-promtool-rules /ruta/temporal/vacia
cd /ruta/temporal/vacia
promtool check rules alerts.required-test.rules.yml
promtool test rules dump-publication-required.test.yml
Rollback: retirar sólo OriginalsDumpPublicationRequired del snippet y template. Antes de una deshabilitación intencional del publicador, retirar explícitamente esta expectativa; apagar el flag por sí solo no cancela la obligación. No borrar historial, recibos, métricas ni las otras dos reglas. El despliegue/rollback runtime requiere su fase acotada habitual, con CAS, backup privado, conservación del inode del bind mount y comprobación de evaluaciones.
Validación nativa y despliegue, 02:12 CEST¶
Root publicó la fuente en 4fb2ef8 y ejecutó la fase nativa autorizada. Promtool validó las 87 reglas del candidato completo, la copia temporal de una regla con reloj rebasado y los cinco escenarios: SUCCESS. Se eliminaron exclusivamente los temporales creados para esas comprobaciones. La revisión independiente anterior confirmó que las otras 86 reglas eran idénticas.
El primer preflight abortó antes de escribir al comparar el hash de configuración del host con el de configuración efectiva del contenedor. Ambos hashes (3537… y c8e…) ya diferían y permanecieron intactos; su análisis pertenece a otro informe. No se atribuye esa diferencia a esta regla.
Despliegue por Root el 20 de octubre, 02:12:27–02:12:28 CEST: CAS del baseline 3f0…, flock, backup privado 0700/0600 con fsync en CT217:/root/rollback-immich-dump-required-20261020T001227Z/alerts.yml.before y recibo. Escritura conservando inode 1029537, uid/gid 1000:1000, modo 0664; promtool volvió a validar 87 reglas antes y después. Hash runtime final: <REDACTED>.
El POST de recarga devolvió HTTP 200; la consulta RPC indicó reload=true y lastConfig=2026-10-20T00:12:28Z. Sin restart, cambios en las otras 86 reglas ni notificaciones de prueba. Estado: instalada, recargada y con dos evaluaciones sanas verificadas por Root, documentadas al final. La observación inicial era transitoria: 79/87 reglas con health ok y las restantes aún unknown. No se presenta ese estado inicial como validación final de salud ni como primer éxito de publicación.
Rollback runtime concreto: exigir CAS del hash final indicado y flock; restaurar alerts.yml.before en el mismo inode, conservando propietario y permisos; fsync, validar las 86 reglas anteriores y efectuar la misma recarga. Conservar recibo y backup; comprobar evaluaciones después. No se ha ejecutado rollback ni se han cambiado las dos reglas anteriores de publicación.
Evaluaciones posteriores al reload¶
La consulta de API tras el reload mostró inicialmente79/87reglas sanas y la nueva aún sin evaluar; no se presentó ese estado como validación terminada. Después, dos evaluaciones distintas de Required a00:12:54.064174592Z y 00:13:24.064548809Z mostraron health=ok/state=inactive/lastError=null y 87/87reglas health=ok. La primera publicación automática sigue pendiente11:10; la inactividad previa al plazo no acredita protección ni éxito.