Mostrando entradas con la etiqueta backup. Mostrar todas las entradas
Mostrando entradas con la etiqueta backup. Mostrar todas las entradas

Backups incrementales con tar

Sí, es cierto, hacía tiempo que no escribía nada en el blog y eso no puede ser. Después de un tiempo de parón, espero volver a ser más constante en las entradas.
En este caso, vamos a ver un método de hacer un backup incremental, pero sin ningún software adicional, sino empleando el comando tar.
La importancia de realizar backups no hace falta que la comente, pues es un tema muy sabido por todos. El método típico de hacer backup con tar, es comprimir todos los ficheros que así desees en un contenedor y darle un nombre, por ejemplo, una fecha. Si todos los finales de día lo hacemos, tenemos un backup bastante consistente y ante posibles fallos. El único problema, que ocupará mucho espacio! Para resolver este problema está el backup incremental y tar, como no podía ser de otra manera, también lo soporta. A continuación, dejo un ejemplo de cómo se debería de emplear tar para la realización de un backup incremental.
  • Crear el entorno de pruebas
    shell> mkdir -p test/aa test/bb test/cc
    shell> touch test/aa/a test/bb/b test/cc/c
    
  • Realizar el primer backup
    Importante aquí, la opción que le pasamos --listed-incremental file.
    shell> tar --listed-incremental test.metadata \
               -czf test.tar.gz test
    
  • Borrar y cambiar ficheros
    shell> rm test/aa/a
    shell> touch test/aa/aa
    shell> echo "hola" > test/bb/b
    
  • Volver a lanzar el backup incremental
    Cada incremental lo vamos añadiendo a un nuevo contenedor.
    shell> tar --listed-incremental test.metadata \
               -czf test.inc1.tar.gz test
    
  • Restaurar ficheros
    Para ello, necesitamos el fichero de backup completo y también los incrementales
    shell> mkdir restore
    shell> tar xzf test.tar.gz -C restore
    shell> tar --incremental \
               -xzf test.inc1.tar.gz -C restore
    
Como podemos apreciar que ha añadido el fichero creado pero también borrado el fichero eliminado en el momento de hacer el incremental. Espero que os haya resultado útil.
Como ya sabréis, realizar backups al mismo disco no es una buena idea, por lo que si no lo conoces, te recomiendo la lectura del tag bacula, que quizás te ayude a tener un backup más seguro.
Leer más

Bacula PKI, cifrando los datos

Si el otro día hablamos acerca de cómo configurar Bacula para que todos los datos de los que realiza backup viajen cifrados (puedes leer el post completo aquí), hoy vamos a ver otra parte no menos importante: la seguridad de los datos almacenados.
Casi tan importante como tener un buen respaldo de los datos es que estos estén seguros. Si alguien se hace con una cinta y tiene ahí todos los datos almacenados en texto plano, pues ya os podéis imaginar... Así que, para evitar que esto suceda, vamos a emplear la opción, también incluida en Bacula, de cifrar los datos en origen. Con ello conseguimos que los datos salgan del cliente ya cifrados, según una clave privada que sólo el cliente debe de conocer. Esto garantiza que los datos que se escriban en la cinta estén ya cifrados, no los cifra el bacula-sd o el bacula-director, sino que es en origen, es decir, bacula-fd. Aquí es importante recalcar que los datos estarán cifrados, es decir, el fichero no se sabrá lo que tiene, pero tanto ruta, permisos, nombre del fichero, etc. estarán disponibles para que en caso de que se necesite recuperar algo, se pueda hacer sin problema.

Generar las claves de cifrado

Como siempre, vamos primero a generar las claves que necesitamos para hacer el cifrado de datos. Para ello, generamos la clave maestra tal como sigue,
shell> openssl genrsa -out master.key 2048
shell> openssl req -new \
       -key master.key \
       -x509 \
       -out master.cert \
       -days 3650
En este caso, y para evitar futuros problemas, creamos un certificado con 10 años de validez. Este será nuestro certificado maestro.
Ahora debemos de generar el par de claves para cada cliente. Este es el paso que debemos de repetir en cada uno de los clientes.
shell> openssl genrsa -out a.local.net.key 2048
shell> openssl req -new \
       -key a.local.net.key \
       -x509 \
       -out a.local.net.cert \
       -days 3650
shell> cat a.local.net.key a.local.net.cert > a.local.net.pem

Configuración

Y ahora, ya únicamente nos queda por editar el fichero del agente (bacula-fd.conf) y añadir las claves de cifrado en el apartado FileDaemon.
FileDaemon {
   ...
   # Data Encryption
   PKI Signatures = Yes
   PKI Encryption = Yes
   PKI Keypair = "/etc/bacula/tls/a.loca.net.pem"
   PKI Master Key = "/etc/bacula/tls/master.cert"
}
Tras el cambio, reiniciamos el daemon y podemos lanzar una tarea de backup, en la que al finalizar aparecerá lo siguiente:
FD Files Written:       139
SD Files Written:       139
FD Bytes Written:       8,719,243,782 (8.719 GB)
SD Bytes Written:       8,719,264,244 (8.719 GB)
Rate:                   23954.0 KB/s
Software Compression:   None
VSS:                    no
Encryption:             yes
Accurate:               no
Todo el proceso de copia y restauración de backups en el cliente es completamente transparente para el administrador. Es el propio software de Bacula quien lo realiza.

Precauciones

Es muy importante tener las claves de cifrado muy bien respaldadas, pues si se pierden no será posible restaurar ningún fichero del sistema.
En caso de de que clave o certificado del cliente se pierda, mientras tengamos las claves maestro podremos restaurar los ficheros. Para ello únicamente deberemos seguir las siguientes instrucciones.
  1. Concatener las claves maestro
  2. shell> cat master.crt master.key > master.keypair
    
  3. Modificar el fichero del agente (bacula-fd.conf)
    FileDaemon {
       ...
       PKI Keypair = /etc/bacula/tls/master.keypair
    }
    

Referencias

Leer más

Bacula TLS, cifrando la comunicación

Esta semana tocó configurar Bacula. La configuración básica del servicio es bastante sencilla y ponerlo a funcionar suele no llevar mucho. Sin embargo, si estás pensando en realizar backup remoto o entre diferentes redes, la opción de que los datos viajen cifrados, no es discutible. Incluso dentro de la propia red local no debería de serlo.
Por suerte, Bacula ya trae soporte para cifrar los datos mediante certificados TLS. Y es importante que tanto la parte cliente como la parte servidor traigan dicho soporte. Para comprobarlo, podemos emplear el comando ldd contra el binario de Bacula.
shell> ldd /usr/sbin/bacula-dir
   libcrypt.so.1 => /lib/libcrypt.so.1
   libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8
   libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8
   ...
shell> ldd /usr/sbin/bacula-fd
   libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8
   libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8
   ...
Si vuestros servicios tienen soporte SSL, entonces podemos seguir leyendo la entrada. Si por el contrario el paquete del que dispones no viene con soporte SSL, intenta actualizarlo o compilarlo para que sí lo soporte.

Crear los certificados

Lo primero que debemos hacer es crear los certificados para los equipos. La parte más importante aquí es aclarar que cada equipo tendrá unos certificados diferentes y por lo tanto, los siguientes 4 pasos habrá que repetirlos en cada uno de los equipos en los que vaya algún componente de Bacula.
  1. Clave privada del equipo
    Esta va a ser la llave maestra para el equipo.
    shell> openssl genrsa -des3 -out a.local.net.key 4096
  2. Solicitud de certificado
    Con la clave anteriormente creada generamos una solicitud de certificado. Es importante que estos datos se rellenen correctamente y en especial la parte del Common Name, que debe ser el FQDN del equipo.
    shell> openssl req -new \
           -key a.local.net.key \
           -out a.local.net.csr
    Enter pass phrase for a.local.net.key:
    ...
    Organizational Unit Name (eg, section) []:Elmundoenbits
    Common Name (e.g. server FQDN) []:a.local.net
    ...
  3. Firmamos la solicitud con una CA conocida
    En este caso, recomiendo recurrir a cacert.org como CA. La creación de la cuenta es gratuita y puedes firmar todas las solicitudes que desees, siempre que tengas permiso para el dominio.
    En caso de que tu sistema no tenga el certificado raíz del CACert, lo puedes descargar desde aquí y le vamos a llamar cacert.pem.
  4. Generamos la clave sin contraseña
    Finalmente y puesto que Bacula no permite trabajar con certificados con contraseña, necesitamos exportar la clave privada (paso 1) a la versión sin contraseña.
    shell> openssl rsa \
           -in a.local.net.key \
           -out a.local.net-nopass.key
    shell> mv a.local.net-nopass.key a.local.net.key
    
Como dije, estos pasos los repetiremos para cada uno de los equipos. Para el ejemplo que aquí manejamos, tendremos dos equipos. El equipo servidor de Bacula (bacula.local.net), para el que tenemos los siguientes ficheros disponibles:
  • cacert.pem
  • bacula.local.net.cert
  • bacula.local.net.key
Y el equipo cliente, a.local.net, con sus tres ficheros correspondientes,
  • cacert.pem
  • a.local.net.cert
  • a.local.net.key

director - bconsole

Lo primero que debemos hacer ahora es indicarle al software de consola (bconsole) que para conectarse al bacula-director debe de emplear certificados TLS. Para ello editamos el fichero bconsole.conf y añadimos las opciones de TLS.
Director {
   ...
   TLS Enable = yes
   TLS Require = yes
   TLS CA Certificate File = /etc/bacula/tls/cacert.pem
   TLS Certificate = /etc/bacula/tls/bacula.local.net.cert
   TLS Key = /etc/bacula/tls/bacula.local.net.key
}
Y a continuación, debemos de indicarle a la parte contrarios (director) exactamente lo mismo (fichero bacula-dir.conf).
Director {
   ...
   TLS Enable = yes
   TLS Require = yes
   TLS CA Certificate File = /etc/bacula/tls/cacert.pem
   TLS Certificate = /etc/bacula/tls/bacula.local.net.cert
   TLS Key = /etc/bacula/tls/bacula.local.net.key
}
Con ello, ya es posible conectarse con bconsole a Bacula para realizar comprobaciones.

director - bacula-sd

A continuación, hay que establecer la comunicación cifrada entre el director y el storage. Para ello nos toca editar el fichero bacula-sd.conf y en el apartado Director, añadirle las opciones TLS. Como siempre,
Director {
   ...
   TLS Enable = yes
   TLS Require = yes
   TLS CA Certificate File = /etc/bacula/tls/cacert.pem
   TLS Certificate = /etc/bacula/tls/bacula.local.net.cert
   TLS Key = /etc/bacula/tls/bacula.local.net.key
}
Y a continuación, en el fichero bacula-dir.conf, editar el apartado Storage y también añadir las opciones TLS.
Storage {
   ...
   TLS Enable = yes
   TLS Require = yes
   TLS CA Certificate File = /etc/bacula/tls/cacert.pem
   TLS Certificate = /etc/bacula/tls/bacula.local.net.cert
   TLS Key = /etc/bacula/tls/bacula.local.net.key
}


bacula-fd - bacula-sd

La que citamos a continuación es quizás la parte más importante en la que aplicar el cifrado, ya que es la que se encarga de enviar y recibir los datos. Por lo tanto, nos interesa mucho que estos sí estén cifrados. Para hacerlo editamos nuevamente el fichero bacula-sd.conf y en el apartado Storage añadimos los TLS,
Storage {
   ...
   TLS Enable = yes
   TLS Require = yes
   TLS CA Certificate File = /etc/bacula/tls/cacert.pem
   TLS Certificate = /etc/bacula/tls/bacula.local.net.cert
   TLS Key = /etc/bacula/tls/bacula.local.net.key
}
y en cada uno de los clientes (fichero bacula-fd.conf) hacemos lo correspondiente,
FileDaemon {
   ...
   TLS Enable = yes
   TLS Require = yes
   TLS CA Certificate File = /etc/bacula/tls/cacert.pem
   TLS Certificate = /etc/bacula/tls/a.local.net.cert
   TLS Key = /etc/bacula/tls/a.local.net.key
}


bacula-fd - director

Para finalizar toda la configuración lo que nos queda es realizar la comunicación entre el director y el cliente también cifrada. Para ello, fichero bacula-dir.conf, apartado del cliente,
Client {
   ...
   TLS Enable = yes
   TLS Require = yes
   TLS CA Certificate File = /etc/bacula/tls/cacert.pem   
   TLS Certificate = /etc/bacula/tls/bacula.local.net.cert
   TLS Key = /etc/bacula/tls/bacula.local.net.key
}
Y en el fichero del cliente (bacula-fd.conf),
Director {
   ...
   TLS Enable = yes
   TLS Require = yes
   TLS Verify Peer = yes
   TLS CA Certificate File = /etc/bacula/tls/cacert.pem
   TLS Certificate = /etc/bacula/tls/a.local.net.cert
   TLS Key = /etc/bacula/tls/a.local.net.key
}
Para terminar, reiniciamos los servidor bacula-sd, bacula-dir y los bacula-fd que correspondan. Si no hay ningún problema, la comunicación debería de estar cifrada en el servicio funcionando perfectamente.

Referencias

Leer más

Bacula (I)

Bacula es un software de copias de seguridad en red de código abierto. Está diseñado para escalar desde una sola máquina a miles, siendo capaz de hacer los backup's en cinta, disco o cualquier otro medio sobre el que GNU/Linux sepa escribir. Sobre algunas características y usos de Bacula ya tuvimos varias entradas, pero hoy vamos a ver Bacula desde un punto de vista más teórico.
El software Bacula está compuesto de 5 servicios principales que detallamos a continuación.
  1. Bacula Director Daemon
    Bacula Director es el centro neurálgico de Bacula y el que controla todas las operaciones: copia de seguridad, recuperación y verificación de datos. En él están, por ejemplo, la ejecución programada de cada acción, también regula la gestión de los grupos de medios y controla el archivo de almacenamiento.
    Para establecer comunicación con él, el administrador tiene acceso a una consola.
  2. Bacula Catalog
    Bacula Catalog está formado por el programa de software responsable de mantener los índices de los archivos y por la base de datos de todos los archivos de copia de seguridad. Son estos catálogos los que permiten al administrador o al usuario encontrar y restaurar cualquier fichero rápidamente. Para ofrecer estos servicios de catálogo, Bacula se apoya en software de base de datos. Actualmente tiene soporte para MySQL, PostgreSQL y SQLite. Uno de ellos es necesario para la instalación de Bacula.
  3. Bacula Storage Daemon
    Bacula Storage es la parte software que se encarga del almacenamiento y la recuperación de los archivos en los medios de copia de seguridad. En otras palabras, es el daemon que se encarga de leer y escribir en las cintas u otras soporte de almacenamiento.
  4. Bacula File Daemon
    Bacula File, también conocido como cliente Bacula, es el programa de software que se instala en todos los equipos de los que deseamos tener una copia de seguridad. Es específico del sistema operativo en el que se ejecuta y se encarga de proporcionar los archivo cuando Bacula Director los solicita.
  5. Bacula Console
    Bacula Console es el programa que permite al administrador o al usuario comunicarse con Bacula Director. La consola está disponible en la interfaz basada en texto (interfaz TTY), pero existen más versiones que permiten interactuar con el Directror de forma más gráfica.
Bacula Services Description

Características

A continuación vamos a ver algunas de las características principales de Bacula como software de backup. Aunque existen muchos programas para la realización de backup's en red, Bacula destaca por lo siguiente.
  • Seguridad
    • Verificación de archivos previamente catalogados.
    • Autenticación con contraseña CRAM-MD5 entre cada componente.
    • Cifrato TLS/SSL de comunicaciones entre cada componente.
    • Posibilidad de encriptación de los datos de un cliente concreto o de todos en función de una clave propia del cliente.
  • Soporte de múltiples sistemas operativos
    • Programado para manejar nombres de archivos y mensajes de longitud arbitraria.
    • Posibilidad de compresión GZIP por parte del cliente en los archivos a transmitir si así es requerido.
    • Soporte para ACL's y atributos extendidos en la mayoría de sistemas operativos.
    • Control de acceso a la consola diferenciado por usuario, lo que permite que cada uno acceda únicamente a sus datos.
    • Soporte para archivos de más de 2 Gb.
    • Soporte para arquitecturas de 64 bits.
    • Apoyo ANSI y etiquetas de cintas IBM.
    • Copia de seguridad consistente de archivos abiertos para Win32 (WinXP, Win2003 y Vista), pero no en Windows 2000.
      Usa para ello, Volume Shadow Copy (VSS).
    • Soporte para rutas/nombres de archivos de hasta 64K en máquinas Win32.
      Sin límite en Unix/Linux.
  • Control de trabajos
    • Copia de seguridad en red desde un punto centralizado.
    • Incluye planificador de ejecución de tareas.
    • Programación de varios trabajos simultáneamente.
    • Permite la ejecución de un trabajo a varios a la vez.
    • Secuancias de trabajo marcadas con prioridades.
    • Consola de comunicación con el proceso principal.
  • Restauración
    • Recuperación de uno o más archivos seleccionados de forma interactiva, desde la última copia de seguridad o desde una seleccionada con fecha y hora concretas.
    • Recuperación de un sistema completo a hardware nuevo. Está especialmente automatizado para sistemas Linux y Solaris.
    • Posibilidad de restaurar la base de datos del catálogo de forma sencilla.
    • Capacidad para volver a generar la base de datos de catálogo mediante el escaneo de los volúmenes gracias a bscan.
  • Catálogo SQL
    • Catálogo de base de datos para almacenar volúmenes, pools, trabajos y archivos.
    • Soporte para MySQL, PostgreSQL, SQLite.
    • Soporte de consultas SQL a los catálogos.
  • Volúmenes y Pools
    • Soporte de etiquetas en volúmenes, que evitan la sobreescritura accidental.
    • Todos los datos de backup pueden ir al mismo volumen. No se discierne por cliente o sistema operativos. Es el catálogo el que controla qué cosa está en cada lugar. Así el volumen se aprovecha mejor y ofrece mayor rapidez de backup.
    • Cambio de volumen automáticamente cuando el que está en uso está marcado como lleno.
    • Pools y volúmenes ofrecen flexibilidad gracias a la configuración de los mismos. Se permite diferenciar por meses, semanas, días, cliente, etc.
    • El formato de los datos es independiente de la máquina cliente.
  • Soporte para la mayoría de los dispositivos de almacenamiento
    • Soporte para función "autochanger", empleando para ellos una shell y el listado de comandos para mtx. Gracias a ellos soporta prácticamente todos las librerías.
    • Soporte para códigos de barras en "autochanger".
    • Etiquetado automático de cintas por códigos de barras.
    • Soporte para múltiples unidades de carga automática.
    • Seguridad en escritura de datos al realizar un checksum de los datos escritos en cada volumen. Aproximadamente cada 64Kb.
    • Soporte para la miegración de datos. Permite mover datos entre diferentes pools o volúmenes y también el guardado de datos en DVD.

Ventajas

  • Bacula File Daemon, un cliente por cada máquina, lo que facilita la conexión y el backup de datos de cada puesto.
  • Soporte para atributos del sistema de ficheros, lo que garantiza que los datos se restauren con los mismos permisos que tenían en origen.
  • Manejo de copias de seguridad de varios volúmenes.
  • Uso de base de datos para almacenar el estado y los fichero de los que hay copia.
  • Auto-purgado de la base de datos, lo que facilita el mantenimiento de la misma.
  • Velocidad de backup y de restauración de datos.
  • Soporte de mensajes de aviso y de estado de operaciones, lo que facilita saber si algo sale mal.
  • Interfaz de comunicación sencilla y por usuario. Existen también clientes web más visuales.
La entrada Bacula (I) la puedes leer en Puppet Linux.
Leer más

Optimizar base de datos MySQL

MySQL es el motor de base de datos por defecto de numerosas aplicaciones, entre ellas Bacula. Y como otros muchos motores de bases de datos, tiene su parte buena y su parte mala. La parte buena es la flexibilidad y potencia que nos ofrece. La parte mala es que en aplicaciones muy dinámicas, hablando de datos, MySQL tiende a fragmentar las tablas y por lo tanto, espacio en disco ocupado y rapidez de acceso a datos aumentan. Aunque este post lo relacionamos directamente con Bacula, este pequeño truco sirve para cualquier otras aplicación que emplee MySQL. Lo que vamos a explicar aquí, es como optimizar un poco las tablas, es decir, que tras realizar muchas escrituras y borrados y también updates, hacer que la estructura de la tabla vuelva a ser la óptima. Existen dos formas, la primera es la clausulo OPTIMIZE de mysql, y la segunda, un pequeño script, que aparece en la documentación de bacula. Ambas estrategias van a realizar algo parecido, desfragmentar la tabla, repararla y ordenar los índices. Vamos a ver cómo funcionan.
  • OPTIMIZE
    Es una clausula de MySQL y sobre tablas MyISAM da muy buenos resultados. Por lo tanto, para aplicarlo a bacula, simplemente tendremos que ejecutar dicha clausula sobre todas las tablas, una a una. 
    mysql> OPTIMIZE LOCAL TABLE bacula.BaseFiles;
    +------------------+----------+----------+----------+
    | Table            | Op       | Msg_type | Msg_text |
    +------------------+----------+----------+----------+
    | bacula.BaseFiles | optimize | status   | OK       |
    +------------------+----------+----------+----------+
    1 row in set (0.00 sec)
    
    mysql> OPTIMIZE LOCAL TABLE bacula.CDImages;
    +-----------------+----------+----------+----------+
    | Table           | Op       | Msg_type | Msg_text |
    +-----------------+----------+----------+----------+
    | bacula.CDImages | optimize | status   | OK       |
    +-----------------+----------+----------+----------+
    1 row in set (0.00 sec)
    
    Según el grado de fragmentación que presente, el proceso puede llevar más o menos tiempo.
  • script
    Esta forma es algo más elaborada y requiere escribir un poco de código, pero el resultado es mucho más óptimo y queda más logrado. Realizamos el siguiente script,
    #!/bin/bash
    
    inMB=$(du -ms $DIR | awk '{print $1}')
    echo "DB Bacula size: $inMB MB"
    echo "Optimize MySQL Database (I): dump"
    mysqldump -f -uroot -p --opt bacula > /tmp/bacula.sql
    echo "Optimize MySQL Database (II): write"
    mysql -u root -p bacula < /tmp/bacula.sql
    echo "Delete security copy"
    rm -f /tmp/bacula.sql
    newInMB=$(du -ms $DIR | awk '{print $1}')
    echo "New DB Bacula size: $newInMB MB"
    RATIO=`echo "scale=2; ($inMB-$newInMB)/$inMB*100" | bc`
    echo "$RATIO % compress ratio"
    
    Antes de ejecutarlo, intentamos comprender un poco lo que hace, que no es más que realizar un dump de la base de datos bacula para luego volver a insertarla. Al insertarla, genera el schema y borra los datos actuales para volver a meterlos, sacando toda fragmentación y ordenando los índices.
    Un ejemplo de ejecución sería,
    DB Bacula size: 1577 MB
    Optimize MySQL Database (I): dump
    Optimize MySQL Database (II): write
    Delete security copy
    New DB Bacula size: 897 MB
    43.00% compress ratio
    
Cualquier de las dos opciones es buena, y es aconsejable según el uso que se haga de bacula ejecutarla cada 3 o 6 meses. Si el equipo realiza muchas copias de seguridad, ejecutarlo una vez al mes, tampoco sobra. Realmente, lo importante es el porcentaje de espacio que se le gana. En esta ejecución, fue de un 43%, efectivamente lo necesitaba. Si la mejora es de un 3%, obviamente, no ;-)
Leer más

[bacula] Cambiar estado de una cinta

Sobre Bacula ya hemos comentado alguna vez cosas en este blog y hoy quería explicar cómo poder hacer para cambiar el estado de una cinta.
Si empleas Bacula de forma habitual contra una cabina de cintas, sabrás que cada cierto tiempo alguna de las cintas va cambiando de estado, bien por que esté llena, bien por que la hemos sacado, etc. Pues bien, si se nos da el caso de que queremos cambiar el estado de una de las cintas, tenemos que saber cómo hacerlo.
Para ello, partimos del siguiente estado:
* list volume
Pool: Daily
+---------+------------+-----------+---------+-----------------+...
| MediaId | VolumeName | VolStatus | Enabled | VolBytes        |...
+---------+------------+-----------+---------+-----------------+...
|      13 | 365LL4     | Append    |       1 | 166,661,139,456 |...
|      14 | 366LL4     | Purged    |       1 |  91,181,966,336 |...
+---------+------------+-----------+---------+-----------------+...
Pool: Weekly
+---------+------------+-----------+---------+-----------------+...
| MediaId | VolumeName | VolStatus | Enabled | VolBytes        |...
+---------+------------+-----------+---------+-----------------+...
|       3 | 367LL4     | Append    |       1 | 430,330,005,504 |...
|       4 | 368LL4     | Used      |       1 | 433,204,208,640 |...
|       5 | 369LL4     | Used      |       1 | 429,060,667,392 |...
|       6 | 595KL4     | Used      |       1 | 432,945,128,448 |...
|       7 | 596KL4     | Used      |       1 | 432,558,379,008 |...
|       8 | 597KL4     | Used      |       1 | 433,293,364,224 |...
+---------+------------+-----------+---------+-----------------+...
Pool: 3month
+---------+------------+-----------+---------+-----------------+...
| MediaId | VolumeName | VolStatus | Enabled | VolBytes        |...
+---------+------------+-----------+---------+-----------------+...
|       9 | 598KL4     | Archive   |       1 | 476,773,678,080 |...
|      10 | 599KL4     | Append    |       1 | 430,071,247,872 |...
+---------+------------+-----------+---------+-----------------+...
Bajo el campo MediaId tenemos el identificador numérico de la cinta, en VolumeName el nombre de la misma y en VolStatus, el estado. Este estado como vemos tiene varios valores y lo que nos interesa es pasar la cinta de nombre 599KL4 de estado Append a estado Archived. En mi caso, por que la vamos a sacar de la cabina y por lo tanto no interesa que pueda intentar cogerla. Para ello lo primero es actualizar el estado de dicha cinta o volumen.
* update
Update choice:
     1: Volume parameters
     2: Pool from resource
     3: Slots from autochanger
     4: Long term statistics
Choose catalog item to update (1-4): 1
Aquí veremos el listado de parámetros que tenemos a disposición de modificar para un volumen. En nuestro caso, como queremos modificar el estado, elegimos la opción 1.
Parameters to modify:
     1: Volume Status
     2: Volume Retention Period
     3: Volume Use Duration
     4: Maximum Volume Jobs
     5: Maximum Volume Files
     6: Maximum Volume Bytes
     7: Recycle Flag
     8: Slot
     9: InChanger Flag
    10: Volume Files
    11: Pool
    12: Volume from Pool
    13: All Volumes from Pool
    14: All Volumes from all Pools
    15: Enabled
    16: RecyclePool
    17: Action On Purge
    18: Done
Select parameter to modify (1-18): 1
Ahora tenemos que seleccionar el pool de volúmenes (de los que tengamos definidos)
Defined Pools:
     1: Daily
     2: Weekly
     3: 3month
Select the Pool (1-3): 3
Y a continuación el volumen (cinta) que esté dentro de dicho pool.
+---------+------------+-----------+---------+-----------------+...
| MediaId | VolumeName | VolStatus | Enabled | VolBytes        |...
+---------+------------+-----------+---------+-----------------+...
|       9 | 598KL4     | Archive   |       1 | 476,773,678,080 |...
|      10 | 599KL4     | Append    |       1 | 430,071,247,872 |...
+---------+------------+-----------+---------+-----------------+...
Enter *MediaId or Volume name: 599KL4
Puesto que hemos optado por cambiar el estado, nos indicará el estado actual y nos pedirá el nuevo estado.
Updating Volume "599KL4"
Current Volume status is: Append
Possible Values are:
     1: Append
     2: Archive
     3: Disabled
     4: Full
     5: Used
     6: Cleaning
     7: Read-Only
Choose new Volume Status (1-7): 2
Una vez aceptado, marcará el cambio y ya podemos salir.
New Volume status is: Archive
Parameters to modify:
     1: Volume Status
     2: Volume Retention Period
     3: Volume Use Duration
     4: Maximum Volume Jobs
     5: Maximum Volume Files
     6: Maximum Volume Bytes
     7: Recycle Flag
     8: Slot
     9: InChanger Flag
    10: Volume Files
    11: Pool
    12: Volume from Pool
    13: All Volumes from Pool
    14: All Volumes from all Pools
    15: Enabled
    16: RecyclePool
    17: Action On Purge
    18: Done
Select parameter to modify (1-18): 18
Selection terminated.
* quit
Leer más

hp, backup automático

En un post anterior explicamos cómo programar un pequeño script que se encargue de hacer el backup de los router's Enterasys. Hoy vamos a aplicar el mismo procedimiento, apoyándonos en expect, para realizar dicho proceso en equipamiento HP.
A mayores en este caso, vamos a pasar el nombre DNS o la IP del router al que conectarnos en línea de comandos, para así poder ejecutarlo contra varios equipos sin tener que alterar el código.
#!/usr/bin/expect -f

set router [lindex $argv 0]

spawn telnet "$router"
set timeout 60
match_max 100000
expect -exact "Password:"
send -- "my_passwd\n"
expect -- "#"
send "copy running-config tftp server.local $router.cfg unix\r"
expect -- "#"
send "exit\r"
expect -- ">"
send "exit\r"
expect -- "log out"
send "y\r"
send_user "\nSaliendo...\n"
Leer más

Copia de seguridad de routers Enterasys

Que la mejor forma de tener algo seguro es tenerlo apagado eso se sabe desde hace mucho tiempo. Sin embargo, si eso no es posible por que lo necesitas para trabajar en el día a día, como puede ser un router o un switch, tener un backup de la configuración es necesario e importante.
Así que si en tu empresa hay equipos Enterasys, el pequeño script que viene a continuación te puede interesar y mucho. Haciendo uso de expect, se conecta al equipo, se autentica, hace un backup y lo envía a un servidor tftp para que quede seguro.
#!/usr/bin/expect -f

spawn telnet router.local.net
match_max 100000
expect "Username:"
send -- "admin\n"
expect -exact "Password:"
send -- "YOUR_PASS\n"
expect -- "->"
send "delete configs/config.cfg\r"
expect -- "->"
send "show config outfile configs/config.cfg\r"
expect -- "->"
send "copy configs/config.cfg tftp://YOUR_TFTP_SERVER/config.cfg\r"
expect -- "->"
send "exit\r"
send_user "\nSaliendo...\n"
En caso de que algo le pase al equipo y tengamos que emplear una nuevo, ya tendremos de dónde sacar el estado de cada una de las bocas ;-)
Leer más

Opciones de recycle en Samba

Hace unos días publicaba un artículo sobre cómo activar la papelera de reciclaje en el servicio Samba. Así todos aquellos archivos que se hayan borrados podrán ser recuperados de forma simple sin tener que recurrir al backup por un delete mal pensado.
El primer post realmente fue bastante rápido, la intención era introducir la facility. Ya en este vamos a explicar más en detalle todos los parámetros que existe y se le pueden pasar y lo qué significa cada uno. También tenemos pendiente la creación de un pequeño script que se encargue de purgar los archivos más viejos de la papelera, para evitar que se nos llene. Vamos por partes.
Las opciones:
  • recycle:repository
    path de la carpeta que ejercerá de papelera de reciclaje. Si no es especifica nada, por defecto es .recycle.
  • recycle:directory_mode
    Indica los permisos que tendrá la carpeta de reciclaje cuando se cree por primera vez. El valor por defecto es 0700.
  • recycle:subdir_mode
    Lo mismo que el anterior, pero para los subdirectorios.
  • recycle:keeptree
    Establece si cuando se elimina un archivo dentro de subdirectorios dicho árbol se mantendrá o no.
  • recycle:versions
    Indica si se mantendrán las versiones de los ficheros. Si se eliminan dos ficheros con el mismo nombre y dicha opción no está habilitada sólo permanecerá el último. Si está, se creará una copia con el nombre "Copy #x of filename".
  • recycle:touch
    Especifica si la fecha de modificación de un archivo debe ser actualizada cuando éste se mueve a la papelera.
  • recycle:exclude
    Indica las extensiones de los archivos que serán excluidos de ser enviados a la papelera. Se nombrarán con *.ext y se separarán por |.
  • recycle:excludedir
    Hace exactamente lo mismo, pero con nombres de directorios.
  • recycle:noversions
    Si la opción versions está activa a nivel general, se puede desactivar para una seria de extensiones que se especificarán aquí.
  • recycle:minsize
    Establece el tamaño mínimo de los archivos que serán enviados a la papelera. Si son de menor tamaño se borran directamente.
    El tamaño se indica en bytes.
  • recycle:maxsize
    Establece el tamaño máximo de los archivos que serán enviados a la papelera. Si este tamaño es excedido, se borrarán directamente.
    Con en la opción anterior, el tamaño viene dado en bytes.
Un ejemplo completo de las opciones que se le podrían pasar en la sección global sería,
[global]
   recycle:repository = /srv/Trash
   recycle:versions   = TRUE
   recycle:keeptree   = TRUE
   recycle:touch      = FALSE
   recycle:exclude    = *.tmp | *.o | ~$* | *.~?? | *.log
   recycle:excludedir = /tmp  | /cache
   recycle:noversions = *.dat | *.ini
   recycle:minsize    = 512
   recycle:maxsize    = 51200
Y ahora vamos por la parte que nos falta, que no es otra que borrar aquellos archivos que llevan más de #x días en la papelera, para evitar que ésta aumente de tamaño indefinidamente. Aunque puedes compartir la papelera con los usuarios de Samba/ldap como una carpeta más y que sean ellos quien lo gestionen, quizás la opción de borrar los archivos mayores de 30 días automáticamente no esté demás. Para hacerlo, podemos recurrir a cron y emplear find. Dejando una línea tal que así en nuestro /etc/crontab.
30 2 * * *   root   find /srv/Trash/* -mtime +30 -exec rm {} \;
Todos los días a las 2:30 de la mañana se ejecutará y eliminará aquellos archivos mayores de 30 días, haciendo así que la papelera no aumente de tamaño de forma descontrolada.

La entrada Opciones de recycle en Samba la puedes leer en Puppet Linux.
Leer más

Papelera de reciclaje en Samba

Samba es un servidor de archivos que emplea el protocolo SMB/CIFS para permitir la compartición simple de archivos entre equipos, tanto Linux como Windows. Crear un servidor Samba es bastante sencillo y no tiene demasiada complicación poner a funcionar el servicio. Sin embargo, una de las cosas que más gente que lo usa se queja es que no existe una papelera de reciclaje. Esto quiere decir, cuando un usuario elimina desde un equipo Windows un archivo, éste se elimina permanentemente del servidor. No es necesario emplear la combinación Shift - Del para suprimirlo definitivamente.
Por defecto, todos los sistemas operativos dejan los archivos que se borran en la papelera, por seguridad, ya que borrar un fichero es algo delicado. Si nos equivocamos, podemos perder mucho trabajo en muy poco tiempo. Hoy vamos a ver cómo crear una papelera en el servidor Samba, para que todas las cosas que se borren, realmente vayan a la papelera y pasado un tiempo, éstas se borren.
Para empezar, necesitamos editar el fichero de configuración general de samba, smb.conf y añadirle las siguientes líneas en la parte global.
recycle:repository = /tmp/Trash/%u
recycle:keeptree   = TRUE
recycle:versions   = TRUE
recycle:touch      = TRUE
Una vez las tengamos, debemos también de añadir un atributo especial a las carpetas que deseemos que estén afectadas por la configuración de la papelera. En cada carpeta deberemos añadir al final de su configuración la siguiente línea.
[carpeta en red]
   comment = Carpeta en red
   path = /srv/datos
   ...
   vfs objects = recycle
Ya para ir terminando, sólo nos queda crear la carpeta que hemos designada como papelera,
shell> mkdir /tmp/Trash
Sólo para dejarlo claro, podemos usar todos los operandos de Samba para la configuración de las carpetas. En mi caso empleé el nombre de usuario (%u), pero puede emplear el que desees.
Ahora ya sólo nos queda reiniciar el servicio de Samba para poder disfrutar de la nueva configuración.
Desde ahora, cualquier archivo que borre el usuario realmente el servidor lo moverá a ésta carpeta que realizará las tareas de papelera. Si un usuario los necesita, simplemente tendrá que pedirlos al administrador y los podrá recuperar sin tener que recurrir al backup.
Este método tiene un problema, la carpeta Trash podría crecer desmesuradamente, ya que no hay ningún proceso que se encargue de borrarla. En el próximo post, veremos cómo hacerlo.

Más info en la web oficial.
Leer más

Restaurar ficheros en bacula

Bacula es un servidor de backup del que ya hablamos e hicimos alguna que otra cosa en este blog. Entre otras muchas facilidades permite conectarnos de forma transparente a una cabina de cintas y tener programadas una serie de tareas de backup que realiza automáticamente.
Como todo servicio de backup, si un día es necesario recuperar un archivo debe facilitarnos esa tarea, por lo tanto, vamos a ver cómo recuperar archivos que necesitemos de un equipo. Para ello haremos uso del comando bconsole, la consola de conexión y control de Bacula.
shell> bconsole 
Connecting to Director backup.local.net:9101
1000 OK: backup-dir Version: 5.0.2 (28 April 2010)
Enter a period to cancel a command.
*
Este comando nos abrirá un pequeño promt con comandos específicos para el manejo de Bacula  El objetivo de este post no es otro que enseñar a recuperar un archivo desde backup, así que emplearemos el comando restore. Si deseamos más información de lo que se puede o no hacer, tenemos el comando help.
Al seleccionar el modo de recuperación, nos aparecerán las siguiente opciones.
* restore
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"

First you select one or more JobIds that contain files
to be restored. You will be presented several methods
of specifying the JobIds. Then you will be allowed to
select which files from those JobIds are to be restored.

To select the JobIds, you have the following choices:
     1: List last 20 Jobs run
     2: List Jobs where a given File is saved
     3: Enter list of comma separated JobIds to select
     4: Enter SQL list command
     5: Select the most recent backup for a client
     6: Select backup for a client before a specified time
     7: Enter a list of files to restore
     8: Enter a list of files to restore before a specified time
     9: Find the JobIds of the most recent backup for a client
    10: Find the JobIds for a backup for a client before a specified time
    11: Enter a list of directories to restore for found JobIds
    12: Select full restore to a specified Job date
    13: Cancel
Select item: (1-13): 5
Aquí tenemos que elegir una y en nuestro caso, como nos interesa recuperar un archivo de un equipo concreto, la mejor forma es seleccionando la opción 5, "Select the most recent backup for a client". A continuación se nos mostrará un listado de todos los equipos de los que hacemos backup, seleccionaremos el que deseemos.
Defined Clients:
     1: backup-fd
     2: bacula-fd
     3: dhcp-fd
     4: mail-fd
     5: mirror-fd
     6: zabbix-fd
Select the Client (1-6): 6
Tras la selección, Bacula hará un reescaneo de todos los datos que tiene de ese equipo. Puesto que el catálogo lo almacena en base de datos, no habrá que consultarlo en disco/cinta, por lo que será más rápido. Tras recuperar todo el catálogo se nos dará acceso a un promt especial, similar a la navegación en shell de GNU/Linux. De esta forma veremos los archivos de los que tenemos backup y podremos navegar por carpetas y ficheros. Los comandos más importantes y necesarios aquí son cd, ls, mark, markdir y done. En especial estos últimos 3, que se emplearán para marcar los archivos o carpetas que deseemos recuperar y done, que indicará que la selección ha finalizado y se procederá a la recuperación de los datos.
Automatically selected FileSet: zabbix-fs
+-------+-------+----------+----------+------------------+------------+
| JobId | Level | JobFiles | JobBytes | StartTime        | VolumeName |
+-------+-------+----------+----------+------------------+------------+
| 6,644 | F     |    2,219 |  940,846 | 2013-01-13 02:06 | 368BGLL4   |
| 6,671 | I     |       12 |  786,796 | 2013-01-14 02:05 | 365BGLL4   |
| 6,698 | I     |       13 |  253,813 | 2013-01-15 02:05 | 365BGLL4   |
| 6,725 | I     |       12 |  287,815 | 2013-01-16 02:05 | 365BGLL4   |
+-------+-------+----------+----------+------------------+------------+
You have selected the following JobIds: 6644,6671,6698,6725

Building directory tree for JobId(s) 6644,6671,6698,6725... ++++++++++++
1,943 files inserted into the tree.

You are now entering file selection mode where you add (mark) and
remove (unmark) files to be restored. No files are initially added, unless
you used the "all" keyword on the command line.
Enter "done" to leave this mode.

cwd is: /
$ ls
 etc/
 usr/
 var/
$ cd etc
cwd is: /etc/
$ ls
 aide/
 bacula/
 group
 hostname
 passwd
 postfix/
 puppet/
 ssh/
 zabbix/
$ cd zabbix/ 
cwd is: /etc/zabbix/
$ ls
 zabbix_agent.conf
 zabbix_agentd.conf
$ mark zabbix_agentd.conf
1 file marked.
$ done
Bootstrap records written to /var/lib/bacula/zabbix-dir.restore.1.bsr

The job will require the following
 Volume(s)     Storage(s)     SD Device(s)
===========================================
 *368BGLL4     ULT3580-HH4     ULT3580-HH4              

Volumes marked with "*" are online.

1 file selected to be restored.

Run Restore job
JobName:         RestoreFiles
Bootstrap:       /var/lib/bacula/zabbix-dir.restore.1.bsr
Where:           /tmp/bacula-restores
Replace:         always
FileSet:         Full Set
Backup Client:   zabbix-fd
Restore Client:  zabbix-fd
Storage:         ULT3580-HH4
When:            2013-01-16 19:56:16
Catalog:         MyCatalog
Priority:        10
Plugin Options:  *None*
OK to run? (yes/mod/no): yes
Como se puede observar, al escribir done nos indica que se va a proceder a recuperar los ficheros seleccionados y creará un nuevo trabajo de restauración para tal efecto. Si no modificamos ninguna de las opciones, por defecto nos dejará los ficheros seleccionados en /tmp/bacula-restores del equipo remoto. Ya luego tendremos manualmente que moverlos a donde corresponda si procede.
En mi caso, puesto que empleo cintas de backup como medio de almacenamiento, esta tarea se puede demorar algo más, puesto que debe ir buscando los archivos solicitados entre los más recientes en las cintas que procedan. Si empleas disco como medio, será mucho más rápido.
Leer más

Backup de la configuración en Cisco

Si hace unos días intentaba explicar cómo realizar un backup automático de un router Enterasys desde una shell en Linux, hoy toca seguir profundizando en elementos de red, en este caso en router's Cisco, éstos quizás más conocidos y habituales en muchos entornos de trabajo.
En este caso, vamos a ver cómo se realiza un backup completo de la configuración del router, para más adelante poder automatizarlo. Aunque en una serie de pequeños post a modo de chuletas Cisco y los comandos en IOS ya se ha comentado, aquí vamos a ver cómo realizar de forma completa, no solamente citando el comando.
Partimos de un switch Cisco y de un servidor tftp montado en la misma red de acceso y desde el modo de configuración observamos el comando write-memory que no hace otra cosa que volcar todo el contenido de la memoria a un fichero que se deposita en el sistema raíz del equipo.
Router(config-archive)# ?
Archive configuration commands:
  ...
  write-memory  Enable automatic backup generation during write memory
Por lo tanto, entrando en modo de configuración, accedemos al path sobre el que deseamos hacer la copia y volcamos todo el contenido de la configuración en el fichero. Por defecto creará un nombre que será el nombre del router y la fecha de creación.
R0# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R0(config)#archive
R0(config-archive)#path disk0:R0
R0(config-archive)#write-memory
R0(config-archive)#end
Si en vez de dejarlo en el mismo equipo lo que nos interesa es sacar una copia, únicamente habrá que indicar otro path, en este caso un path remoto, vía tftp, tal como sigue.
R0(config-archive)# path tftp://10.10.10.10/R0/
Ahora escribirá el contenido de la memoria en el servidor remoto, quedándonos así con una copia de la configuración del equipo.
Más vale prevenir... que luego volver a configurar ;-)
Leer más

Enterasys, backup automático

Todos sabemos la importancia de tener backup's de nuestros sistemas y de la importancia de que los mismos sean constantes. De nada nos sirve un backup del mes pasado si las cosas están cambiando muy a menudo. Para solucionar estes problemas ya hablamos en este blog de bacula, un potente software cliente-servidor para la realización automática de backups.
Sin embargo, qué pasa si tenemos que hacer backup's de otros elementos de la red, como pueden ser switch's o router's. Estos elementos son tanto o más importantes que los propios equipos, ya que si tenemos la información, pero no tenemos forma de compartirla, de nada nos sirve. Es muy raro encontrar un equipo de estos que permita automatizar el backup y Enterasys no lo hace. Por norma general, hay siempre que ejecutar una serie de comandos que no se pueden encadenar, lo que complica su automatización. Al final cuando hay un problema, siempre se obtiene la misma frase "sí, había que hacerlo, pero no lo hice". Y ahí empiezan todos los problemas.
Así que ya sabes, si tienes equipos Enterasys en tu oficina, usando expect puedes automatizar la creación de backup's de los sistemas.
#!/usr/bin/expect -f

set router [lindex $argv 0]

spawn telnet "$router"
match_max 100000
expect "Username:"
send -- "admin\n"
expect -exact "Password:"
send -- "mi_passwd\n"
expect -- "->"
send "delete configs/$router.cfg\r"
expect -- "->"
send "show config outfile configs/$router.cfg\r"
expect -- "->"
send "copy configs/$router.cfg tftp://server.local/$router.cfg\r"
expect -- "->"
send "exit\r"
Su empleo es sencillo, se pasa como argumento la IP o nombre del router con lo que él accede y deja una copia de la configuración en nuestro servido tftp preferido. Como sabéis, Enterasys realizar las copias a/desde un servidor tftp y necesitan estar en la misma red que los propios equipos, en caso de que empleéis VLAN's.
Leer más

status bacula en zabbix

De bacula ya hemos hablado alguna vez en este blog y de zabbix, creo que también, así que ahora estaría bien unir ambos en un mismo post y hacer que los mensajes de estado de los trabajos de bacula vayan a un monitor zabbix, para así saber si el proceso de backup se realizó o no correctamente. Saber que el backup está OK es muy importante y zabbix nos permite sacar alertas de cambios de estado de forma muy simple, por lo que se acabó leer los informes que bacula envía por mail! En los foros de zabbix hay un ejemplo de cómo unir zabbix + bacula, pero la verdad es que no me pareció un poco consufa y complicada de montar, así que me puse a investigar un poco las posibilidades de bacula de enviar informes y cómo poder obtener el estado para enviárselo a zabbix. Tras leer un poco de documentación, simplemente me di cuenta de que era más efectivo emplear la directiva RunScript dentro de Jobs que editar y capturar todo el mensaje. Así que... manos a la obra! Primero comenzamos editando los ficheros de trabajos de cada cliente, ya que el envío del estado del backup lo realizará el propio cliente y no el servidor. Esto tiene sus pros y sus contras. Por el momento he decidido dejarlo así. Un ejemplo de trabajo sería el siguiente,
Job {
  Name = "backup-equipo23"
  JobDefs = "DefaultJob"
  Client = equipo23-fd
  FileSet = "equipo23-fs"
  Write Bootstrap = "/var/lib/bacula/backup-equipo23.bsr"
  RunScript {
    RunsWhen = After
    Command = "/usr/local/bin/bacula %l %e"
    RunsOnClient = yes
    RunsOnFailure = yes
    RunsOnSuccess = yes
  }
  Enabled = yes
}
La única diferencia respecto de lo que ya había, fue agregarle las líneas que están en negrita y que hacen justamente lo que nos interesa, ejecutar un pequeño script que envía el estado del backup según el tipo (Full, Incremental, etc). En la documentación oficial de bacula está descrito, pero el tipo de variables que se le pueden pasar son:
  • %c -- Client's name
  • %d -- Director's name
  • %e -- Job Exit Status
  • %i -- JobId
  • %j -- Unique Job id
  • %l -- Job Level
  • %n -- Job name
  • %s -- Since time
  • %t -- Job type (Backup, ...)
  • %v -- Volume name
Y en nuestro caso pasamos un %l, para que nos indique el nivel de trabajo y %e, el estado de finalización del mismo.
Ahora hay que hacer el pequeño script que se ejecutará cuando el trabajo finalice. Éste es,
#!/bin/bash

case "$1" in
 Incremental)
  zabbix_sender -c zabbix_agentd.conf -k bacula.inc.verify.result -o $2
  ;;
 Full)
  zabbix_sender -c zabbix_agentd.conf -k bacula.full.verify.result -o $2
  ;;
 *)
  zabbix_sender -c zabbix_agentd.conf -k bacula.other.verify.result -o $2
  ;;
esac
Ya que como $1 recibimos el tipo de nivel de backup y sólo realizamos backup's Full o Incremental y como $2 recibimos el estado, por lo tanto, es lo que directamente enviamos a zabbix. El estado enviado puede ser OK, Error, Fatal Error, Canceled, Differences o Unknown term code. Aquí podemos optar por pasarlo a número o no, yo prefiero dejarlo como tipo texto, ya que zabbix también permite sacar alertas de campos de tipo texto.
Llegados a este punto ya sólo queda crear una pequeña plantilla de zabbix que permita obtener los datos enviados como Trapper y un trigger que reaccione ante cambios. Los 3 items a los que hace referencia el script tienen estas propiedades:
Nombre descriptivo: Full backup
Tipo: Trapper ZABBIX
Monitor: bacula.full.verify.result
Tipo de información: Texto
Conservar el histórico durante (en días): 60
Estado: Activo
Aplicaciones: bacula
Y por su parte, los triggers asociados,
Nombre: {HOSTNAME} Full backup fail!
Expresión: {Template_bacula:bacula.full.verify.result.regexp(OK)}#1
Gravedad: Alta
Leer más

Clonar particiones en red

Aunque este es un tema bastante recurrido en la red, tuve que emplearlo hace poco para rescatar un disco y me parece interesante ponerlo, para que quede constancia y así la próxima vez que lo tenga que emplear, simplemente lo veo y listo.
SI tenéis la necesidad de clonar un disco en red, la forma más simple de hacerlo es empleando netcat y dd. Del lado del cliente, es decir, del lado del equipo que tiene el disco a clonar, tenemos que ejecutar lo siguiente,
shell> dd if=/dev/vg0/home bs=1M | nc 192.168.1.33
Mientras que del lado del servidor, es decir, el equipo que va a recibir los datos de la clonación, tenemos que ejecutar,
shell> nc -l 9999 | dd of=/dev/vg0/home_ext bs=1M
Una breve explicación de lo que se va a realizar es la siguiente. Primero se ejecuta el segundo comando, para abrir el puerto 9999 y dejar que el flujo de datos que llegue se escriban en la partición home_ext. Ésta debe de existir. A continuación, se ejecuta el primer comando, para enviar todos los datos vía netcat al equipo que está a la escucha. Como se puede observar, dd nos da la clave, if es el origen de datos y of es el destino de los mismos.
Leer más

Cómo eliminar servicios en Windows

Los servicios de Windows son un tema importante, pero hay veces que el manejo de los mismos se complica, ya bien sea por que el programa que se desinstaló no lo ha borrado o bien por que al registro de Windows le da por no dejárnoslo borrar. Pues bien, eso mismo me ha pasado recientemente con un equipo con Windows XP y el servicio bacula. Desinstalé una versión y al instalar la nueva versión ya no dejaba instalar el servicio bacula-fd. Mirando un poco, ejecuté el visor de servicios (services.msc) y vi que el servicio no estaba activo, pero sí estaba allí. No podía hacer nada, por que Windows lo había marcado como servicio para desinstalar, por lo tanto no lo podía arrancar (aunque los ejecutables volvían a existir) ni tampoco borrar. Menos mal que en estos casos la solución está en la consola, así que buscando un poco por google, aparece la solución de cómo borrar un servicio desde cmd. Para hacerlo, hay que emplear el ejecutable sc.
cmd> sc delete service
Por lo tanto, para borrar el servicio de bacula,
cmd> sc delete "Bacula Service Program"
Tras ejecutar esto, volví a tener el mismo fallo de que es imposible borrar el servicio, así que tuve que optar por una forma más brusca de realizarlo, es decir, editar el registro. Por lo tanto, vamos a inicio -> ejecutar -> regedit y buscamos la rama
HKEY_LOCAL_MACHINE\
 |
 -SYSTEM\
  |
  -CurrentControlSet\
   |
   -Services
y borramos todo lo referente al servicio que deseemos limpiar. Tras esto, ya podemos volver a instalar el servicio, esta vez relacionado con el nuevo ejecutable.
cmd> bacula-fd.exe /install
Leer más

Backup de ACL's

Si estás trabajando en un servidor GNU/Linux que maneja ACL's, especialmente complejas para usuarios y grupos, lo mejor que puedes hacer es realizar un backup de las mismas diariamente, por que si un día necesitas restaurar algo, lo más probable es que también tengas que reestablecer la larga cadena de ACL's que conlleva y eso, según qué casos puede no ser 100% simple. Para poder hacer lo comentado, existe el comando getfacl que no es más que un pequeño programa que consultas las ACL's del directorio pasado como parámetro y permite volcar la salida a un fichero de texto. A continuación, os dejo un ejemplo de cómo quedaría el script que realizar el backup de las ACL's.
#!/bin/bash

BACKUP_DIRS="/data"
STORE_ACL="/var/backups"
umask 077
for i in $BACKUP_DIRS
do
 cd $i; /usr/bin/getfacl -R . > $STORE_ACL/$i.acl
done
Y puesto que todos nuestros sistemas está automatizados y manejados con puppet, creamos una pequeña clase que permite instalar este script y ejecutarlo diariamente sin esfuerzo alguno.
class configuracion::acl {
 file { "/usr/local/sbin/backup-acl":
   owner => root,
   group => root,
   mode => 0500,
   source => "puppet://$master/files/backup-acl",
   ensure => present;
 }

 cron { "domain-acl":
   command => "/usr/local/sbin/backup-acl",
   user => root,
   hour => 1,
   minute => 15,
   require => File [ "/usr/local/sbin/backup-acl" ],
   ensure => present;
 }
}
Así que para poder usarla, únicamente hay que agregar la clase creada en los equipos que se desee.
include configuracion::acl
Leer más

Restaurar backup de cuentas zimbra

Si en un post reciente hablamos de cómo poder realizar un backup de las cuentas de correo en Zimbra, ahora toca el momento de saber qué hacer si es necesario recurrir a dicho backup. Pues bien, antes de realizar ninguna acción tenemos que saber las opciones que nos permite el comando zmmailbox a la hora de restaurar datos a una cuenta. Si la cuenta fue completamente borrada no importa, pero si todavía tiene datos, ésto sí es importante. Por lo tanto, primero vemos las opciones y luego cómo recuperar los datos.
  • modify
    Modifica el elemento viejo con el nuevo.
  • replace
    Borra el elemento existente y lo vuelve a crear.
  • reset
    Borra todos los elementos antes de crear los nuevos.
  • skip
    No importa elementos duplicados.
Bien, entonces sirviendonos del comando zmmailbox y del fichero de backup, podemos realizar lo siguiente:
shell> zmmailbox -z -m cuenta@server.com \
       postRestURL "//?fmt=tgz&resolve=skip" \
       cuenta@server.com.tgz
En nuestro caso, como la cuenta existe y no queremos reemplazar todo, simplemente recuperamos lo borrado respecto del último backup. En caso de que quisiéramos recuperar todo,
shell> zmmailbox -z -m cuenta@server.com \
       postRestURL "//?fmt=tgz&resolve=reset" \
       cuenta@server.com.tgz
Leer más

Backup de cuentas de correo zimbra

Zimbra tiene muchas opciones y suele ser bastante sólido, pero sacar una copia de seguridad de sus datos nunca es mala opción, especialmente teniendo en cuenta que si no es el software puede ser el hardware el que termine fallando alguna vez, así que... más vale prevenir ;-)
Para realizar un backup de una cuenta de correo, desde Zimbra se puede usar el comando zmmailbox y sacar los datos de una cuenta. Existe dos formatos de salida:
  • Formato .zip
    shell> zmmailbox \
           -z \
           -m user@local.net \
           getRestURL "//?fmt=zip" \
           > user_at_local_net.zip
    
  • Formato .tgz
    shell> zmmailbox \
          -z \
          -m user@local.net \
           getRestURL "//?fmt=tgz" \
           > user_at_local_net.tgz
    
Almacenando correctamente estos ficheros y sacándolos de forma periódica, siempre sería posible volver a restaurar una cuenta de correo en caso de fallo. Puedes ver cómo hacerlo, aquí.

A continuación os dejo un pequeño script que simplifica esta tarea de backup. Recorre todas las cuentas del servidor de correo y hace un volcado de las mismas.
#!/bin/bash
for i in `zmprov -l gaa`
do
  zmmailbox -z -m $i getRestURL "//?fmt=tgz" > /srv/backup/$i.tgz
done
Leer más

Manejo de cintas de backup en GNU/Linux

Hace tiempo que tenía planeado escribir este post y con ello espero que ayudar algún día a alguien que necesite manejar una librería o unidad de cintas. Actualmente están perfectamente soportadas en sistemas GNU/Linux y en uno de los próximos post espero comenzar a mostrar cómo conseguir que bacula funcione perfectamente contra la librería. Pero antes de nada... hay que saber manejar la librería y las cintas. Bacula, o cualquier otro cliente de backups, lo único que hace es manejar de forma automática estos comandos según lo necesite.
Por lo tanto, vamos a ello. Primero hay que tener claro un par de conceptos. En prácticamente todos los sistemas GNU/Linux, el cargador de cinta está identificado como un dispositivo /dev/sgX (en mi caso será /dev/sg0) y la cinta, una vez cargada como /dev/nstX (en mi caso /dev/nst0). Existen comandos perfectamente pensados para manejar ambos dispositivos. Para el primero emplearemos mtx y para el segundo, el comando mt.
Hay que recordar que la cintas de backup son secuenciales y por lo tanto, al cargarlas, leer o escribir en ellas primero hay que posicionarse en donde corresponda. Una vez aclarado esto, vamos a ver las principales opciones para manejar la unidad de cintas.
  • Consultar el estado de la librería
    shell> mtx -f /dev/sg0 status
    
  • Cargar una cinta
    shell> mtx -f /dev/sg0 load numero_de_cinta
    
  • Descargar una cinta
    shell> mtx -f /dev/sg0 unload
    
Y una vez que tenemos una cinta cargada, también podemos hacer cosas con ella, para comprobar que realmente funciona correctamente. Para ello,
  • Consultar el estado de una cinta
    shell> mt -f /dev/nst0 status
    
  • Rebobinar la cinta cargada
    shell> mt -f /dev/nst0 rewind
    
  • Expulsar la cinta, después de rebobinarla
    shell> mt -f /dev/nst0 eject
    
  • Escribir directamente en la cinta
    shell> tar -cvf /dev/nst0 fichero/directorio
    
  • Escribir un eof después de escribir algo
    Permite luego poder ir saltando de fichero en fichero.
    shell> mt -f /dev/nst0 eof
    
  • Salta de fichero en fichero por la cinta
    Es necesario escribir un eof entre ficheros.
    shell> mt -f /dev/nst0 fsf
    
  • Sacar un fichero de la cinta estando al principio del mismo
    Recordar, la cinta es secuencial. Primero nos posicionamos y luego leemos.
    El fichero o directorio leído quedará almacenado en el directorio actual.
    shell> tar -xvf /dev/nst0
    
  • Borrar una cinta
    shell> mt -f /dev/nst0 erase
    
Leer más

Formulario de contacto

Nombre

Correo electrónico *

Mensaje *

Últimos comentarios