SyntaxHighlighter

Mostrando entradas con la etiqueta copias de seguridad. Mostrar todas las entradas
Mostrando entradas con la etiqueta copias de seguridad. Mostrar todas las entradas

viernes, 21 de marzo de 2014

Data Protector. Recuperación usando la directiva POST-EXEC y SCRIPTING

Con Data Protector podemos programar una agenda de copias de seguridad fácilmente usando la GUI Java, lo que no es tan simple es planificar una calendario de restauración que, por ejemplo, recupere la última copia de seguridad realizada en otra localización.

La primera aproximación sería intentar ejecutar esta restauración llamando al programa omnir con los argumentos necesarios e incluir la llamada en el cron del servidor para que se ejecute periódicamente. Lo que a priori parece algo sencillo se complica con sólo mirar la la página de manual de omnir (o buscar "data protector cli reference" en cualquier buscador). El Backend de comandos de Data Protector da toda la funcionalidad que necesitamos para restaurar una copia de seguridad, pero es necesario la ejecución de varias órdenes para "montar" los argumentos que necesita omnir.

Hay otro problema en cuanto a la inclusión en cron de esta orden podría dar lugar a solapamientos en el uso de la unidad sobre la que estemos haciendo la copia de seguridad.

Imaginad que la copia de seguridad programada comienza a las 2:00 am, y nuestra orden de restauración se ejecuta vía cron a las 4:00 am. Si la copia de seguridad tarda más de 2h, la restauración se podrá en cola. Pasado cierto tiempo de espera configurable en Data Protector, si aún no ha comenzado el trabajo de restauración, se procederá a su cancelación. Esto se puede evitar usando las opciones POST-EXEC y PRE-EXEC del trabajo de copia de seguridad.

Estas dos opciones se encargan de ejecutar un script en el cliente de data protector que indiquemos antes (PRE-EXEC) o después (POST-EXEC) de que se realice el trabajo de backup. El uso más extendido de estas dos opciones es el de parar un servicio antes de realizar el trabajo de copia y levantarlo después.

Para conseguir el comportamiento que necesitamos lo ideal sería ejecutar un script en POST-EXEC que llame a omnir con los datos de la última copia de seguridad. Para conseguir los datos necesarios de la última sesión de copia de seguridad hay que ejecutar la orden onmidb, que consulta la BD de Data Protector para extraer la información que requiere omnir:

/opt/omni/bin/omnir -filesystem [datalist] [label] -session [session] -tree [path] -as [target_path] -target [target_client]

Pasos del script:
  1. Considera un número de días hacia atrás desde la fecha actual para buscar la última sesión de la agenda especificada.
  2. Determinar sesión más reciente que se terminó satisfactoriamente en el intervalo definido en el paso anterior.
  3. Buscar el árbol de directorios que queremos restaurar y extraer el datalist y label, argumentos necesarios para ejecutar omnir.
  4. Ejecutar omnir con los parámetros adecuados.
El código del script (un poco sucio):

#!/bin/bash
OMNI_PATH=/opt/omni/bin/

if [ $# -ne 5 ]; then
  echo "Ilegal number of arguments" >&2
  echo "Use: $0 [dataList] [label] [targetClient] [targetDir] [RestoreOnlyIfFull 0/1]" >&2
  exit 1
fi

ARG_DATALIST=$1
ARG_LABEL=$2
ARG_TARGETCLIENT=$3
ARG_TARGETDIR=$4
ARG_ONLYFULL=$5
DAYSTOINSPECT=30

INITIALDATE=$(date '+%Y/%m/%d' --date="${DAYSTOINSPECT} days ago")
LASTSESSION=$(${OMNI_PATH}omnidb -session -datalist $ARG_DATALIST -since $INITIALDATE | grep -i backup | grep -i completed | tail -n1 | cut -f 1 -d " ")
FILESYSTEM=$(${OMNI_PATH}omnidb -session $LASTSESSION | grep \'${ARG_LABEL}\' | cut -f1 -d " ")
LABEL=$(${OMNI_PATH}omnidb -session $LASTSESSION | grep \'${ARG_LABEL}\' | cut -f2 -d " ")
BACKUP_LEVEL=$(${OMNI_PATH}omnidb -filesystem $FILESYSTEM ${ARG_LABEL} -session $LASTSESSION | egrep -o "Incremental|Full")

if [ -z "$LASTSESSION" ]; then
 echo "Session not found: $ARG_DATALIST. Available schedules:"
 ls /etc/opt/omni/server/schedules >&2
 exit 1
fi

if [[ $ARG_ONLYFULL -eq 1 && $BACKUP_LEVEL != "Full" ]]; then
 echo "Mode is set to full but cannot find full backup" >&2
 exit 1
fi

if [ -z "$LABEL" ]; then 
 echo "Label not found: $ARG_LABEL. Backed up filesystems and labels:"
 omnidb -filesystem >&2
 exit 1
fi

#Print command options
echo "Restoring label: ${LABEL}, filesystem: < $FILESYSTEM > from Session: $LASTSESSION into ${ARG_TARGETCLIENT}:${ARG_TARGETDIR}, backup_level: $BACKUP_LEVEL"
#Print omnir command used to perform the restore job. Debug.
echo ${OMNI_PATH}omnir -filesystem ${FILESYSTEM} ${LABEL} -session ${LASTSESSION} -tree ${ARG_LABEL} -as ${ARG_TARGETDIR} -target ${ARG_TARGETCLIENT}
OMNI_COMMAND="${OMNI_PATH}omnir -filesystem ${FILESYSTEM} ${LABEL} -session ${LASTSESSION} -tree ${ARG_LABEL} -as ${ARG_TARGETDIR} -target ${ARG_TARGETCLIENT}"
eval $OMNI_COMMAND

Si a la orden omnir que se llama al final del script añadimos -full antes del argumento -filesystem se restaurará una copia completa del árbol de directorios usando la última copia completa que se realizó y todas las incrementales hasta la sesión que estamos restaurando. De otra manera sólo se restaurarán los ficheros que se respaldaron en la sesión en cuestión.  El último argumento del script controla los problemas que se puedan derivar de esto: sólo se ejecutará la restauración si la última copia ha sido full.

No está de más ejecutar el script comentando la última línea (eval ...), para comprobar que todo es correcto antes de empezar a utilizarlo. Si alguno de los parámetros no es correcto imprimirá posibles soluciones.

Por último, el directorio en el que tenemos que incluir el script para que no haya problemas es /opt/omni/lbin y así podremos llamarlo sin usar path completo, algo que parece que no funciona bien si configuramos el POST-EXEC desde la GUI Java.

NOTA. Si la restauración toma demasiado tiempo, Data Protector puede abortar el Script. Para evitarlo se puede modificar la opción ScriptOutputTimeout en el fichero /etc/opt/omni/server/options/global

martes, 25 de enero de 2011

Backup con Data Protector: Estructura del Software e Instalación


Data Protector, como otras soluciones de copia de seguridad, se compone de varios módulos que separan la funcionalidad de la herramienta:
  • Cell Manager (CM). Es el componente principal, el más “pesado”. Coordina al resto de componentes y es el único que tiene consciencia de todas las máquinas y dispositivos asociados al sistema de backups.
  • Disk Agent (DA). Este agente ha de estar ejecutándose en todas las máquinas que enviarán datos a la copia de seguridad. Es el componente que responde a las llamadas del CM en cada una de las máquinas.
  • Media Agent (MA). Responsable de la gestión del dispositivo que de almacenamiento donde seguardarán las copias de seguridad. En nuestro caso una HP MSL2024.
  • Installation Server (IS). Componente que se encarga de hacer instalaciones en las distintas máquinas del resto de componentes.
  • GUI/JAVAGUI. Podemos instalar una interfaz gráfica para controlar todo el sistema en una o varias maquinas. La verdad es que nos facilitará bastante el trabajo ya que la interfaz “command line” es enorme y bastante compleja (aunque al final siempre necesitas recurrir a ella en ciertos momentos).

La instalación se realiza con la orden:

./omnisetup.sh -cm -is -ma

Indicamos que se instale el Cell Manager, el Installation Server y el Media Agent en la misma máquina.

Hay que tener muy en cuenta que Cell Manager requiere para su instalación un SO de 64bits. Un problema que tuvimos que solucionar reinstalando nuestro REDHAT ya que teníamos un kernel 32bits-PAE. Para el resto de componentes no es necesario, dando bastante flexibilidad a la hora de instalar en distintas plataformas.

Una vez instalado el Installation Server se pueden hacer instalaciones remotas si se indica la IP del cliente y su password siempre que la máquina permita la ejecución remota (rexec-rlogin), no obstante, según el sistema cliente tendremos más o menos problemas para hacer este tipo de instalación. La solución es fácil: instalar con el CD de instalación en cada máquina los componentes deseados y después añadirlos al Cell Manager.

Algo bastante confuso con respecto a la instalación con los Cds es el hecho de que la instalación de la Interfaz Java (javagui) deba hacerse con el CD correspondiente a la versión HP-UX del software. En la versión Linux no se ha incluido este paquete.

La orden instala la gui:

./omnisetup.sh -cc -javagui

Y para las máquinas que enviarán datos a la copia de seguridad en caso de que no se haga la instalación remota usando Installation Server:

./omnisetup.sh -da

Data Protector y GFS2

Primer problema con el software: Informa de un error cuando se intenta incluir en la copia de seguridad una unidad GFS2 montada en el sistema... ¡Pues empezamos bien!

Que malvados estos de HP, GFS2 aparece como sistema de archivos soportado en la documentación, pero si lees la letra pequeña te das cuenta que es mediante un parche que hay que pedir directamente a los ingenieros de HP.

Me pongo en contacto con HP para que me envíe el parche y un amable ingeniero me envía el parche (SSPLNX611_001) que activa el soporte GFS2. Aplicamos el parche y por fin tenemos acceso a la compartición GFS2 que actúa como espacio común de los nodos del cluster.


En esta figura se ve la estructura:

  • El servidor con el Cell Manager, Installation Server y Media Agent instalados.
  • La unidad de cinta que guarda las copias.
  • Tres nodos que comparten un almacenamiento GFS2. Todos ellos con el Disk Agent funcionando, pero tan solo uno de ellos respalda el sistema GFS2.

Dejo aquí el artículo y vuelvo otro día con algunos conceptos sobre copias de seguridad en Data Protector: Los Pools, la programación de copias, etc.

domingo, 24 de octubre de 2010

Backup con Data Protector: Evaluación


Las copias de seguridad son un concepto a tener muy en cuenta en cualquier actividad relacionada con las TICs. Hay una gran variedad de soluciones disponibles, tango libres como privativas. Algunas de las más importantes son:
Después de evaluar algunas de ellas nos hemos decidido por Data Protector aunque también nos recomendaron el software de CommVault y descartar Bacula por ser algo más complejo de mantener y sobre todo porque no nos aseguraba al 100% la compatibilidad con nuestro hardware (HP MSL2024) y no dispone de un servicio técnico.

El problema de esta suite es que para sacarle todo el partido necesitas tener el sistema operativo de HP (HP-UX) en al menos la máquina en la que se instale el CELL MANAGER (componente central de Data Protector).

En el próximo artículo explicaré la instalación del software.