Un problema que he descubierto recientemente con Bacula, es que el File Deamon en los clientes no sigue links simbólicos que apunten a otro filesystem o a un directorio que no es parte del backup (FileSet
, conjunto de archivos a resguardar). Esto es un comportamiento lógico, pues Bacula da precedencia a la configuración de Include
y Exclude
dentro de cada FileSet
. Sin embargo, es un detalle particular a tener en cuenta al momento de definir tanto los FileSet
como los trabajos de Backup, pues Bacula no sigue aquellos symlinks que apunten a directorios fuera del conjunto a resguardar.
Veamos directamente un ejemplo. En los sistemas FreeBSD, el directorio /home
es en realidad un enlace simbólico a /usr/home
:
root@fbsd10:/ # ll -d /home lrwxr-xr-x 1 root wheel 8 Sep 1 14:07 /home@ -> usr/home
El problema ocurre cuando se desea hacer backup de un directorio, pero este es en realidad un enlace simbólico (symbolic link) a otro directorio, el cual no es parte del conjunto de archivos y directorios a resguardar.
El trabajo de backup en el Director de Bacula utiliza un FileSet
con la siguiente configuración:
Include { Options { signature = MD5 compression = GZIP } File = /etc File = /usr/local/etc File = /home File = /root File = /backup }
Se observa que se desea resguardar /home
pero no /usr
.
Prueba Nº 1
Al ejecutar el trabajo con esta configuración de FileSet
se hace una copia de respaldo del enlace, pero no de su destino. Esto se hace evidente al momento de restaurar un backup desde la consola de Bacula con el comando restore all
:
root@fbsd10:~ # cd /usr/local/bacula/restore/ root@fbsd10:/usr/local/bacula/restore # ll total 18 drwxr-xr-x 27 root wheel 114 Dec 5 08:42 etc/ lrwxr-x--x 1 root wheel 8 Dec 5 10:06 home@ -> usr/home drwxr-xr-x 8 root wheel 19 Dec 2 14:45 root/ drwxr-x--x 3 root wheel 3 Dec 5 10:06 usr/ root@fbsd10:/usr/local/bacula/restore # ll usr/ total 1 drwxr-x--x 4 root wheel 4 Dec 5 10:06 local/
Se observa que se ha restaurado el enlace simbólico home@
, y se ha creado apuntando correctamente a la ruta relativa usr/home
. Aunque no existe usr/home
, pues no es parte del FileSet
.
Prueba Nº 2
Luego de borrar la restauración en el cliente:
root@fbsd10:/usr/local/bacula/restore # cd .. root@fbsd10:/usr/local/bacula # rm -r restore/*
Cambiar la configuración del FileSet
para forzar a Bacula a seguir el link simbólico:
Include { Options { signature = MD5 compression = GZIP } File = /etc File = /usr/local/etc File = /home/. File = /root File = /backup }
Notar que se ha agregado /.
. De esta forma Bacula sigue el link simbólico en lugar de verlo como un archivo especial, lo cual termina resguardando al directorio destino.
Reiniciar el Director de Bacula y volver a correr el trabajo de backup, pues se ha modificado el FileSet
. Luego, restaurar nuevamente.
Al restaurar es posible comprobar que el directorio /home
ha sido resguardado correctamente:
root@fbsd10:/usr/local/bacula # ll restore/ total 18 drwxr-xr-x 27 root wheel 114 Dec 5 08:42 etc/ drwxr-xr-x 4 root wheel 4 Sep 14 15:15 home/ drwxr-xr-x 8 root wheel 19 Dec 2 14:45 root/ drwxr-x--x 3 root wheel 3 Dec 5 10:30 usr/ root@fbsd10:/usr/local/bacula # ll restore/usr/ total 1 drwxr-x--x 4 root wheel 4 Dec 5 10:30 local/
Sin embargo, notar que ya no es un enlace simbólico (y tampoco es /usr/home
parte del backup), sino que se ha transformado en un directorio, el cual contiene los archivos y directorios dentro del destino (/usr/home
). Básicamente se ha transformado al enlace simbólico en el target. Esto puede traer problemas de consistencia al momento de una restauración.
Alternativas
Otras soluciones posibles consisten en agregar ambas entradas (tanto el link simbólico, como su target) en la configuración del FileSet
:
File = /home File = /usr/home
O simplemente resguardar sólo del target:
File = /usr/home
Problema
El principal problema aquí es que, si un directorio en una ruta dentro de un directorio a resguardar es un link simbólico hacia fuera del FileSet
, éste no será resguardado. Esto implica que es necesario ser consciente de todos los posibles enlaces simbólicos, antes de definir el FileSet
, de lo contrario se corre el riesgo de dejar información importante fuera del backup, lo que puede ocasionar una eventual pérdida de datos.
A este fin, es posible recurrir a la herramienta find
para encontrar todos los enlaces simbólicos dentro de un directorio específico:
# find / -type l -exec ls -ld {} \;
Por ejemplo:
root@fbsd10:/usr/local/bacula # find /etc/ -type l -exec ls -ld {} \; lrwxr-xr-x 1 root wheel 14 Aug 12 2015 /etc/unbound -> ../var/unbound lrwxr-xr-x 1 root wheel 23 Aug 12 2015 /etc/termcap -> /usr/share/misc/termcap lrwxr-xr-x 1 root wheel 13 Aug 12 2015 /etc/rmt -> /usr/sbin/rmt lrwxr-xr-x 1 root wheel 35 Nov 11 2014 /etc/vmware-tools/plugins -> /usr/local/lib/vmware-tools/plugins lrwxr-xr-x 1 root wheel 31 Nov 11 2014 /etc/vmware-tools/icu -> /usr/local/lib/vmware-tools/icu lrwxr-xr-x 1 root wheel 10 Oct 13 2015 /etc/mail/certs/saraza.0 -> cacert.pem lrwxr-xr-x 1 root wheel 38 Nov 1 15:33 /etc/ssl/cert.pem -> /usr/local/share/certs/ca-root-nss.crt lrwxr-xr-x 1 root wheel 12 Aug 12 2015 /etc/aliases -> mail/aliases
En este caso en particular, existen varios enlaces simbólicos que apuntan fuera del FileSet
indicado al comienzo del artículo. Entre ellos se encuentran /var
, /usr/share/misc
, /usr/sbin
, /usr/local/lib
y otros.
Finalmente, cabe destacar que si un enlace simbólico apunta a un destino dentro del FileSet
, no hay problema alguno. Se resguarda correctamente tanto el enlace simbólico como el destino, apuntando correctamente el enlace a este último al momento de restaurar una copia de seguridad.