Usando AWS Virtual Tape Library como Storage para Bacula

En este artículo, configuraremos una máquina virtual Storage Gateway en local que almacenará y cargará datos de backup desde Bacula.

La máquina virtual Storage Gateway subirá los datos al servicio de VTL, contando con una solución de backup rentable, al mismo tiempo que permite el almacenamiento externo de nuestros datos de backup.

¿Qué es Bacula?

Bacula es un paquete de código abierto para gestionar tus backups. Es muy personalizable y permite una configuración de almacenamiento muy potente. Puedes almacenar tus backups en cintas (en unidades o utilizando un media changer) o en un disco local.

La arquitectura de Bacula está hecha de programas disociados que facilitan la combinación de diferentes sistemas de almacenaje. Puedes utilizar múltiples backends de almacenaje desde el mismo director de Bacula.

¿Qué es Virtual Tape Library?

Virtual Tape Library (o VTL) es una solución basada en cintas de Amazon Web Services Storage Gateway. Puedes usar el servicio de VTL para archivar datos de backup en Amazon Glacier, proporcionando una integración perfecta entre el entorno local y la nube de AWS.

La arquitectura se verá de la siguiente manera, con la excepción de que usaremos un único Data Center (fuente):

Desplegando la máquina virtual de Storage Gateway en local, nos beneficiaremos de tener un caché de nuestros datos en las instalaciones, permitiendo tanto el acceso rápido a los datos de backup más recientes como a un búfer entre nuestro centro de datos y el almacenamiento de S3 donde se almacenan las cintas virtuales.

Es muy recomendable que uses dispositivos de disco para usarlos como almacenamiento intermedio de carga y almacenamiento en caché en tu Storage Gateway. Ten en cuenta que ambos tamaños de búfer tendrán un impacto directo en el rendimiento, ya que su uso principal es evitar las latencias de red entre tu Storage Gateway y AWS. Si tienes algún tipo de red de área de almacenamiento, puedes usar dispositivos RAW iSCSI.

Conexiones desde Bacula a VTL

Necesitarás instalar iSCSI Initiator Tools para tu distribución de Linux (open-iscsi en Debian y derivados, iscsi-initiator-utils si usas Red Hat). En nuestro caso en particular, usaremos Debian.

Para descubrir los objetivos expuestos por el dispositivo de VTL, puedes seguir las instrucciones de la documentación de VTL. Básicamente:

# This will output your gateway's IQN that you will use in the next command
sudo /sbin/iscsiadm --mode discovery --type sendtargets --portal GATEWAY_IP:3260

# This will connect the target (devices exposed by the VTL virtual machine)
sudo /sbin/iscsiadm --mode node --targetname IQN_YOU_GOT_IN_THE_PREVIOUS_COMMAND
--portal GATEWAY_IP:3260,1 --login

Ten presente que por defecto tu sistema puede detectar los dispositivos como dispositivos genéricos SCSI, pero para que Bacula opere correctamente, necesitamos cargar el controlador “st”. Puedes forzarlo añadiendo el nombre del módulo a /etc/modules.

Puedes ver los dispositivos recién añadidos usando lsscsi -g:

# lsscsi -g
[3:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st3 /dev/sg5
[4:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st2 /dev/sg3
[5:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st0 /dev/sg2
[6:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st1 /dev/sg4
[7:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st9 /dev/sg12
[8:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st4 /dev/sg7
[9:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st5 /dev/sg6
[10:0:0:0] mediumx AWS Gateway-VTL 0100 - /dev/sg8
[11:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st8 /dev/sg9
[12:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st7 /dev/sg10
[13:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st6 /dev/sg11

Como puedes ver, tenemos 10 unidades y un media changer, y podemos usar cualquier combinación de unidades si tenemos la capacidad de almacenaje y de ancho de banda. En esta entrada solamente usaremos uno de ellos, pero ten en cuenta que puedes usarlos todos si quieres.

Dado que Linux recientemente utiliza udev para autodescubrir dispositivos, puede pasar que los nombres del dispositivo no se mantengan entre reinicios. Ya que la configuración de Bacula necesita un nombre de dispositivo estático, escribiremos una regla de udev que combine con el media changer y le daremos un nombre predefinido. Añade las siguientes líneas a /etc/udev/rules.d/80-drivers.rules

# type 8 devices are "Medium Changers"
SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="8",
IMPORT{program}="scsi_id --sg-version=3 --export --whitelisted -d $devnode",
SYMLINK+="tape/by-id/scsi-$env{ID_SERIAL}-changer"

Esto creará un enlace bajo /dev/tape/by-id/ apuntando al changer device detectado. Por ejemplo:

# ll /dev/tape/by-id/
total 0
lrwxrwxrwx 1 root root 9 Mar 11 14:41 scsi-2414d5a4e5f5347572d454632-changer -> ../../sg8

MTX: el changer helper

Bacula es agnóstico en cuanto a sus backends de almacenamiento. Desconoce cómo gestionar un media changer o cómo escribir una cinta. Utiliza la filosofía subyacente de UNIX de «todo es un archivo» y herramientas auxiliares para administrar cintas y unidades.

Una de las herramientas de backend es mtx, un programa usado para controlar media changers. Puedes usar mtx de manera manual para operar con el changer, pero si haces algún cambio permanente (por ejemplo, cargar o descargar cintas) recuerda ejecutar siempre el comando update slots en la consola de Bacula.

Estatus

Lista los Data Transfer Elements (unidades), así como los Storage Elements (ranuras de expansión) con sus contenidos. Ejemplo:

# mtx -f /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer status | head -n 50
Storage Changer /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer:10 Drives, 3200 Slots ( 1600 Import/Export )
Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag = TAP964B33
Data Transfer Element 1:Empty
Data Transfer Element 2:Empty
Data Transfer Element 3:Empty
Data Transfer Element 4:Empty
Data Transfer Element 5:Empty
Data Transfer Element 6:Empty
Data Transfer Element 7:Empty
Data Transfer Element 8:Empty
Data Transfer Element 9:Empty
Storage Element 1:Empty:VolumeTag=
Storage Element 2:Full :VolumeTag=TAP944B31
Storage Element 3:Full :VolumeTag=TAPA44B01
Storage Element 4:Full :VolumeTag=TAPA54B00
Storage Element 5:Full :VolumeTag=TAP5B4AFE
[...]

Ten en mente que hay 3200 ranuras de expansión, 1600 ranuras de expansión regulares y 1600 ranuras de expansión de Import/Export, usadas cuando se archivan y recuperan cintas desde y hacia el Virtual Tape Shelf.

Carga/Descarga

Puedes cargar y descargas cintas manualmente desde las ranuras de expansión (Storage Element) a las unidades (Data Transfer Element).
De todas maneras, ten cuidado si Bacula está operando con las unidades para que no interfieran en su funcionamiento habitual.
Por ejemplo, para cargar la cinta que está en la ranura de expansión 3 a la unidad número 9:

# mtx -f /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer load 3 9
Loading media from Storage Element 3 into drive 9...done
# mtx -f /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer status
Storage Changer /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer:10 Drives, 3200 Slots ( 1600 Import/Export )
Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag = TAP964B33
Data Transfer Element 1:Empty
[...]
Data Transfer Element 8:Empty
Data Transfer Element 9:Full (Storage Element 3 Loaded):VolumeTag = TAPA44B01
Storage Element 1:Empty:VolumeTag=
Storage Element 2:Full :VolumeTag=TAP944B31
Storage Element 3:Empty:VolumeTag=

Ocurre lo mismo al descargar (el orden del argumento es el mismo):

# mtx -f /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer unload 3 9
Unloading drive 9 into Storage Element 3...done
# mtx -f /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer status | head -n 30
Storage Changer /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer:10 Drives, 3200 Slots ( 1600 Import/Export )
Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag = TAP964B33
Data Transfer Element 1:Empty
[...]
Data Transfer Element 8:Empty
Data Transfer Element 9:Empty
Storage Element 1:Empty:VolumeTag=
Storage Element 2:Full :VolumeTag=TAP944B31
Storage Element 3:Full :VolumeTag=TAPA44B01

El mtx-changer wrapper

La herramienta de mtx es útil para gestionar los dispositivos manualmente, pero Bacula viene con un buen wrapper llamado mtx-changer (en los sistemas Debian, puedes encontrar int en /etc/bacula/scripts/mtx-changer), el que Bacula realmente usará.

De hecho, el wrapper está pensado para ser modificado y así adaptarse a tus necesidades concretas, aunque para la mayoría de changers debería funcionar de manera inmediata. En el caso particular de VTL, filtrará las 1600 ranuras de expansión de Import/Export, por lo que si quieres usarlos directamente desde la consola Bacula (por ejemplo, cuando crees una nueva cinta o recuperes una cinta archivada del Virtual Tape Shelf, VTL lo insertará en una de las ranuras de expansión de Import/Export disponibles), tendrás que ajustarlo un poco. En nuestro caso, nos gusta interactuar con las ranuras de expansión de Import/Export utilizando la interfaz mtx de forma manual.

Configuración de Bacula

Después, tenemos que modificar la configuración de Bacula para usar los nuevos dispositivos. Cambiaremos dos archivos:

• bacula-sd.conf: aquí configuraremos los backends de almacenamiento actuales (cómo Bacula escribirá realmente a las cintas y usará el media changer).
• bacula-dir.conf: definiremos un recurso de Storage y lo pondremos a disposición del grupo de cintas.

Storage Daemon

Para configurar el Storage Daemon, simplemente tienes que crear los recursos en tu configuración de Storage Daemon (archivo bacula-sd.conf). Veamos la definición del recurso y luego desglosaremos el significado de las directivas:

Autochanger {
Name = "VTL Autochanger"
Device = Drive-1
Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d"

Changer Device = /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer
}

Device {
Name = Drive-1
Drive Index = 0
Media Type = ULT3580-TD5
Archive Device = "/dev/tape/by-path/ip-GATEWAY-IP:3260-iscsi-YOUR-IQN-tapedrive-01-lun-0-nst"
RemovableMedia = yes;
RandomAccess = no;
AutoChanger = yes
}

Autochanger: la definición de las propiedades del medium changer:

• Name: un nombre arbitrario (identificador) para el dispositivo de Autochanger.
• Device: una lista separada entre comas de recursos de Device que trabaja con este Autochanger.
• Changer Command: el programa que se utiliza cuando Bacula necesita cargar/descargar cintas desde/hacia las unidades.
• Changer Device: el dispositivo de SCSI para manejar el Autochanger. Aquí es donde pondremos el nombre del symlink que creemos con la regla de udev.

Device: la definición de cada unidad de la cinta:

• Name: un nombre arbitrario (identificador) para esta unidad.
• Drive Index: el índice de la unidad (usado por mtx)
• Media Type: un identificador arbitrario de las cintas que este dispositivo puede usar. Puedes usar el mismo Media Type para múltiples recursos si son compatibles (¡y si usas VTL lo son!), de esta manera, Bacula no vinculará una cinta en particular para que se lea por una única unidad, sino que, en vez de eso cualquier unidad valdrá para cargar cualquier cinta virtual.
• Archive Device: el dispositivo en sí que Bacula usará para escribir a la unidad.
• RemovableMedia: indica que el medio se puede extraer (al contrario que un directorio en el disco duro)
• RandomAccess: las unidades de cintas no pueden leer/escribir en posiciones arbitrarias, debes tirar atrás y avanzar hasta el fragmento deseado de la cinta.
• AutoChanger: este dispositivo pertenece a un changer automático.

Director

Añadiremos nuevos recursos de Storage y Pool al archivo de configuración bacula-dir.conf:

Storage {
Name = VTL
Address = storage-daemon.fqdn # N.B. Use a fully qualified name here
SDPort = 9103
Password = "password"
Device = "VTL Autochanger"
Media Type = ULT3580-TD5
Autochanger = yes
}

Pool {
Name = Backup
Pool Type = Backup
Storage = VTL
[...]
}

Las 2 directivas importantes son:

1. Storage: la definición del almacenaje para nuestras tareas.

• Name: un identificador arbitrario que usaremos en el recurso Pool
• Address: una IP o nombre del host resoluble por los clientes. Este string se pasa de manera textual a los clientes para que sepan qué Storage Daemon tienen que usar.
• Password: usada para autenticarse con el Storage Daemon.
• Device: el nombre que le dimos al recurso Autochanger en la configuración de Storage Daemon.
• Media Type: debe coincidir con la directiva de Media Type desde la definición de Autochanger en el Storage Daemon.
• Autochanger: indica que este almacenaje es un Autochanger.

2. Pool: la definición de un grupo de cintas que Bacula puede usar para hacer backups.

• Name: un identificador arbitrario que usaremos en el recurso Job
• Pool Type: aquí simplemente usa Backup.
• Storage: el nombre que le dimos antes al recurso de Storage.

Entonces, ya lo tenemos todo listo. Ahora solamente tenemos que usar el recurso Pool que usa el backend de almacenaje de VTL en nuestras tareas de backup.

Resumiendo

Como hemos visto, las posibilidades de configuración de Bácula son muy poderosas, pero configurarlas puede ser algo complicado (¿qué? ¿necesito añadir 4 recursos en dos archivos diferentes solamente para usar una unidad de cinta?) pero es aquí donde reside su flexibilidad.

AWS Virtual Tape Library es el complemento perfecto de Bacula. Tenemos datos locales y fáciles de acceder (descansando en el Cache Buffer en el dispositivo VTL local) así como backups basados en el Cloud y fuera de las instalaciones. También podemos aprovechar Glacier para reducir el impacto de los costes.

TAGS: amazon web services, aws, backups, bacula, herramientas, how-to, howto, procedimientos, recipes, storage