Bacula y los enlaces simbólicos

Detalles

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.

Compartí este artículo