Recuperación de directorios y ndmpcopy.

Hoy volvemos con una nueva entrada relacionada con la protección de datos en nuestros sistemas ONTAP, con lo que vamos a recordar dos herramientas fundamentales, snap restore y ndmpcopy las cuales nos permitirán recuperar información cuando sea necesario.

Mediante snap restore podemos recuperar información de los snapshots existentes en un volumen, mientras que ndmpcopy nos permite copiar datos entre SVMs e incluso con la configuración adecuada, entre diferentes clusters.

Por ejemplo, para los casos en los que queremos recuperar un fichero, podemos usar snap restore-file del siguiente modo:

Recuperación de un fichero desde un snapshot.

En caso de que necesitemos restaurar todo un volumen, el comando que usaremos será snap restore, el cual recuperará todos los datos del volumen al estado en el que se encontraba en el momento de creación del snapshot correspondiente. Por ejemplo:

Recuperación de un volumen completo a partir de un snapshot.

Es muy importante tener en cuenta los siguientes puntos en el caso de recuperación de un volumen completo:

1. Al restaurar un volumen completo de un snapshot determinado, si el snapshot elegido no es el último, cualquier snapshot posterior se borrará.
2. Las cuotas establecidas en qtrees pueden ser diferentes entre el volumen y el snapshot, con lo que será necesario revisarlas tras la recuperación y reinicializar las cuotas en dicho volumen en caso de ser necesario. 
3. Es necesario revisar las políticas de exportación NFS por si son diferentes entre el volumen y el momento del snapshot usado para la recuperación.

En determinadas ocasiones necesitaremos recuperar  un directorio completo y en ese caso, nos encontramos con el siguiente problema al usar snap restore-file:

Error al intentar recuperar un directorio mendiante snap restore-file.

Por tanto, además de copiar y pegar directamente el directorio desde el snapshot correspondiente accediendo al mismo desde el directorio .snapshot, ¿que otra opción tenemos? Podemos usar el comando ndmpcopy como vamos a ver a continuación.


Para poder usar este comando correctamente, primero es necesario añadir el protocolo ndmp a la SVM, para lo cual solo necesitamos modificar los protocolos de la misma añadiendo el protocolo ndmp:

Modificamos los protocolos del vserver.

A continuación iniciamos el servicio ndmp en la SVM y generamos una password para el usuario que utilizaremos para el proceso de copia:

Iniciamos el servicio ndmp y generamos la password.

Ya solo nos queda ejecutar el comando ndmpcopy para restaurar el directorio, con todo su contenido, desde el snapshot deseado. Para este comando es muy importante tener en cuenta que debe ejecutarse en un nodo, por tanto el comando será:

Comando ndmpcopy para restaurar un directorio completo (no se muestra toda la salida).

Es muy importante definir correctamente las rutas fuente y destino que, como vemos, deben incluir los nombres de las SVMs involucradas en la operación de recuperación, así como el usuario y contraseña de los usuarios utilizados en origen y destino. Como referencia, el comando ndmpcopy usado en este ejemplo tiene la siguiente sintaxis:

Sintaxis simple comando ndmpcopy.

En próximas entradas veremos como proteger nuestra información a largo plazo utilizando snapvault para la realización de backups a disco.

La importancia de las directivas en NetWorker

Hoy vamos a recordar algo que no suele suceder muy a menudo, el fallo de un backup causado por determinados ficheros. Vamos a revisar como podemos analizarlo y solucionarlo de manera muy sencilla.

En ocasiones se produce un fallo realizando un backup en algún save set que antes no fallaba. De repente las notificaciones de un cliente que lleva mucho tiempo configurado comienzan a informar de fallos en el proceso de backup, pero solamente en algunos de los directorios o save sets de los configurados para ese cliente. Cuando esto sucede suele producirse en servidores de ficheros a los que acceden usuarios mediante el protocolo CIFS, por ejemplo servidores Unix o Linux compartiendo su almacenamiento interno mediante samba con equipos Windows.

Llegados este punto, la forma más correcta de analizar el fallo es lanzar el comando save directamente desde el cliente sobre esa ruta y analizar la salida del mismo. Lanzariamos el comando save del siguiente modo:

Comando save con mucho log para analizar el fallo.

Podríamos añadir la opción -D9 para que se lance en modo debug, lo cual genera mucha más salida, pero en general suele bastar con la sintaxis anterior, que ya genera bastante información.

Quitando toda la información intermedia de salida del comando, la parte importante es justo el final del mismo que tendrá una pinta como la siguiente:

Salida del comando save.

La salida nos muestra que, cuando el comando save lanza el módulo uasm para hacer el backup del fichero /Ruta/Thumbs.db, se produce un core y el comando save sale de forma un poco fea.

Recordemos que NetWorker tiene diferentes módulos para realizar las operaciones de backup y recuperación de diferentes tipos de sistemas de archivos, siendo el módulo uasm el empleado para los sistemas de ficheros Unix y Linux y que en nuestro caso al intentar hacer backup del fichero Thumbs.db, falla generando la salida anterior.

Como uasm es un módulo que puede llamarse por separado, es decir podemos ejecutarlo directamente desde línea de comandos, vamos a obtener una traza del mismo para intentar determinar más en profundidad cual es el fallo que se está produciendo.

En este punto, es muy importante que conozcamos que herramientas proporcionan los diferentes sistema operativos de forma nativa para poder obtener la traza de un comando y analizar las llamadas al sistema que realiza. En concreto en sistemas Solaris el comando que usaremos será truss y en sistemas Linux strace. Estos comandos generan muchísima salida, con lo que es recomendable utilizar la opción para volcar la traza del comando a un fichero para analizarla posteriormente.

Para el caso que nos ocupa, lanzamos el siguiente comando truss por tratarse de un sistema Solaris 11.3:

Generamos la traza del comando uasm

Y la salida que tenemos del comando anterior es la siguiente:

Salida del comando truss para analizar el comando de backup.

Esta salida, que en principio parece que no dice nada, realmente nos está indicando que el binario uasm, al procesar ese fichero Thumbs.db, ha intentado acceder a una dirección de memoria no válida, lo que nos hace pensar que puede haber un bug en el comando que provoca que, en determinados casos ciertos ficheros provocan este tipo de fallos.

Como está claro que este fallo implica abrir un caso de soporte pero necesitamos realizar el backup de la ruta afectada, lo mejor es establecer una directiva para ese cliente o todos aquellos clientes que puedan contener ese tipo de ficheros, indicando que deben ser ignorados al hacer backup.

Los ficheros Thumbs.db de Windows son pequeñas cachés utilizadas para hacer la visualización de miniaturas en directorios más rápida con lo que, sin ninguna duda, podemos ignorar estos archivos en nuestros backups sin problemas.

Por tanto para solucionar el problema, la directiva que debemos especificar es tan sencilla como la siguiente:

Directiva básica de exclusión de archivos.

Con esta directiva básica, que deberíamos usar para cualquier cliente de backup que contenga datos generados en sistemas Windows de usuario, nos aseguramos de excluir los ficheros Thumbs.db así como cualquier fichero temporal generado por el paquete Office. La última directiva indica que se comprimirán el resto de ficheros de esa ruta. Al especificar el carácter + delante de cada directiva, le estamos indicado a NetWorker que es necesario aplicar la operación a la ruta y todos sus subdirectorios.

Lo expuesto aquí, por mi experiencia, es algo que no suele producirse muy a menudo, con lo que no estaremos generando trazas de procesos de backup habitualmente. Sin embargo estas herramientas suelen ser muy útiles en general para detectar fallos y problemas de todo tipo de aplicaciones que, quizás de otro modo, nos costaría mucho más analizar y solucionar.

Como nota adicional, cuando se trata de sistemas Linux, el comando strace que suelo utilizar es el siguiente:

Comando strace equivalente en sistemas Linux.

 

Integración de NetWorker y Data Domain VE

Hola de nuevo, vamos con otra entrada sobre backup, en concreto como integrar un appliance virtual Data Domain con NetWorker 9.x.

Un sistema Data Domain nos permite realizar backups a disco con características muy superiores a las de un dispositivo AFTD de NetWorker, con el que se integra desde su versión 7.6, siendo sus principales características:

• Deduplicación de los datos. Los sistemas Data Domain deduplican los datos almacenados, lo que nos permitirá mantener más backups.
• Replicación entre los sistemas Data Domain desplegados.
• Protocolo DD Boost. El uso de este protocolo con NetWorker, acelera enormemente los backups y las recuperaciones.

Desde hace un tiempo está disponible una versión virtual de Data Domain, la cual se licencia por capacidad a partir de 500 GB. Esta appliance virtual que puede desplegarse en VMware e Hyper-V, incluye todas las licencias que nos interesan para nuestro servicio de backup, la licencia del protocolo DD Boost, la licencia de deduplicación y la de replicación. Por tanto, si queremos integrar sistemas Data Domain virtuales en nuestra infraestructura de backup, solo necesitaremos adquirir una licencia DiskBackup de NetWorker.

Tras la aburrida teoría, vamos a lo práctico. Primero desplegamos el appliance, para lo cual tenemos que seguir el asistente que se lanza al desplegar el fichero OVA del appliance virtual. Las opciones que debemos configurar en el despliegue son las tarjetas de red virtuales y el tipo de sistema DD que vamos a desplegar, siendo el mínimo el correspondiente a un sistema que soporta hasta 4 TB. Una vez desplegada nuestra appliance, en el primer arranque realizaremos la configuración inicial del sistema DD cuando iniciemos sesión en la consola por primera vez.

Lo primero es cambiar la contraseña del usuario sysadmin que nos permite administrar el sistema:

Primero cambiamos la password de sysadmin.

En los pasos siguientes configuramos la red del sistema donde, al menos uno de los interfaces, debe estar configurado por DHCP:

Especificamos la configuración de red.

En el siguiente paso el asistente de configuración nos preguntará si queremos introducir ya el código de licencia, así como la configuración del sistema la cual será más sencilla de realizar desde el interfaz gráfico de administración.

Al acceder a cualquier de las dos direcciones IP anteriores accederemos a la consola de administración Data Domain System Manager (DDSM) desde la cual podremos terminar de configurar el sistema y administrarlo:

Pantalla de validación para DDSM.

Al entrar por primera vez en DDSM y no haber introducido un código de licencia en la configuración inicial, lo primero que nos pedirá el sistema es introducir el fichero de licencia. La descarga del appliance incluye un fichero de licencia de evaluación, para que podamos hacer todas las pruebas que queramos durante 30 días. Basta con indicar donde esá el fichero de licencia para activar el DD virtual:

Introduciendo licencia de evaluación.

Tras este paso llegamos a la consola principal de adminsitración de DDSM que tiene la siguiente pinta:

Pantalla principal de DDSM.

El siguiente paso es añadir un disco al DD para que pueda usarlo como almacenamiento para nuestros backups. Como podemos añadir los discos en caliente, solo tenemos que añadir un nuevo disco virtual a la VM y configurarlo para su uso. Al añadir el nuevo disco veremos que este aparece en el apartado Devices dentro de la sección Hardware y también como almacenamiento utilizable, dentro del apartado Overview:

El disco disponible para ser añadido al sistema.

Para añadir el disco solo tenemos que pinchar sobre Configure y añadir el disco disponible al tier  activo como se puede ver en la siguiente imagen:

Añadimos el disco al tier activo para su uso.

El disco añadido y el uso de licencia asociado.

Al añadir el disco el sistema nos indicará que es necesario crear un sistema de archivos en el nuevo dispostivo para poder usarlo y el disco aparecerá en la consola como dispositivo que no está en uso. Para poder usar este nuevo disco necesitamos crear un sistema de archivos sobre él, para esto solo tendremos que seguir el asistente de creación de nuevo file system desde el apartado correspondiente dentro de la sección Data Management. Este asistente nos preguntará para que queremos utilizar el sistema, realizando unos tests de rendimiento específicos en cada caso. Como queremos integrarlo con NetWorker, seleccionamos la primera opción cuando llegamos al siguiente paso del asistente:

Seleccionamos la primera opción para usarlo como dispositivo de backup.

Una vez terminado el asistente de creación del file system este ya estará disponible para su uso con lo que ahora, para poder usarlo en nuestra infraestructura de backup, solo necesitamos conectarnos a la consola de nuestro servidor NetWorker y desde la sección devices, lanzar el asistente de creación de nuevo dispositivo. Al tratarse de un dispositivo DD el tipo de dispositivo que crearemos será un dispositivo Data Domain.

Lanzamos el asistente de creación de nuevo dispositivo.

Selecciona Data Domain como nuevo dispositivo.

Las opciones que debemos configurar para nuestro nuevo dispositivo son básicamente, la dirección IP del sistema y las credenciales del usuario con acceso para usar el protocolo DDboost:

Configuración de la IP y credenciales del dispositivo DD.

En el siguiente paso NetWorker se conectará con el Data Domain y podremos crear una carpeta específica en el file system y dar nombre a nuestro nuevo dispositivo. Esto nos permitirá tener cierta organización y crear diferentes dispositivos apuntando al mismo sistema DD.

Creación de carpeta y nombre de dispositivo.

Ya los siguientes pasos nos permiten crear un pool específico y asignarlo a este dispositivo, el nodo de almacenamiento que usará el dispositivo DD y la configuración de SNMP para que NetWorker pueda monitorizar los eventos SNMP que genere el sistema Data Domain. Con toda esta configuración realizada, nuestro nuevo dispositivo DD aparecerá en la lista de dispositivos del servidor NetWorker listo para ser usado para realizar backups.

El dispositivo DD ya está disponible para su uso.

Adicionalmente desde la DDSM, podemos ver la conexión activa desde el servidor NetWoker con el DD usando el protocolo DD Boost:

Conexión activa con el DD desde el servidor NetWorker.

Ya solo tendremos que cambiar nuestros workflows, o crear otros nuevos, para utilizar el nuevo pool que utiliza el dispositivo que acabamos de crear y empezar así, a hacer backups a disco.

Hasta aquí la configuración básica de un sistema Data Domain y como integrarlo con nuestro servidor NetWorker para poder hacer backusp a disco. En una próxima entrada veremos como configurar el DD para hacer backups directos de los clientes usando protocolos como NFS o CIFS.

Caraterísticas principales de NetWorker 9.2

Hola de nuevo, hoy toca una entrada sobre backup, en concreto sobre NetWorker y los cambios introducidos en las versiones 9.x.

Acabamos de terminar la migración de nuestro servicio de backup en versión 8.4.2, a la reciente versión 9.2.2 y he aprovechado para realizar cambios en la infraestructura. El cambio más importante ha sido la virtualización del servidor de backup, con lo que he separado el nodo de almacenamiento que controla la biblioteca de cintas del propio servidor.

El proceso de actualización ha implicado un cambio de plataforma, lo que Dell/EMC denomina una migración cruzada, ya que nuestro servidor de backup era un sistema Solaris 10 y el nuevo servidor es un servidor virtual Red Hat 7. Este tipo de migración solo está soportado si lo realiza personal de Dell/EMC así que, con su ayuda, hemos hecho la migración en aproximadamente 3 días.

Durante la instalación del servidor ya encontramos varios cambios, siendo los principales que es necesario instalar el servidor de autenticación y el servidor de licencias. Por tanto, si monitorizamos los procesos del servidor, ahora tendremos que incluir el servidor flex y los procesos asociados al servidor de autenticación en nuestro sistema de monitorización.

Otros de los cambios más importantes es la propia base de datos de NetWorker la cual, basada antes en WiSS, es ahora una base de datos SQLite, lo cual introduce muchas mejoras de rendimiento en el funcionamiento del servidor.

Pero los cambios de verdad los vemos al entrar en la NMC ya que ahora, la nueva consola presenta el siguiente aspecto:

Consola de adminsitración de NetWorker 9.2.

A primera vista es muy similar a la de las versiones 8.x y practicamente tenemos las mismas secciones, salvo por la sección Protection que es donde nos vamos a encontrar el cambio fundamental en como NetWorker nos permitirá proteger nuestra información.

En la sección Protection nos encontramos con la siguiente estructura:

Sección Protection de NMC.

Hay varios apartados que nos resultarán familiares de las versiones anteriores menos el apartado Policies, dentro del cual veremos que es donde se centra el cambio en como definimos nuestra estrategia de protección de datos.

Para ver las diferencias vamos a crear un cliente de backup usando el asistente de creación de nuevo cliente, que es el método recomendado de creación. Una vez terminado veremos nuestro nuevo cliente en la consola con una marca, la cual nos indica que el cliente no forma parte de ninguna política de protección.

Lista de clientes de backup disponibles.

A continuación creamos un grupo de clientes de backup en el que vamos a incluir nuestro nuevo cliente:

Creación de un nuevo grupo de backup.

Mientras que en versiones anteriores de NetWorker teníamos muchas opciones cuando configurábamos un grupo, ahora queda claro que un grupo de backup o protección es un conjunto de clientes organizado siguiendo el citerio que queramos fijar. En versiones anteriores recuerdo que olvidaba asignar el grupo al pool de cintas que quería usar para el backup de dicho grupo y, cuando se lanzaba el backup, el servidor siempre pedía una cinta del pool Default para poder realizar el backup. Ahora ya no hay una relación directa entre un grupo de backup y el pool de cintas a utilizar, con lo que veremos un poco más adelante como establecemos dicha relación.

Por tanto hasta ahora, en lo que respecta a la configuración de los clientes no encontramos muchas diferencias, pero en cuanto a los grupos de clientes no hemos configurado el pool a utilizar, si el grupo y el autostart están habilitados, el schedule, si queremos guardar los índices, etc...

El siguiente punto es la creación de una política, a partir de la cual podremos empezar a definir cómo queremos proteger nuestros datos. La creación de una política es tan sencillo como:

Creación de una nueva política.

Como podemos ver, lo único configurable es el nombre, comentario y tipo de notificación que se generará. Así que ¿como establezco la política de protección del grupo que acabo de crear? Creando un workflow que contendrá una o más acciones que queremos realizar sobre el grupo de protección.

Desde la política que acabamos de crear crearemos un workflow del siguiente modo:

Nuevo workflow de protección de clientes.

Ahora, dentro del workflow, definimos las acciones que queremos realizar y que se aplicarán solamente sobre el grupo LINUX_SERVERS que hemos definido antes.

Creación de una acción de backup - Tipo de backup y programación.

Creación de una acción de backup - Retención y pool.

Creación de una acción de backup - Opciones avanzadas y cambios en programación

Ahora que hemos definido la acción de backup sobre el grupo podemos resumir lo siguiente:

• Los clientes se organizan en grupos de protección. Estos grupos los crearemos según nuestros propios criterios, pero no disponen de más información que los clientes que los forman y el nombre del grupo.
• Las políticas de backup, también creadas según nuestros criterios y entorno, contendrán los workflows que aplicaremos a los grupos de protección anteriores. El workflow ya me permite configurar la hora de inicio, el intervalo y contiene las accioens que realizaremos sobre los grupos de protección.
• La acción o acciones que contenidas en un workflow me permitirán definir la programación, el storage node, el pool, la retención y cualquier opción adicional necesaria.

Una vez terminada la configuración, nuestro workflow se representará graficamente del siguiente modo:

Representación gráfica de un workflow de backup.

Con esta representacion gráfica queda claro que, sobre el grupo de protección LINUX_SERVERS vamos a realizar una acción de backup y que el pool a utilizar se llama BACKUP.

Todos estos cambios ya estarán reflejados en la sección Monitoring, desde la que podremos lanzar un backup de nuestro grupo con solo ejecutar el workflow correspondiente:

Ejecución de un workflow de backup.

Una vez terminado el backup, podremos consultar los logs y resultado del mismo desde esta sección:

Consultando el resultado de un backup.

Resultado y logs de un backup.

Así que hasta aquí, para todos los que administramos NetWorker, las diferencias fundamentales se basan en la relación entre todos los elementos que nos permiten diseñar nuestra estrategia de backup.

Después de tantos años trabajando con NetWorker, desde la version 7.x, creo que el cambio le hacía falta y que el resultado es un sistema mucho más moderno tanto desde el punto de vista funcional como operativo, sin contar todos los cambios realizados en el código y todas las funcionalidades añadidas.

Como todavía me falta mucho por leer, en breve intentaré hacer otra entrada con más información sobre esta nueva versión de NetWorker.

Backups con SnapManager para Exchange

Hola de nuevo, hoy voy a explorar las características de Snap Manager para Exchange, el cual acabo de implementar para poder realizar los backups de nuestra infraestructura de Exchange.

Snap Manager para Exchange es una aplicación de NetApp que dentro de su familia de aplicaciones Snap Manager, se integra con sus sistemas de almacenamiento y Microsoft Exchange para poder hacer backups de BBDD de Exchange mediante snapshots del almacenamiento donde residan las BBDD de buzones.

Este software se comunica directamente con Exchange a través de su API consiguiendo realizar backups consistentes de las BBDD de buzones así como de los logs de transacciones de Exchange. Así mismo, gracias a esta integración, Exchange truncará los logs de transacciones ya aplicados y de los que se ha realizado el backup, liberando así espacio en las LUNs de logs de las BBDD de buzones.

¿Que ventajas tengo al usar una aplicación como esta?

• Velocidad a la hora de realizar backups. Al ser un backup a disco basado en la capacidad de realizar snapshots, el backup es mucho más rápido.
• Velocidad a la hora de realizar restores. Del mismo modo, cualquier restauración es muchísimo más rápida.

Como es lógico estas son las dos ventajas fundamentales, pero adicionalmente disponemos de las siguientes ventajas derivadas de usar un sistema NetApp:

• Optimización del uso del almacenamiento. Fundamentalmente tenemos un ahorro de almacenamiento conseguido gracias a la deduplicación del dato. Almacenando varias LUNs en el mismo volumen conseguiremos una reducción del espacio utilizado.
• Protección de la información. Ya que estamos usando cabinas NetApp y snapshots ¿porque no transferir esos snapshots a otra SVM y mantenerlos con SnapVault? Igualmente, mediante una relación de SnapMirror podremos tener una réplica para nuestra política de DR.

Este último punto, que es el que nos ha costado más hacer funcionar, se integra directamente con ONTAP cluster, de tal manera que configurando el backup con la opción de archivado, lanzará automáticamente la relación de snapmirror o snapvault del almacenamiento primario al secundario.

Por tanto, si necesitas hacer backups rápidos de Exchange e implementar políticas de protección sobre ellos de forma rápida y sencilla, esta es una opción a tener muy en cuenta.

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.

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.