Manifest y verificación de integridad al crear un backup (v1.69.0 · task #236 PR-1)

User value

Hasta v1.68.x, generar un backup no comprobaba el resultado: el ZIP se daba por bueno por el mero hecho de existir. Desde v1.69.0, cada backup (manual o automático nocturno) lleva dentro un inventario de sí mismo —cuántos racks, equipos, planos, imágenes, etc. contiene, con una huella criptográfica del contenido— y, nada más generarse, el sistema lo relee del disco y comprueba que lo declarado coincide con lo real. Si algo no cuadra (fichero truncado, imagen que falta), el backup se descarta y la operación termina en error visible, en vez de entregar una maleta rota que se descubre corrupta el día del restore.

De propina, la revisión destapó que el backup automático nocturno y el manual habían dejado de ser idénticos: el nocturno guardaba menos información de la que debía (sin script_templates, device_profiles recortados a 10 campos de ~40, blueprints sin mode/sort_order, credenciales SNMP en forma cifrada no restaurable) sin que nadie lo supiera. Ahora ambos backups salen del mismo molde y esa deriva no puede repetirse.

Cómo usarla

No requiere acción del usuario: la verificación es automática en cada backup, manual (Config → Full System Backup) o del cron nocturno.

• Backup manual con éxito: el job termina en done con verified: true y los conteos por entidad en el resultado.
• Backup manual fallido en verificación: el AsyncJob termina en error (“Backup failed integrity verification. Please try again.”), el ZIP corrupto se borra del disco.
• Backup automático nocturno fallido en verificación: generate_backup() devuelve None, el ZIP se borra, se loguea el error — el cron sigue con la siguiente organización.

Implementación

• [[entity—core—service—backup-verify]] — build_manifest() / verify_backup_zip(), el núcleo de la verificación.
• [[entity—racks—service—run-full-backup]] — write_full_backup_zip() (punto único de generación) ahora construye el manifest con los mismos bytes escritos; run_full_backup() verifica tras escribir.
• [[entity—core—service—backup-service]] — generate_backup() (backup automático nocturno) dejó de duplicar el serializador (~230 líneas retiradas) y ahora delega en write_full_backup_zip() + verifica igual que el manual.
• [[entity—racks—endpoint—backup-full-start]] / [[entity—racks—endpoint—backup-full-download]] — endpoints del flujo async que exponen el resultado verificado.
• [[feature—racks—backup-restore-async-v156]] — el flujo async sobre el que se apoya esta verificación.
• [[feature—racks—full-backup-tenant-scoping]] — el scoping de uploads que el manifest ahora también contabiliza.
• [[feature—backup-restore—additive-restore-confirmation-v1-66-2]] — la feature hermana del lado restore; esta verificación es la base de la fase 2 (PR-2, aún pendiente) de restore selectivo con informe de verificación.

Commits relacionados

• 0bc49bb1 — feat(backups): manifest + verificación de integridad en la creación (task #236, PR-1) - v1.69.0 (#396) — 2026-08-20.

Nota de postura (seguridad)

Los ZIP automáticos en disco del servidor llevan ahora las credenciales SNMP en claro, igual que el backup manual (extensión de la decisión T1 ya vigente para el manual). Viven en el volumen media con acceso root, mismo perímetro que la base de datos.

Véase también

• [[entity—core—service—backup-verify]]
• [[entity—core—service—backup-service]]
• [[entity—racks—service—run-full-backup]]
• [[entity—racks—endpoint—backup-full-start]]
• [[entity—racks—endpoint—backup-full-download]]
• [[feature—racks—backup-restore-async-v156]]
• [[feature—racks—full-backup-tenant-scoping]]
• [[feature—backup-restore—additive-restore-confirmation-v1-66-2]]