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. |
