Archivo de la etiqueta: linux

Bacula: necesaria introducción

GNU/Linux tips, , ,

Hola a todos.

Quería hablaros un poco de bacula, ese programa al que todo el mundo le coge miedo porque se les viene grande y/o a primera vista parece complicado.

Realmente es un programa grande, pero una vez te explican (a grandes rasgos) su funcionamiento, todo va rodado.

Introducción

Bacula es un programa que gestiona backups (copias de respaldo en castellano). Su enorme potencial reside en lo bien que maneja y automatiza las tareas de respaldo, sobre todo en entornos grandes (véase el mantenimiento de varios servidores).

Cierto es que si simplemente quieres hacer backups de tu equipo personal, olvídate, te llevará demasiado tiempo configurarlo. Pero si te encuentras en la posición de tener que ocuparte de varios equipos/servidores, Bacula es tu solución. Al principio tendrás que echarle muchas horas, pero una vez que dejes todo configuradito, pueden pasar años sin que tengas que volver a tocarlo; además una vez que aprendes a usarlo, los cambios que realizarás serán pequeños y fáciles.

Arquitectura

Lo primero que hay que entender de este programa es su diversificación: está dividido en varias partes que se interrelacionan entre ellas. Estas partes pueden estar instaladas en diferentes máquinas o en la misma, dando la opción de guardar los backups en una máquina diferente a la que los gestiona (por ejemplo).

Existen 3 partes principales, cada cual además es un paquete de instalación diferente: el Director, el Storage y el File. Como podréis deducir, el File es la máquina cliente (la que necesita que se le hagan copias), el Storage es la máquina que guarda dichas copias y el Director es la máquina que orquesta todo el proceso. Por supuesto pueden existir varias máquinas cliente (File), varias Storage (por si se quiere separar las copias) y Director (aunque lo lógico sería una, se pueden especificar varias).

Archivos, herramientas y demonios

Si todo esto se automatiza es por el uso de los demonios. Cada parte tiene su propio demonio: bacula-director, bacula-fd (file-daemon) y bacula-sd (storage-daemon). Y cada demonio funciona según la configuración de su archivo, alojados en /etc/bacula: bacula-dir.conf, bacula-fd.conf, bacula-sd.conf.

Estos archivos de configuración son generados automáticamente durante la instalación, y solo hace falta modificar un par de parámetros (IP de la máquina remota, certificados propios, planificación de backups automáticos…). La configuración del director es la más difícil y extensa, ya que es el que se ocupa de todo; normalmente se divide en varios archivos para no romperse uno la cabeza, luego en el archivo principal se unen todos (parecido a los includes de Apache2).

Ahora bien, aunque los archivos de configuración es donde está toda la «chicha», bacula nos ofrece varias herramientas para su manejo, puesto que muchas veces habrá que realizar tareas «a mano». Solamente voy a centrarme en la herramienta de consola bconsole, ya que es la más útil y además el resto (las gráficas) se basan en ella. Como su propio nombre indica, es un intérprete de órdenes, que de forma interactiva permite realizar diversos trabajos.

Cabe decir que existen varios servicios web que uno puede instalar el la máquina Director para el manejo y la monitorización de Bacula. Por ejemplo, Bacula-Web te ofrece con gráficas y tablas información sobre el estado de los backups, la ocupación del Storage… etc.

También hay que mencionar que el funcionamiento de Bacula se basa en un catálogo: una base de datos (a elegir entre MySQL, SQLite y PostgreSQL) donde quedan registrados todos los eventos, volúmenes, clientes… No se debe tocar a mano esta base de datos, a través de bconsole se ofrecen varios comandos para interactuar con el catálogo sin necesidad de usar sintáxis SQL.

Seguridad

Uno de los puntos fuertes de Bacula es la seguridad. Cada Cliente, Storage y el Director tiene su propia clave, y según la conexión ésta es cifrada con dicha clave. Cada uno puede inventarse esta clave a su gusto, aunque el propio programa te genera una aleatoria de 30 caracteres.

Además del propio cifrado que ofrece el programa, Bacula acepta conexiones seguras mediante el uso de TLS. Por lo tanto a nuestor anterior cifrado hay que añadirle otro cifrado más de certificado y de clave SSL. Si ya nos ponemos más serios, se debe crear un certificado y clave únicos para cada máquina. Esta parte de la configuración es un poco más compleja.

Volúmenes

Voy a hacer un poco de incapié en cómo se gestionan las copias a través del catálogo, ya que puede resultar un poco lioso al principio.

Las copias se guardan empaquetadas en volúmenes cifrados, por lo que uno no puede acceder directamente a los archivos. Es una especie de .tar.gz (ya que admite compresión), pero propio; sin el catálogo es imposible rescatar los datos a pelo. Existen herramientas avanzadas para ello, pero siempre necesitan algún componente de la base de datos, y para el usuario principiante se vuelven muy complejas. Por eso se debe mimar y cuidar el catálogo (por defecto Bacula hace un propio backup del catálogo después de completar los trabajos que tenía planificados).

Para ayudarnos en la organización de múltiples backups, Bacula agrupa los Volúmenes en Pools. Por poner un ejemplo, se define un Pool por cliente, asi todas las copias (Volúmenes) de cada cliente pueden diferenciarse fácilmente puesto que pertenecen a diferentes familias (Pools).

Además Bacula admite reutilización/reciclado de los volúmenes. Por lo que si tú solamente quieres un Full Backup mensual, pero sólo quieres que exista uno, puedes configurar Bacula para que sobreescriba el Volumen que anteriormente contenía esa copia, así te evitas llenar el disco innecesariamente y te olvidas de tener que borrar tú los datos viejos a mano.

Nivel de copia y restauraciones

Uno puede definir diferentes trabajos con sus horarios respectivos. Es decir, si todos los días hacemos un Full Backup, nuestras tareas de mantenimiento no serían muy eficazes… pero Bacula nos permite hasta 3 niveles diferentes a la hora de realizar copias de seguridad: Full, Differential e Incremental.

El Full backup es la copia clásica, todo lo que se quiera respaldar es copiado. Mientras que el Differential sólo copia los arhivos que hayan cambiado (o los nuevos) desde el último Full. Con las copias Incremental pasa lo mismo pero un nivel por debajo, sólo compara los cambios desde el último Differential, o desde el último Full si éste es más reciente. Esto es muy cómodo si se quiere mantener un equilibrio entre optimización de recursos y utilidad de los mismos. Con esto podemos conseguir archivos de diferentes fechas sin necesidad de ocupar mucho espacio. Es muy útil cuando alguien mete la pata y necesita el backup específico de un día.

Un ejemplo: planificamos backups Incrementales a diario, Diferenciales cada semana y Full cada mes. Si en algún momento necesitamos usar dichas copias (porque alguna de nuestras máquinas cliente se ha estropeado), simplemente tenemos que realizar un trabajo de Restore (a través de bconsole) pudiendo especificar la copia mas reciente para determinada fecha, y Bacula solito te monta un árbol de directorios basándose en la concatenación del último Full con los cambios aportados por los Differential e Incremental.

Automatización

Aquí viene el punto fuerte de Bacula. Todas las tareas de respaldo se planifican en el Director, admitiendo además niveles de prioridad. Por lo tanto es normal planificar varias tareas para el mismo día y la misma hora. Una vez que el Director haya conectado con la máquina cliente (con su FileDaemon) éste le pone en contacto con el Storage asociado a dicha tarea, prepara la conexión cifrada y los archivos que deben ser copiados.

Además no solo permite especificar los archivos/carpetas que deben ser copiados, también admite ejecutar comandos/scripts antes, durante y después de cada trabajo. Por lo tanto si uno quiere hacer un backup de una base de datos, puedes especificar la ruta del script que te da el dump y posteriormente copiar ese dump. También te permite especificar los archivos a copiar de forma genérica, pudiendo añadir archivos más concretos desde la propia máquina cliente. Es normal tener un FileSet común para todos los sistema UNIX (donde se definen las carpetas a copiar, /etc, /usr, /home /var…), y luego cada cliente puede especificar archivos propios que quieran ser copiados.

Bacula también admite reutilización/reciclado de los volúmenes. Por lo que si tú solamente quieres un Full Backup mensual, pero sólo quieres que exista uno, puedes configurar Bacula para que sobreescriba el Volumen que anteriormente contenía esa copia, así te evitas llenar el disco innecesariamente y te olvidas de tener que borrar tú los datos viejos a mano. Un uso muy extendido es el de reutilizar los Pools asignados a copias Incrementales y Diferenciales, ya que simplemente sirven para almacenar los archivos modificados/nuevos, cada vez que haya un nuevo Full esos volúmenes quedan inservibles, asi que los reutilizas para los nuevos Incrementales/Diferenciales.

Y todo esto… ¿cómo funciona?

Después del ladrillazo que os acabo de soltar, muchos se preguntarán como carajos se maneja esto. Pues bien, TODO se especifica en los archivos de configuración antes mencionados, y todo queda automatizado en ellos. Después de tirarte varias horas configurándolos, una vez hecho eso te vale para toda la vida, se vuelve incluso aburrido.

Lo único que requiere hacerse a mano son las tareas de restauración, ya que no tendría mucho sentido automatizarlas… aunque se puede hacer. Aún así, el hacerlas a mano es bastante sencillo, con la herramienta bconsole se ofrecen varias opciones y solamente tienes que ir eligiendo los detalles. También es un uso extendido el de definir los Pools a mano, por lo tanto en los archivos de configuración sólo tienes que decir a qué Pool pertenecen los Volumenes, sin tener que crear una directiva para crearlos/buscarlos.

Epílogo

No he entrado en detalles técnicos ya que este post se está volviendo muy extenso, además quería dar una vista global del funcionamiento del programa. Si veo mucho feedback quizás me curre un tutorial.

Espero que os haya gustado y ¡hasta la próxima!

Originalmente posteado en DesdeLinux

How to chroot a.k.a. recuperar un sistema que no bootea

GNU/Linux tips, , , , ,

Muchas veces, sobre todo cuando se anda trasteando, nos hemos visto en el aprieto de no poder acceder al sistema para repararlo, pero la solución es fácil: usar el comando chroot desde un LiveCD/RepairCD cualquiera.

En muchos sitios (foros, blogs…) se menciona este comando y se da un «copy/paste» del código, pero mi intención con este post es explicar un poco esos pasos, para poder hacer un buen uso de esta herramienta, con conocimineto de causa.

Introducción

El comando chroot es conocido como CHangeROOT, es decir, un comando que te permite cambiar la raíz del sistema sobre la que estás trabajando. En otra palabras: si estás desde un LiveCD y quieres que todo lo que estés trabajando sobre la consola tenga efecto en el sistema instalado, previamente debes hacer uso de chroot.

El problema está en que no basta con usar chroot tal cual, antes debemos montar adecuadamente determinadas particiones.

HOW TO

Primero necesitamos iniciar alguna terminal, ya sea desde otro sistema instalado (en otra partición/disco) o desde un LiveCD. IMPORTANTE: la arquitectura del LiveCD debe coincidir con la del sistema a reparar (32 o 64 bits).
Una vez estemos en la terminal empezaremos identificando nuestras particiones:

fdisk -l

  • Con este comando listaremos todas nuestras particiones/discos. Debemos identificar cuál es la partición objetivo, donde está instalado nuestro sistema a reparar, a partir de ahora lo llamaremos sistema roto.

Para este ejemplo consideraremos que nuestro sistema roto está en /dev/sda1 .

Pasamos a montar el sistema. Primero crearemos la carpeta donde vamos a trabajar y posteriormente montamos la partición donde se encuentra nuestro sistema roto en dicha carpeta

mkdir /mnt/my_linux
mount /dev/sda1 /mnt/my_linux

Si tenéis la carpeta /home o /var o cualquier otra en otra partición, deberíais montarla/s de la siguiente manera:

mount /dev/sda2 /mnt/my_linux/var

  • NOTA: he tomado como ejemplo la partición /dev/sda2 para la carpeta /var, que cada uno ajuste el código a sus características.

Normalmente con esto bastaría si simplemente se necesita editar archivos a mano, pero si queremos ejecutar algunos comandos que configuran el sistema, nos hace falta montar determinadas carpetas especiales del sistema: /dev, /proc y /sys.

mount -t proc proc /mnt/my_linux/proc
mount -t sysfs sys /mnt/my_linux/sys
mount -o bind /dev /mnt/my_linux/dev

  • Con la opción -t le decimos a mount el tipo de «filesystem» que queremos montar. Es necesario especificarlo por la naturaleza especial de las carpetas /proc y /sys.
  • Con la opción -o especificamos las opciones de mount. La opción bind sirve para «linkear». En UNIX todos los dispositivos hardware son accesibles a través de la carpeta /dev, por eso debemos montar nuestro actual /dev en la carpeta donde ahora se encuentra nuestro sistema roto. Al ya estar montada esta carpeta, solo es necesario decirle a mount dónde está originalmente montada.

Se hace de esta forma para que chroot tenga acceso a estas carpetas como si se tratasen del sistema roto, aunque deben ser del sistema actual (ej: la sesión del LiveCD) ya que guardan relación con el estado del sistema, los procesos y el hardware.

Ahora llega el momento de poder usar chroot:

chroot /mnt/my_linux/ /bin/bash

  • Al comando se le pasan como argumentos la ruta de la nueva raíz «/» (que en nuestro caso es /mnt/my_linux) y la consola que se desea utilizar (en este caso hemos optado por la archiconocida bash, encontrada en /bin/bash). Si no especificamos la consola nos encontraremos ante un intérprete de órdenes un poco arcaico (no rellena al pulsar el tabulador, etc).

Ahora ya podemos usar la consola como si tuviesemos la sesión de root iniciada en nuestro sistema roto (editar archivos, revisar scripts, instalar/desinstalar paquetes…). ¡OJO!, para que los cambios realizados surtan efecto, hay que desmontar el sistema de ficheros después de salir de chroot, mirad el ejemplo de abajo.

Más información en https://wiki.archlinux.org/index.php/Change_Root (lectura más que recomendada).

Ejemplo de uso: restauración de GRUB2

Uno de los usos más extendidos de chroot es como herramienta para poder reparar el GRUB. Ya que si se nos rompe el grub, es prácticamente imposible bootear nuestro sistema para poder arreglarlo.

AVISO: este pequeño tutorial es un mero ejemplo, funciona en varias distribuciones derivadas de Debian, Ubuntu y openSUSE entre otras. Aún así revisen la documentación propia de vuestra distribución, ya que en muchas no se encuentra el comando update-grub.
# NOTA: estos comandos se ejecutan una vez dentro de chroot.

update-grub
grub-install /dev/sda

  • Con update-grub actualizamos el menu de entrada de GRUB2, añadiendo así las posibles entradas que falten. Posteriormente reinstalamos GRUB en nuestro disco, ya que ha sido dañado.

En este caso he tomado /dev/sda como el disco en donde tenemos nuestro sistema, esto debéis adaptarlo a vuestro caso.

Nuestro GRUB ya debería estar reparado, asi que debemos salir de chroot, desmontar el sistema de ficheros (IMPORTANTE) y reiniciar para que los cambios surtan efecto. Si se nos olvida desmontar el sistema de ficheros, es posible que al reiniciar éstos no se desmonten correctamente y por lo tanto algunos cambios no tendrían efecto.
# salimos de chroot

exit

# desmontamos el sistema de ficheros y reiniciamos

umount /mnt/my_linux/dev
umount /mnt/my_linux/sys
umount /mnt/my_linux/proc
umount /mnt/my_linux
reboot

Y esto es todo. Espero que lo disfruten y que les sirva de utilidad. ¡Un saludo!

NOTA: tutorial originalmente escrito para DesdeLinux