Notas pre-implementación de Data Protector 6

Esta semana tomé el curso u1620s (HP Data Protector 6 Software Fundamentals). Tengo en este caso una panoramica muy buena de las capacidades reales del software más allá de lo que se puede ver en los datasheets y los manuales. Particularmente para trabajar sobre plataformas *nix, si es que no se tiene una infrastructura distribuída, añade poco a las características de otro soft de backup, libre o no.

Lo que puede ser realmente útil es la capacidad de administración del sistema casi a puro golpe de click, ello si bien no incorpora gran ganancia para los *nix users acostumbrados a navegar entre puertos ssh y largos archivos de configuración de herramientas de backup y administración, en cambio deja al soft en posición perfecta para ser un punto de operación de infraestructura: ya habiendo montado eficazmente la infraestructura de backup y con los manuales de procedimientos bien aceitados (y lo más cortos posible), se puede asignar la tarea de realización y control de backups a operadores, incluso a varios, ya que el subset de skills necesario para operar Data Protector es mínimo (vs. el necesario para instalar, configurar y administrar). Para ello el software colabora con la capacidad de incorporar al sistema credenciales para usuarios de menor privilegio.

Lamentablemente, un soft de backup de este nivel implementado en una gran infraestructura (desde decenas de servidores en adelante), tiende a necesitar un poco más de atención que la de un operador. Por ello es recomendable limitar las funciones de los operadores a celdas de backup a lo sumo (una celda en Data Protector es equivalente a un servidor de backup y puede interconectarse varias celdas en un solo gran sistema).

La tarea para el (verdadero) administrador consiste entonces sí en subir varios niveles de dificultad y avanzar en el control de las posibilidades problematicas que estén dadas según el nivel de complejidad en el subconjunto de funciones de Data Protector elegidas para ser usadas en una implementación particular (en difícil usar el 100%). Igualmente esto se puede planificar y documentar apropiadamente y así no estaremos nunca en situación de verificar los posibles problemas en el marco del 100% de las posibilidades funcionales de la herramienta.

Una limitación práctica de Data Protector dada desde antes de configurar nada: no soporta scheduling ala CRON, no se puede configurar la herramienta para correr backups, por ejemplo, todos los primeros lunes de cada mes...a menos que se configure doce veces las fechas del año que coinciden con el primer lunes de cada mes (y así sucesivamente, año a año). Esto a la versión 6, al último parche disponible hace un par de días cuando terminamos el curso.

Otra limitación práctica: el soporte para backup en Linux, en herramientas FOSS (DB Postgresql, DB Mysql, etc.), y en tareas de DI (Disaster Recovery) está a la misma altura que la de cualquier software de backup FOSS (Amanda y Bacula por ejemplo). Ninguna de las funciones de backup en línea para software está soportada para varias DB FOSS, ni para la mayoría de las herramientas comerciales típicas en sus versiones para Linux.

En particular para mi diseño de implementación particular, voy a tener que prescindir del uso del scheduler de Data Protector y correr los sets de backup configurados desde el server vía CRON. Es decir, en la práctica es exactamente lo mismo que correr los backups vía scripting+CRON (añadiendo catalogos y compresión con tar.bz2 opcionalmente).

La característica de backup on-line para herramientas puede suplirse con snapshots LVM por ejemplo, haciendo un uso adecuado de las características de backups y consolidaciones virtuales en Data Protector. Adicionalmente es para considerar la situación en que un software/servicio particular es "snapshoteado" y luego traído de vuelta a la vida (ciertamente en un /etc/init.d/servicio start, manual), luego de una restauración, a poner cuidado entonces de a qué le aplicamos snapshots y hacer testing exhaustivo (la mayoría del soft, FOSS o no, no tiene referencias de este tipo de stop-start de funciones, más allá de comentarios en foros).

Las características puntuales de backup y restauración en Linux de Data Protector que ya se aprecian desde los datasheets y ahora veo confirmadas son el que permite realizar backups mediante agentes, seleccionando vía click desde un servidor central qué directorios y/o archivos se quiere resguardar. En el momento de la restauración los agentes podrán sobreescribir o no archivos, a elección del admin u operador.

Volviendo un poco a las ausentes características de DI (Disaster Recovery) para Linux, veo que en el momento de restaurar un server desde cero, no habrá posibilidad de restauración Bare Metal directo desde un dispositivo externo (disco, usb, cinta), sino que habrá que instalar el SO (y ello implicará su correspondiente configuración y actualización), luego el agente DP, realizar la conexión con el server DP y luego sí proceder a la restauración de casi seguramente centenares de gigas vía un enlace de red (algo que se complica cuando tienes tu server a restaurar a varios centenares de kilométros del punto de origen de la comunicación vía TCP).

Esto último caso de restauración remota es parcialmente solucionable backupeando un "esqueleto" en varios sets de backups, uno por server. Cada esqueleto de configuración permitiría bajar bastante el downtime evitando bajar a configurar /etc y otros directorios y archivos (sea vía CLI o con GUIs de administración), de configuración si hubiera algun otro soft externo a la distribución implementado.

Quedaría pendiente entonces la cuestión de la imposibilidad práctica de backpear los binarios (parte de los cuales se debería actualizar regularmente, vía parches de seguridad principalmente) para una restauración vía medios externos (dvd, usb, cinta) e independientes de Data Protector y una conexión (rápida) de red (...podrías llevarte el DP, la unidad cinta hasta el server remoto, instalar todo y realizar la restauración ahí mismo...mmm).
Una solución de compromiso consiste en instalar y actualizar todo el sistema operativo, instalar binarios de herramientas externas y luego aplicar los backups de configuraciones ("esqueletos") antes mencionados. Esto último facilitaría mucho un DI en servers remotos, pero hay que contar con un enlace razonable a Internet para actualizar el SO (vía VPN se podría conectar Data Protector y realizar los transportes necesarios más rápidamente que usando los típica y potencialmente más lentos enlaces WAN; y sí, el operador on-site debería ser capaz de configurar este link VPN o seguir instrucciones paso a paso, queda anotado como ítem del manual de procedimientos DI).

Definitivamente la imposibilidad de configurar sets de Bare Metal (aunque fueran a discos/storage, disponibles para grabar a medios trasladables vía camión por ejemplo), va a complicar en exceso una restauración remota, aunque no mucho más de lo que sería el caso si se estuviera usando software FOSS (baks .tar.bz2 en un dvd por ejemplo). Recuerdo que existe software FOSS que permite realizar backups bare metal, a dvd usualmente, pero normalmente es complicado de manejar para operadores y debe ser corrido on-site sobre el servidor.

No hay que olvidar el amplio soporte para librarías y dispositivos de almacenamiento para grandes volumenes de información, así como la facilidad de configuración y administración de dichos recursos, algo que en soluciones FOSS y/o manuales puede dar dolores de cabeza si no se planifica con excesivo cuidado.

En conclusión las caracterísiticas técnicas puntuales que pueden llevar a elegir DP son sus características avanzadas de administración vía GUI. Adicionalmente y ello es crítico en el momento de la selección de herramientas y hardware, DP brinda una lista de soporte de hardware en el que el selector tiene garantizado la integración fina con la herramienta y sus funciones administrativas.