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:
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
:
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
Esto creará un enlace bajo /dev/tape/by-id/
apuntando al changer device detectado. Por ejemplo:
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:
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:
Ocurre lo mismo al descargar (el orden del argumento es el mismo):
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: 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
:
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
Comentarios
Indeed, you’re right.
Thanks for your visit and feedback Ana!
We edited the typo 🙂
Hello,
Thank you for this article. Very helpful.
I´m affraid there is a typo on «remember always to execute the upload slots command in the bacula console». Maybe it is «update slots» and not «upload slots» command?
Best regards.
Indeed, you’re right. Thanks for your visit and feedback Ana! We edited the typo 🙂
Indeed, you’re right.
Thanks for your visit and feedback Ana!
We’ve just edited the typo 🙂