Backups NDMP.

Bueno, pues voy con otra entrada relacionada con el backup y el almacenamiento.

Si como en mi caso, administras filers de NetApp lo mejor para realizar un backup muy rápidamente es utilizar el protocolo NDMP.

De forma resumida, cada vez que se lanza el backup de un volumen o qtree, aunque lo recomendado es hacer backups NDMP solo de volúmenes, ONTAP hace un snapshot de dicho volumen, lo convierte en un stream de datos y lo envía por red al servidor de backup el cual lo escribirá en disco o cinta.

Hasta aquí todo muy bien, el backup no tarda mucho pero ¿y cuando queremos recuperar algo de esos backups NDMP? Entonces amigos es cuando llega la lentitud, pero lentitud muy lenta. Por como funciona el protocolo NDMP y como debe recuperarse la información del sistema de archivos WAFL, nos encontramos que incluso para recuperar un mísero archivo de 1 KB es necesario que nuestro querido Legato lea tooooodo el backup correspondiente para poder hacer la recuperación. Como referencia, aquí os pego lo que dice la guía de administración de Legato NetWoker 8.1 SP1 en su página 683:

By default, the NDMP recover process reads an entire tape from start to finish. The recover
process extracts the data as it encounters the data on the tape. For large backup images,
recovery is slow.

Lo de recovery is slow se queda corto la verdad. Así que, para mejorar bastante el tiempo de las recuepraciones, hay un par de variables de entorno a utilizar siempre que queramos hacer una recuperación NDMP. Estas variables las exportaremos con nuestro querido comando export cuando estemos usando el comando recover en Unix/Linux, o tendremos que fijarlas como variables del sistema en nuestro Windows.

Las variables son:

NSR_NDMP_DAR=y

NSR_NDMP_DDAR=y

y al usarlas Legato irá al punto de la cinta exacto donde está la información que queremos recuperar, lo cual nos ahorra el leer todo el backup para poder recuperar un simple fichero y ahorra bastante tiempo.

Saludos.

Snapshots en plataformas VNX

Hace unos meses recibimos un VNX5200 con el que llevo pegándome desde entonces. Mientras espero a recibir el curso correspondiente, que debería ser en breve, estoy investigando la plataforma y sus características.

Una de las cosas que más me ha llamado la atención, sobre todo viniendo de plataformas NetApp, es que, aunque se pueden hacer snapshots, no hay un scheduler de los mismos como en Data ONTAP y que hay que hacer bricolage para programar tus snapshtos y controlar su expiración.

Afortunadamente EMC proporciona para todos los sistemas operativos una herramienta muy interesante, el comandito naviseccli el cuál, una vez instalado, te deja hacer practicamente de todo.

Así, para listar las LUNs existentes en el sistema, basta con utilizar un comando tan cómodo como el siguiente:

/opt/Navisphere/bin/naviseccli -User USUARIO -Password PASSWORD -Scope 0 -Address DIR_IP lun -list
 

Con lo que, si queremos hacer snapshots es necesario que nos curremos un script que se encargue de hacer el snapshot de todas las LUNs que hayamos creado.

Para los snapshots el subcomando que hay que usar es snap, quien lo hubiera dicho, el cuál tiene bastantes opciones.

Subcomando snap y opciones

Viendo la salida del subcomando snap solo necesitamos crear un script en el que, con la opción -create, podremos hacer los snapshots de nuestras LUNs. Para controlar la expiración y borrado automático de esos snapshots, usaremos la opción -keepFor especificando el tiempo que deseémos mantener el snapshot. Por ejemplo, para crear el snapshot de una LUN y mantener dicho snapshot 15 días el comando será:

/opt/Navisphere/bin/naviseccli -User USUARIO -Password PASSWORD -Scope 0 -Address DIR_IP snap -create -res LUN_ID -name NOMBRE_SNAPSHOT -keepFor 15d

Todo esto en un bonito shell script controlado por nuestro viejo amigo crontab y ya tenemos snapshots de las LUNs de nuestro VNX5200.

Seguiremos investigando.

Backups incrementales de Exchange 2010 promocionados a full

Bueno, pues voy a hacer la primera anotación técnica de un problemilla que acabamos de tener y la primera entrada de la sección de backup.

Soy el responsable de backup y usamos EMC Legato NetWorker, el cual he actualizado hace poco a la versión 8.1.1 SP2 y me he encontrado que todos los backups de Exchange 2010 de un determindao grupo de backup, independientemente del schedule configurado, son promocionados a full. La versión de NMM en los clientes es la 2.4.1.

Curiosamente esto ya nos sucedió hace un tiempo, también con Exchange 2010 pero con un DAG y un grupo de backup diferente, pero no recordaba como lo solucionamos.

Afortunadamente, la magia del buscador de la web de soporte de EMC me ha recordado que el problema, por raro que sea, tiene que ver con la configuración del pool de cintas a utilizar para los backups. De forma resumida este problema se produce si, en la confgiruación de los clientes miembros del grupo de backup configuramos el pool de cintas así como en la definición del grupo. Es decir que para que esto no suceda el campo Pool de la configuración de los clientes debe estar vacío:

Configuración del cliente

Pero en la configuración del grupo de backup si es necesario definir correctamente el pool de cintas, que será además de tipo snapshot por tratarse de un backup de Exchange:

Configuración del grupo de backup

Pues si niños, si defines en dos sitios el pool de cintas a utilizar, para backups de Exchange 2010 con NMM 2.4.1 y Legato NetWorker 8.1.1 SP2 conseguiréis qur los backups incrementales de Exchange 2010 se conviertan en unos bonitos full.

Saludos.