Informes en NetBackup Alta View: detectar backups ausentes

Si tu objetivo es un informe sencillo como "mostrar todos los servidores sin un backup completo en los últimos siete días", no empieces montando un sistema de generación de informes desde cero. La plataforma de informes de NetBackup ya dispone de patrones para clientes sin copia de seguridad en un número configurable de días, y su biblioteca de informes puede ser un punto de partida mucho más rápido que pelearse con un diseñador visual en blanco.

La frustración de los administradores es comprensible. En un debate de la comunidad, Alta View fue calificado de pesado y en ocasiones lento, y otro participante comentó que lograba generar informes a medida en Python más rápido y con mayor control. La petición concreta era elemental: localizar aquellos servidores que llevaban siete días sin recibir un backup completo.

¿Existe ya un informe para clientes sin backup reciente?

Sí. La documentación actual de transición de NetBackup IT Analytics traduce el antiguo concepto de "Clients Not Backed Up" en informes para clientes denominados "Clients with no Backup in X Days" y "Failed or No Backup in 3 days". Ese es prácticamente el mismo caso de uso planteado en el debate.

Por tanto, empieza utilizando ese informe existente y ajusta la ventana o el criterio de backup en vez de volver a crear la consulta entera. Si siete días es tu umbral operativo, introduce ese valor como parámetro del informe o adapta la plantilla para que encaje con él.

Define con exactitud qué significa "sin backup". Un servidor puede tener un backup incremental pero carecer de un completo reciente; otro puede haber lanzado trabajos fallidos repetidamente, y un tercero puede haber sido desmantelado mientras sigue dado de alta en el inventario. Son excepciones operativas distintas y no deben caer en la misma lista sin el contexto adecuado.

La guía sobre la tasa de éxito de backups en NetBackup plantea esta misma cuestión desde la perspectiva de los SLA: un porcentaje solo resulta útil cuando puedes explicar qué clientes componen la fracción que falta.

¿Por qué la creación de informes en Alta View resulta farragosa?

Las herramientas de informes se complican cuando el modelo de datos es mucho más rico que la pregunta concreta que el operador necesita responder. Alta View puede agregar datos procedentes de múltiples dominios de NetBackup, lo que ofrece un valor innegable para la visibilidad global de la empresa, pero una consulta operativa sencilla puede parecer sepultada bajo una infinidad de opciones de configuración.

Los comentarios de la comunidad son directos. Un usuario calificó el entorno de engorroso y señaló que los informes personalizados pueden volverse lentos. Otro prefería apoyarse en Python porque le concedía control total sobre la consulta y la salida de datos.

Ambas posturas tienen sentido. Un diseñador visual tiene que exponer filtros, alcances, rangos temporales, dimensiones, programaciones y estilos de presentación, mientras que un script en Python permite a un administrador con experiencia codificar esa misma lógica sin rodeos. El coste real reside en el mantenimiento: una vez que el script pasa a formar parte del control diario de las copias de seguridad, alguien debe hacerse responsable de sus credenciales, el comportamiento frente a APIs, la gestión de errores, la programación y los cambios de versión. Antes de escribir código, comprueba si la salida que buscas ya existe en la biblioteca de informes.

¿Qué es la Customer Report Library de IT Analytics?

La Customer Report Library es un repositorio de informes creados por la comunidad que se pueden descargar, importar y personalizar. La documentación actual señala que estos informes complementan los más de 300 informes incluidos de serie en NetBackup IT Analytics, cubriendo áreas como copias de seguridad, capacidad, redes de almacenamiento SAN y modelos de imputación de costes (chargeback). Para las operaciones de backup, la biblioteca incluye patrones como el estado de los clientes, éxito de trabajos, tareas detenidas, resúmenes de errores, estado de cintas, excepciones en ventanas de backup y clientes a los que les faltan copias recientes.

Hay que tener en cuenta un matiz: la documentación indica que estos ejemplos comunitarios no reciben el mismo nivel de soporte que las funciones nativas del producto, y algunos informes pueden no encajar en infraestructuras muy grandes o portales de MSP. Trátalos como plantillas que conviene revisar y adaptar antes de darles plena confianza en producción.

Aun así, son infinitamente mejores que enfrentarse a un lienzo en blanco. Aportan las relaciones de datos adecuadas y una estructura de consulta funcional que puedes poner a prueba frente a tu propio entorno.

¿Cómo debe definirse un informe de "sin backup completo en siete días"?

Delimita la excepción en términos operativos antes de interactuar con el diseñador de informes. La regla más limpia se resume así: los clientes de producción activos que deben recibir un backup completo deben contar al menos con un backup completo finalizado con éxito en los siete días naturales anteriores.

Esa definición introduce de inmediato varios filtros necesarios. ¿Qué clientes se consideran activos? ¿Qué tipos de directiva se computan? ¿Se incluye un backup completo sintético? ¿Qué ocurre con los planes de protección de aplicaciones? ¿Se excluyen los servidores de pruebas? ¿Cómo se gestiona un cliente pausado deliberadamente por mantenimiento?

Sin definir estas variables, el informe puede ser técnicamente exacto pero inútil en la práctica. Señalará sistemas que nadie espera proteger u ocultará máquinas que tienen copias incrementales correctas pero ningún punto de restauración completo aprovechable.

Aquí es además donde la gestión de licencias y la limpieza del inventario se cruzan con los informes. La guía de capacidad y licencias FETB en NetBackup explica cómo los registros de clientes duplicados u obsoletos pueden distorsionar la visión del entorno, y la generación de informes se beneficia de esa misma labor de saneamiento.

¿Conviene utilizar Alta View, IT Analytics o un script en Python?

Utiliza la capa de informes del propio producto cuando el requisito sea habitual, compartido y deba ser consultado por más de un equipo. Recurre a código propio cuando la lógica sea extremadamente particular, la salida deba alimentar otro sistema o el modelo de datos integrado no permita expresar la condición con claridad.

Un informe en Python resulta una excelente solución para un equipo de operaciones que ya mantenga herramientas internas. Puede enviar una lista resumida al sistema de tickets, enriquecer los clientes con información de propietarios de la CMDB y aplicar reglas de exclusión específicas del negocio.

Sin embargo, el código a medida genera una dependencia directa de quien lo escribió. Un informe que nace como un script de diez líneas suele ir sumando autenticación, reintentos, paginación, formato CSV, envío de correos, registros de actividad y captura de excepciones. Eso es asumible siempre que el valor que aporta compense el esfuerzo.

La solución intermedia suele ser la más acertada: empieza con la biblioteca de informes estándar o de clientes, valida la definición exacta de la excepción y automatiza por fuera únicamente aquellos aspectos que la herramienta de informes no resuelva bien.

¿Por qué puede degradarse el rendimiento de los informes en entornos grandes?

El debate original refleja lentitud pero no identifica una causa raíz concreta, por lo que sería un error responsabilizar a un único componente. El rendimiento de un informe puede verse afectado por el volumen de datos consultado, el período de retención del histórico, la cantidad de dominios conectados, la complejidad de la plantilla y el nivel de agregación que exige la consulta.

Empieza acotando la consulta a un único dominio de NetBackup, un grupo reducido de clientes y una ventana temporal más corta. Si la respuesta es rápida, amplía el alcance de forma gradual hasta detectar cuándo surge la lentitud. Eso te aclarará si el fallo radica en el volumen de datos o en la propia definición del informe.

Compara además un informe predeterminado frente a uno personalizado sobre el mismo ámbito. Si ambos van lentos, investiga el rendimiento general de la plataforma y los procesos de recolección de datos. Si el informe nativo es rápido y el personalizado es lento, el problema está en la plantilla.

No optimices el diseño visual antes de consolidar la lógica de la consulta: un informe que entrega con rapidez una lista de clientes equivocada sigue siendo un informe erróneo.

¿Qué debe incluir en realidad un informe diario de backup que resulte útil?

Un informe de excepciones eficaz ayuda al operador a decidir qué acción tomar a continuación. Conviene incluir el nombre del cliente, la fecha y hora del último backup completo con éxito, la fecha y hora de la última copia de seguridad exitosa de cualquier tipo, el estado del fallo más reciente, la directiva o plan de protección correspondiente y suficiente contexto del propietario para canalizar el incidente.

Evita convertir el informe en un listado interminable de cada tarea completada con éxito, ya que su propósito es hacer visibles las anomalías. Si el equipo gestiona 9,000 procesos de backup al día, un informe con 8,900 éxitos resulta mucho menos accionable que una lista clara con los 100 sistemas que demandan atención inmediata.

Añade el estado de desmantelamiento si los datos lo permiten. Una razón muy habitual por la que las tasas de éxito en backup no alcanzan el 100 por ciento es que hay servidores retirados sin que nadie avise al equipo de backup, de modo que el informe debe diferenciar entre "fallo de protección" y "equipo ya inexistente".

Mide además la evolución del propio informe. Si la lista diaria de excepciones no para de crecer, el proceso ha descubierto un fallo de gobierno, y lo que se necesita es un responsable que lo solucione y no otro panel de control más.

¿Qué solución elegiría para el caso del backup completo a siete días?

Primero importaría o revisaría el patrón de informe "Clients with no Backup in X Days" y lo adaptaría a copias completas con una ventana de siete días. Luego validaría los resultados frente a un grupo de clientes de control conocido antes de programar su envío recurrente.

Si el diseñador de informes continúa complicando la lógica de forma innecesaria, utilizaría Python para el flujo final de detección de excepciones, pero dejando documentada la definición del informe en lenguaje claro para que el script no sea el único lugar donde resida la regla de negocio.

Alta View e IT Analytics demuestran su valor cuando acortan el tiempo transcurrido entre un backup no ejecutado y su corrección técnica. El mejor informe es el que indica con fiabilidad al equipo de backup qué servidores incumplen las políticas hoy, sin importar lo austero que sea su formato visual.