Monitorización de los procesos de backup mediante datos en una bbdd SQL

Disponer de una herramienta de monitorización de los procesos de backup simplifica y de qué manera esta tarea. No es nada que no hayamos contado ya. La realidad es que podemos gestionar de forma manual el proceso de verificación de las copias de seguridad accediendo a la consola del software que usemos y comprobando qué elementos haya en su configuración (nodos, copias, catálogos, etc).

Pero, ¿y si el resultado de este proceso se pudiera recoger de forma automática? Imagina que cada mañana recibes un correo que te informa con todo lujo de detalles del estado de este asunto.El servicio de monitorización te permite automatizar la recogida de estos datos y que, posteriormente, lleguen a tu buzón.

Cómo automatizar la monitorización de los procesos de backup

La metodología que explico a continuación es aplicable a diversas tecnologías, dado que para obtener todo este escenario usaré herramientas estándar tales como snmp, wmi o Microsoft SQL.

1. Como partners de Paessler, utilizamos PRTG para la monitorización. Este producto nos permite atacar de distintas formas los diferentes elementos que sean susceptibles de monitorizar. En este caso, te mostraré cómo atacar desde PRTG Paessler contra la base de datos SQL de Arcserve Unified Data Protection (UDP).
2. Tras darle algunas vueltas, decidí que los resultados del backup aún se podían atacar mediante un sensor IMAP contra un buzón de correo. Éste revisaba el contenido del buzón para buscar las palabras “backup incorrecto” (por ejemplo). Pero me pareció que podría haber un método más específico que no dependiera de elementos como el cambio de  contraseña del usuario del buzón, que el buzón se llenara y el sensor fallara, etc.
3. Finalmente, decidí que lo mejor era atacar contra la base de datos del fabricante de backup para poder recabar un resultado más certero.

Arcserve no brinda en su web la información API y estructura de base de datos de su producto UDP, algo que, hasta cierto punto, es normal. Se trata de información destinada a partners (como nosotros) y departamentos de TI avanzados que dispongan del producto.

Mediante estos dos documentos, pude hallar el origen de dos elementos básicos. Por un lado, el “agentID”, que no es más que el identificativo interno de UDP que le asigna a cada máquina que forme parte de un plan de backup (diario, semanal, etc), verificado en la tabla “as_edge_host” que nos relaciona el ID con el nombre de máquina. Y por otra parte, un resultado que ofrece la tabla “as_edge_d2dJobHistory_lastJob”.

Esta última tabla, como su propio nombre indica, recopila la información relativa al estado del último backup realizado, siendo 1 correcto, 2 advertencia y 3 erróneo. Por lo tanto, bastaba con crear una instrucción SQL que permitiera revisar el estado del último backup de un “agentID” y forzando a forzar dar solamente el último resultado.

En esta query, ponemos como ejemplo un “agentId” que tiene como valor “16”, porque como hemos dicho anteriormente, en la tabla “as_edge_host” hemos verificado qué “agentId” corresponde a cada máquina. Este valor es el que usamos como referencia, dado que la tabla “as_edge_d2dJobHistory_lastJob”, no contiene el campo de hostname de equipo.
Por lo tanto, nos estará dando el valor numérico del último backup que se ha realizado de la máquina “16” (“agentId”).

Con esto, tenemos en nuestro buzón, el resultado claro y conciso del último backup. Y en la consola de monitorización, tenemos una visualización del entorno de backups: