Nagios en Debian Lenny

Hoy veremos como instalar y configurar Nagios de una manera básica en Debian Lenny.

Para instalarlo, bastará con un:

aptitude install nagios3

Nos vamos al directorio del Nagios:

cd /etc/nagios3

Creamos un login para entrar en Nagios e introducimos la contraseña:

htpasswd -c htpasswd.users nagiosadmin

Para probar, introducimos la IP de nuestro servidor seguido de nagios3 en la barra de direcciones y nos debería de salir algo parecido a esto:



Los archivos de configuración se encuentran en el directorio /etc/nagios3/conf.d. En el directorio /etc/nagios3 se encuentra un archivo de configuración (nagios.cfg) que de momento no vamos a tocar, ya que no es necesario para una configuración básica.

Vamos a centrarnos en los archivos que están en el directorio conf.d. El primero, contacts.cfg:

Aqui se le dice a Nagios a quien enviará emails, de que tipo, con que frecuencia, etc. Podemos crear grupos de usuarios para que reciban las mismas notificaciones. En este caso, solo creare un usuario y un grupo.

Ahora, voy a explicar del modo en que yo configuro Nagios. Seguro que los habrá mejores, pero a mi me funciona bien así. Vamos a configurar 3 archivos:

El primero, es el hosts.cfg. Si este archivo no existe, lo creamos. En el, vamos a introducir todos los hosts, dispositivos de red, etc. de los que queramos monitorizar algo. Soy partidario de organizar muy bien los archivos de texto, por lo que pongo etiquetas por grupos y demás. Un ejemplo de este archivo de configuración, podría ser el siguiente:

########################################

### DISPOSITIVOS DE RED ###

########################################

define host {

host_name Fortinet_Interna

alias Fortinet_Interna

address 192.168.1.1

use generic-host

}

define host {

host_name Fortinet_Externa

alias Fortinet_Interna

address 172.16.0.2

use generic-host

}

define host {

host_name Router_Ono_Interna

alias Router_Ono_Interna

address 172.16.0.1

use generic-host

}

define host {

host_name Switch1

alias Switch1

address 192.168.1.205

use generic-host

}

define host {

host_name Switch2

alias Switch2

address 192.168.1.206

use generic-host

}

define host {

host_name Switch3

alias Switch3

address 192.168.1.207

use generic-host

}

define host {

host_name Switch4

alias Switch4

address 192.168.1.208

use generic-host

}

define host {

host_name DiscoRed1

alias DiscoRed1

address 192.168.1.22

use generic-host

}

define host {

host_name DiscoRed2

alias DiscoRed2

address 192.168.1.240

use generic-host

}

define host {

host_name Centralita1

alias Centralita1

address 192.168.1.200

use generic-host

}

define host {

host_name Centralita2

alias Centralita2

address 192.168.1.201

use generic-host

}

define host {

host_name iLO-SRV*****

alias iLO-SRV*****

address 192.168.1.250

use generic-host

}

define host {

host_name iLO-ESXi1

alias iLO-ESXi1

address 192.168.1.251

use generic-host

}

define host {

host_name iLO-SRVW2008

alias iLO-SRVW2008

address 192.168.1.252

use generic-host

}

########################################

### SERVIDORES WINDOWS ###

########################################

define host {

host_name SRV*****

alias SRV*****

address 192.168.1.5

use generic-host

}

define host {

host_name vSRV*****

alias vSRV******

address 192.168.1.4

use generic-host

}

define host {

host_name vSRVApliWeb

alias vSRVApliWeb

address 192.168.1.47

use generic-host

}

########################################

### SERVIDORES DEBIAN ###

########################################

define host {

host_name vSRVDebian

alias vSRVDebian

address 127.0.0.1

use generic-host

}

define host {

host_name vSRVDebianWS1

alias vSRVDebianWS1

address 192.168.1.103

use generic-host

}

########################################

### SERVIDORES VMWARE ###

########################################

define host {

host_name ESXi1

alias ESXi1

address 192.168.1.14

use generic-host

}

El siguiente archivo es el hostgroups_nagios2.cfg. En este archivo vamos a agrupar todos los hosts dados de alta en el archivo anterior. A Nagios no le gusta que un host no esté dentro de un grupo (Nos mandará “Warnings”). Así que no se debe olvidar meter a todos los host en grupos. En mi caso el archivo ha quedado así:

########################################

### GRUPOS DISPOSITIVOS DE RED ###

########################################

define hostgroup {

hostgroup_name Dispositivos_Red

alias Dispositivos_Red

members Fortinet_Interna,Fortinet_Externa,Router_Ono_Interna,Centralita1,Centralita2,DiscoRed1,DiscoRed2,Switch1,Switch2,Switch3,Switch4,iLO-SRVAstarte,iLO-ESXi1,iLO-SRVW2008

}

########################################

### GRUPOS SERVIDORES WINDOWS ###

########################################

define hostgroup{

hostgroup_name Servidores_Windows ; The name of the hostgroup

alias Servidores Windows ; Long name of the group

members SRV*****,vSRV*****,vSRVApliWeb

}

########################################

### GRUPOS SERVIDORES DEBIAN ###

########################################

define hostgroup {

hostgroup_name Servidores_Debian

alias Servidores Debian GNU/Linux

members vSRVDebian, vSRVDebianWS1

}

########################################

### GRUPOS SERVIDORES WEB ###

########################################

define hostgroup {

hostgroup_name Servidores_Web

alias Servidores Web

members vSRVDebian, vSRVDebianWS1

}

########################################

### GRUPOS SERVIDORES VMWARE ###

########################################

define hostgroup {

hostgroup_name Servidores_VMWARE

alias Servidores VMWARE

members ESXi1

}

El último archivo a editar es el services_nagios2.cfg. En este, vamos a dar de alta todos los servicios que queramos que Nagios monitoree y le asignaremos los grupos de hosts a dichos servicios. Los servicios los he “copiado” del archivo /etc/nagios3/conf.d/localhost_nagios2.conf (Servicios a monitorear en máquinas Linux) y del archivo windows.cfg (Servicios a monitorear en máquinas Windows). Este último archivo lo he buscado con un updatedb + locate, porque no me acordaba de donde se encontraba. En mi caso, este archivo ha quedado así:

########################################

### SERVICIOS DISPOSITIVOS DE RED ###

########################################

define service {

hostgroup_name Dispositivos_Red

service_description PING

check_command check_ping!100.0,20%!500.0,60%

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

########################################

### SERVICIOS SERVIDORES WINDOWS ###

########################################

define service{

hostgroup_name Servidores_Windows

service_description NSClient++ Version

check_command check_nt!CLIENTVERSION

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

define service{

hostgroup_name Servidores_Windows

service_description Tiempo Funcionando

check_command check_nt!UPTIME

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

define service{

hostgroup_name Servidores_Windows

service_description Rendimiento CPU

check_command check_nt!CPULOAD!-l 5,80,90

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

define service{

hostgroup_name Servidores_Windows

service_description Uso de memoria

check_command check_nt!MEMUSE!-w 80 -c 90

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

define service{

hostgroup_name Servidores_Windows

service_description Espacio en Unidad C

check_command check_nt!USEDDISKSPACE!-l c -w 80 -c 90

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

#define service{

# hostgroup_name Servidores_Windows

# service_description W3SVC

# check_command check_nt!SERVICESTATE!-d SHOWALL -l W3SVC

# use generic-service

# notification_interval 0 ; set > 0 if you want to be renotified

# }

define service{

hostgroup_name Servidores_Windows

service_description Explorer

check_command check_nt!PROCSTATE!-d SHOWALL -l Explorer.exe

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

########################################

### SERVICIOS SERVIDORES DEBIAN ###

########################################

define service {

hostgroup_name Servidores_Debian

service_description SSH

check_command check_ssh

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

# Define a service to check the disk space of the root partition

# on the local machine. Warning if < 20% free, critical if

# < 10% free space on partition.

define service{

hostgroup_name Servidores_Debian

service_description Espacio en disco

check_command check_all_disks!20%!10%

use generic-service ; Name of service template to use

notification_interval 0 ; set > 0 if you want to be renotified

}

# Define a service to check the number of currently logged in

# users on the local machine. Warning if > 20 users, critical

# if > 50 users.

define service{

hostgroup_name Servidores_Debian

service_description Usuarios Actuales

check_command check_users!20!50

use generic-service ; Name of service template to use

notification_interval 0 ; set > 0 if you want to be renotified

}

# Define a service to check the number of currently running procs

# on the local machine. Warning if > 250 processes, critical if

# > 400 processes.

define service{

hostgroup_name Servidores_Debian

service_description Procesos Totales

check_command check_procs!250!400

use generic-service ; Name of service template to use

notification_interval 0 ; set > 0 if you want to be renotified

}

# Define a service to check the load on the local machine.

define service{

hostgroup_name Servidores_Debian

service_description Rendimiento CPU

check_command check_load!5.0!4.0!3.0!10.0!6.0!4.0

use generic-service ; Name of service template to use

notification_interval 0 ; set > 0 if you want to be renotified

}

########################################

### SERVICIOS SERVIDORES WEB ###

########################################

define service {

hostgroup_name Servidores_Web

service_description HTTP

check_command check_http

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

########################################

### SERVICIOS SERVIDORES VMWARE ###

########################################

define service {

hostgroup_name Servidores_VMWARE

service_description PING

check_command check_ping!100.0,20%!500.0,60%

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

Ahora vamos a comprobar que la configuración que hemos introducido es correcta. Para ello:

nagios -v /etc/nagios3/nagios.cfg

Seguramente Nagios nos de algún error. Pero nos indica el archivo y línea en el que se encuentra, por lo que solo tendremos que ir y corregirlos. Habrá que repetir este proceso hasta que NAgios nos diga que no encuentra ningún error. Una vez conseguido, reiniciamos Nagios:

/etc/init.d/nagios3 restart

Si nos vamos a la interfaz web de Nagios e intentamos forzar un check de los servicios en todos los hosts, nos dará un error porque Nagios por defecto no ejecute comandos externos. El error en cuestión es el siguiente:

Could not stat() command file ‘/var/lib/nagios3/rw/nagios.cmd’!

Para arreglar esto, editamos el archivo /etc/nagios3/nagios.cfg y nos vamos a la línea donde se encuentra la directiva ‘check_external_commands’ y le ponemos un valor igual a 1, como en la imagen:

c3 external commands.png

Ejecutamos los siguientes comandos:

/etc/init.d/nagios3 stop

dpkg-statoverride —update —add nagios www-data 2710 /var/lib/nagios3/rw

dpkg-statoverride —update —add nagios nagios 751 /var/lib/nagios3

/etc/init.d/nagios3 start

Ahora ya deberá funcionar correctamente la interfaz web, le pidamos lo que le pidamos…
El siguiente paso es configurar el envío de correos electrónicos. En el primer archivo que editamos pusimos la configuración de los contactos a los que les tenía que llegar el correo y ahora vamos a configurar el envío de los mails. Hay varios modos de hacerlo (Con scripts de Perl, usando un servidor de correo local, un smarthost, etc.). En mi caso he instalado y configurado un Postfix en el propio servidor de Nagios para que mande los emails usando un servidor de correo externo.
Instalamos Postfix:

aptitude install postfix

Durante la instalación, le diremos que vamos a usar un SmartHost y le pondremos el nombre de nuestro servidor de correo. Por ejemplo: smtp.midominio.com
Una vez instalado, creamos el archivo /etc/postfix/sasl/passwd y le introducimos la siguiente información:

[smtp.tudominio.com]:25 tucuenta@tudominio.com:TuPassword

Guardamos el archivo y ahora le asignamos los permisos correspondientes:

chmod 600 /etc/postfix/sasl/passwd

Y por último lo transformamos en un fichero indexado de tipo hash con la ayuda de postmap:

postmap /etc/postfix/sasl/passwd

Reiniciamos Postfix (/etc/init.d/postfix restart) y para probar el envío ejecutamos:

mail -s “Prueba” tucorreo@tudominio.com

Debemos pulsar CTRL+D para que envíe

Y nos debería de llegar el correo…

Para monitorear equipos con Linux o dispositivos de red a los que solo queramos hacerle un ping, con esto será bastante. Pero como supongo que también habrá que controlar máquinas Windows, vamos a seguir con la configuración. Ahora vamos a editar el archivo /etc/nagios-plugins/config/nt.cfg y lo dejamos así:

# ‘check_nt’ command definition

define command{

command_name check_nt

command_line /usr/lib/nagios/plugins/check_nt -H $HOSTADDRESS$ -p 12489 -s TuPassword -v $ARG1$ $ARG2$

}

Reiniciamos el Nagios para que valide los cambios y ahora vamos a configurar los equipos Windows. Para que Nagios recupere la información de estos equipos, vamos a instalarle un cliente llamado NSClient++. Lo podemos descargar de aquí. Como este cliente no es solo para Nagios, tendremos que hacer unos cuantos ajustes en su configuración para que funcione correctamente.

Durante la instalación, le diremos la IP del servidor Nagios, así como la contraseña que escribimos antes en el archivo /etc/nagios-plugins/config/nt.cfg. A la hora de seleccionar la ventana con los “checks”, marcaremos todos menos la última opción (WMI Checks…creo que se llamaba). Cuando nos pregunté si queremos iniciar el servicio, le decimos que NO.

Ahora deberemos seguir 5 pasos para terminar de configurar el cliente.

1. Nos vamos al administrador de servicios, buscamos el servicio del NSClient y le damos a ver sus propiedades. Debemos marcar la casilla que “Permite a los servicios interactuar con el escritorio”. Lo tenemos en la siguiente imagen:

Todavía NO inciamos el servicio. Sigamos.

El archivo de configuración se llama NSC.ini y se encuentra en el directorio donde hemos instalado el cliente (Normalmente en Archivos de Programa >> NSclient). Este archivo consta de varias secciones con distintas directivas en cada una. Vamos a seguir los 4 pasos restantes:

2. Dentro de la sección [Modules] vamos a descomentar todo, a excepción de las directivas ‘RemoteConfiguration.dll’ y ‘CheckWMI.dll’. También descomentamos la directiva ‘Password’ y le ponemos la contraseña que pusimos durante la instalación del cliente

3. Ahora, en la sección [Settings], descomentamos la directiva ‘allowed_host’ y le ponemos la IP del servidor Nagios.

4. En la sección [NSClient], descomentamos la directiva ‘port’, dejando el número de puerto establecido por defecto.

5. Por último, desde una ventana de MS-DOS, ejecutamos el comando: lodctr /R. Con este comando, aunque no es obligatorio, reiniciamos los contadores de rendimiento y demás, evitando errores como el de la siguiente imagen:

Pues ya hemos terminado. Ahora, si apuntamos a la interfaz web de Nagios y nos validamos, debería de aparecernos algo parecido a esto: (Variará según los equipos que hayáis dado de alta)

Leer más »

Backups con Bacula (II)

Bueno, continuemos. La primera parte del artículo esta aquí.

Una vez hecha la copia de seguridad de todos los archivos de configuración, vamos a instalar el paquete necesario para que Bacula use MySQL para guardar su base de datos.

Primero, instalemos el servidor MySQL:

aptitude install mysql-server

Durante la instalación, nos pedirá la contraseña del usuario root de MySQL y algunas cosas más.

Luego, instalaremos el paquete necesario para que Bacula use MySQL:

aptitude install bacula-director-mysql

A mi, personalmente, me gusta usar phpmyadmin para gestionar las bases de datos de MySQL. Para instalarlo:

aptitude install phpmyadmin

Una vez esté todo instalado, ya podemos empezar a configurar Bacula.

Lo primero que hago es saber donde voy a almacenar mis copias de seguridad. En mi caso, lo haré en un disco de red al que accederé montando una carpeta en Debian que apunta a un recurso compartido por el disco de red.

Para montar esa unidad, primero creo el directorio con el siguiente comando:

mkdir /mnt/bacula

Una vez creado, monto en ese diectorio la carpeta del disco de red con el siguiente comando:

mount -t smbfs -o usuario@dominio,password=Password //192.168.1.240/bacula /mnt/bacula

Lo probamos, y si funciona, creamos un script que contenga el comando anterior y lo copiamos en la carpeta /etc/init.d. Luego, ejecutamos el siguiente comando para que el script se ejecute siempre al arranque de nuestro sistema:

update-rc.d montar_carpetas_bacula.sh defaults

Aclaración: montar_carpetas_bacula.sh es el nombre que le he dado al script que he creado. Luego le di permisos 744 y de ejecución, antes de copiarlo a la carpeta /etc/init.d

Ahora, vamos a empezar a tocar los archivos de configuración de Bacula. Vamos a empezar por los más sencillos, pero antes debemos modificar unos parámetros del archivo principal. Para ello:

nano /etc/bacula/bacula-dir.conf

Aquí modificamos el nombre del demonio Director y le ponemos una IP (En este caso el propio ordenador) y le establecemos una contraseña.

Continuemos editando los archivos más sencillos. Nos vamos a editar el bconsole.conf:

Le ponemos el nombre y la contraseña del Director. Guardamos y salimos (Si usamos nano sería un CTRL+O y CTRL+X, respectivamente)

Ahora vamos a por el bacula-sd.conf:

En el punto 1, configuramos el nombre y la IP del propio demonio. En el 2, le ponemos los datos del Director. En el 3, ponemos los datos para el Tray Monitor (Ya lo veremos más adelante). En punto 4 es un ejemplo de un dispositivo donde guardar las copias de seguridad. (En nuestro caso, es un archivo). Si queremos guardar las copias de cada equipo/servidor en carpetas diferentes, deberemos crear un dispositivo por cada equipo/servidor.configuración

Continuamos con el bacula-fd.conf. La configuración es muy parecida al archivo anterior:

En el punto 1, configuramos los datos del director. En el 2, los del Tray Monitor. En el 3, el nombre y la IP del propio demonio y en el 4, la configuración de los envíos de alertas por email. Este archivo es el que tendremos que modificar en cada cliente del que hagamos copias de seguridad. Ya lo iremos viendo…

El archivo que nos queda por configurar, el bacula-dir.conf, es el principal. En el vamos a poner cuando se hacen las copias, de que clientes, que tipo de copias, etc. Voy a poner una breve descripción de cada apartado que configuraremos dentro de este archivo y un ejemplo de cada uno:

Director

En el configuraremos (Aunque ya lo hicimos anteriormente) los datos del propio demonio (Su IP, nombre, puerto a usar, etc.) En mi caso, la configuración quedó así:

Director { # define myself

Name = vSRVDebian-dir

DIRport = 9101 # where we listen for UA connections

QueryFile = “/etc/bacula/scripts/query.sql”

WorkingDirectory = “/var/lib/bacula”

PidDirectory = “/var/run/bacula”

Maximum Concurrent Jobs = 3

Password = “*****************” # Console password

Messages = Daemon

DirAddress = 127.0.0.1

}

Catalogo

Aquí vamos a definir los datos del Catálogo, que es la base de datos que usa Bacula. Pondremos el nombre de la base de datos, así como su usuario y contraseña. (Estos datos los pusimos cuando instalamos el paquete bacula-director-mysql). En mi caso queda así:

# Generic catalog service

Catalog {

Name = Catalogo

dbname = “bacula”; dbuser = “bacula”; dbpassword = “************”

}

Clientes (File Services)

En este apartado tendremos que “dar de alta” a todos los clientes de los que realizaremos copia de seguridad:

# Client (File Services) to backup

Client {

Name = vSRVDebianWS1-fd

Address = 192.168.1.103

FDPort = 9102

Catalog = Catalogo

Password = “*******************” # password for FileDaemon

File Retention = 30 days # 30 days

Job Retention = 6 months # six months

AutoPrune = yes # Prune expired Jobs/Files

}

Client {

Name = vSRVApliWeb-fd

Address = 192.168.1.47

FDPort = 9102

Catalog = Catalogo

Password = “************” # password for FileDaemon

File Retention = 30 days # 30 days

Job Retention = 6 months # six months

AutoPrune = yes # Prune expired Jobs/Files

}

Client {

Name = vSRVDebian-fd

Address = 192.168.1.115

FDPort = 9102

Catalog = Catalogo

Password = “**************” # password for FileDaemon

File Retention = 30 days # 30 days

Job Retention = 6 months # six months

AutoPrune = yes # Prune expired Jobs/Files

}

JobDefs

En un Jobdef podemos tener las mismas directivas que un job (Tarea). Al crear un jobdef, no estamos creando una tarea, sino que estamos configurando una serie de directivas “por defecto” que podremos usar para configurar uno o varios jobs, ahorrándonos muchas líneas de configuración. Por ejemplo: Tenemos varios servidores Linux de los que deseamos hacer copias de seguridad completas. En vez de crear varios jobs con todas sus directivas en cada uno, creamos varios jobs a los que le decimos que se “alimenten” de las directivas del jobdef. Si repetimos una directiva en el job, que ya esté referenciada en el jobdef, Bacula usará la opción que hayamos puesto en el job.

JobDefs {

Name = “JD-vSRVDebianWS1”

Type = Backup

Level = Incremental

Client = vSRVDebianWS1-fd

FileSet = “LinuxCompleto”

Schedule = “CicloSemanal”

Storage = FS-vSRVDebianWS1

Messages = Standard

Pool = Pool-vSRVDebianWS1

Priority = 10

}

JobDefs {

Name = “JD-vSRVApliWeb”

Type = Backup

Level = Incremental

Client = vSRVApliWeb-fd

FileSet = “Alfresco”

Schedule = “CicloSemanal”

Storage = FS-vSRVApliWeb

Messages = Standard

Pool = Pool-vSRVApliWeb

Priority = 10

}

JobDefs {

Name = “JD-vSRVDebian”

Type = Backup

Level = Incremental

Client = vSRVDebian-fd

FileSet = “LinuxCompleto”

Schedule = “CicloSemanal”

Storage = FS-vSRVDebian

Messages = Standard

Pool = Pool-vSRVDebian

Priority = 10

}

Jobs

Los jobs son las “tareas” que deberá realizar Bacula. Pueden ser de backup, restauración, etc. Como dije antes, las tengo referenciadas a jobdefs.

# Define the main nightly save backup job

# By default, this job will back up to disk in /nonexistant/path/to/file/archive/dir

Job {

Name = “Backup-vSRVDebianWS1”

JobDefs = “JD-vSRVDebianWS1”

Write Bootstrap = “/mnt/bacula/vSRVDebianWS1/vSRVDebianWS1.bsr”

}

Job {

Name = “Backup-vSRVApliWeb”

JobDefs = “JD-vSRVApliWeb”

Write Bootstrap = “/mnt/bacula/vSRVApliWeb/vSRVApliWeb.bsr”

}

Job {

Name = “Backup-vSRVDebian”

JobDefs = “JD-vSRVDebian”

Write Bootstrap = “/mnt/bacula/vSRVDebian/vSRVDebian.bsr”

}

# Backup the catalog database (after the nightly save)

Job {

Name = “Backup-Catalog”

JobDefs = “JD-Catalogo”

# This creates an ASCII copy of the catalog

# WARNING!!! Passing the password via the command line is insecure.

# see comments in make_catalog_backup for details.

# Arguments to make_catalog_backup are:

# make_catalog_backup

RunBeforeJob = “/etc/bacula/scripts/make_catalog_backup bacula bacula ********* 127.0.0.1”

# This deletes the copy of the catalog

RunAfterJob = “/etc/bacula/scripts/delete_catalog_backup”

Write Bootstrap = “/var/lib/bacula/BackupCatalog.bsr”

Priority = 11 # run after main backup

}

#

# Standard Restore template, to be changed by Console program

# Only one such job is needed for all Jobs/Clients/Storage …

#

Job {

Name = “Restaurar-vSRVDebianWS1”

Type = Restore

Client=vSRVDebianWS1-fd

FileSet=”LinuxCompleto”

Storage = FS-vSRVDebianWS1

Pool = Pool-vSRVDebianWS1

Messages = Standard

Where = /mnt/bacula/restaurar/vSRVDebianWS1

}

Job {

Name = “Restaurar-vSRVApliWeb”

Type = Restore

Client=vSRVApliWeb-fd

FileSet=”Alfresco”

Storage = FS-vSRVApliWeb

Pool = Pool-vSRVApliWeb

Messages = Standard

Where = /mnt/bacula/restaurar/vSRVApliWeb

}

Job {

Name = “Restaurar-vSRVDebian”

Type = Restore

Client=vSRVDebian-fd

FileSet=”LinuxCompleto”

Storage = FS-vSRVDebian

Pool = Pool-vSRVDebian

Messages = Standard

Where = /mnt/bacula/restaurar/vSRVDebian

}

Job {

Name = “Restaurar-Catalogo”

Type = Restore

Client=vSRVDebian-fd

FileSet=”Catalogo”

Storage = FS-Catalogo

Pool = Pool-Catalogo

Messages = Standard

Where = /mnt/bacula/restaurar/catalogo

}

Schedules

Los “schedules” son las programaciones horarias con las que se realizaran los trabajos. Yo he optado por dejar la que trae Bacula, ya que me parece buena para los servidores de los que tengo que realizar copias de seguridad. Por defecto, hace copias completas el primer domingo de cada mes, diferenciales el resto de domingos del mes e incrementales todos los demás días.

Schedule {

Name = “CicloSemanal”

Run = Full 1st sun at 02:00

Run = Differential 2nd-5th sun at 02:00

Run = Incremental mon-sat at 02:00

}

# This schedule does the catalog. It starts after the WeeklyCycle

Schedule {

Name = “CicloSemanalDespuesBackup”

Run = Full sun-sat at 23:10

}

Filesets

Los filesets son las listas de archivos de los que queremos hacer copias de seguridad. Aquí incluyo listas de ejemplo de servidores Linux y de servidores Windows.

# List of files to be backed up

FileSet {

Name = “LinuxCompleto”

Include {

Options {

signature = MD5

}

File = /

}

Exclude {

File = /proc

File = /tmp

File = /.journal

File = /.fsck

}

}

FileSet {

Name = “Alfresco”

Enable VSS = yes

Include {

Options {

signature = MD5

}

File = “C:/Alfresco”

}

}

FileSet {

Name = “Catalogo”

Include {

Options {

signature = MD5

}

}

File = /var/lib/bacula/bacula.sql

}

}

Storages

Aqui damos de alta los dispositivos que pusimos en el archivo bacula-sd.conf.

# Definition of file storage device

Storage {

Name = FS-vSRVDebianWS1

Address = 192.168.1.115 # N.B. Use a fully qualified name here

SDPort = 9103

Password = “***************”

Device = FS-vSRVDebianWS1

Media Type = File

}

Storage {

Name = FS-vSRVApliWeb

Address = 192.168.1.115 # N.B. Use a fully qualified name here

SDPort = 9103

Password = “***************”

Device = FS-vSRVApliWeb

Media Type = File

}

Storage {

Name = FS-vSRVDebian

Address = 192.168.1.115 # N.B. Use a fully qualified name here

SDPort = 9103

Password = “***************”

Device = FS-vSRVDebian

Media Type = File

}

Storage {

Name = FS-Catalogo

Address = 192.168.1.115 # N.B. Use a fully qualified name here

SDPort = 9103

Password = “***************”

Device = FS-Catalogo

Media Type = File

}

Pools

Un Pool es un “almacén” de volúmenes. Un volumen es un dispositivo donde Bacula almacenará las copias de seguridad (Una cinta, un archivo, un DVD, etc.). Los volúmenes no los creamos aquí, lo haremos posteriormente desde la consola de Bacula.

# Default pool definition

Pool {

Name = Pool-vSRVDebianWS1

Pool Type = Backup

Recycle = yes # Bacula can automatically recycle Volumes

AutoPrune = yes # Prune expired volumes

Volume Retention = 365 days # one year

}

Pool {

Name = Pool-vSRVApliWeb

Pool Type = Backup

Recycle = yes # Bacula can automatically recycle Volumes

AutoPrune = yes # Prune expired volumes

Volume Retention = 365 days # one year

}

Pool {

Name = Pool-vSRVDebian

Pool Type = Backup

Recycle = yes # Bacula can automatically recycle Volumes

AutoPrune = yes # Prune expired volumes

Volume Retention = 365 days # one year

}

Pool {

Name = Pool-Catalogo

Pool Type = Backup

Recycle = yes # Bacula can automatically recycle Volumes

AutoPrune = yes # Prune expired volumes

Volume Retention = 365 days # one year

}

Emails

Esta es la última directiva que tendremos que configurar. Es la que nos permitirá enviar los emails a través de Bacula. Para ello, Bacula usa bsmtp. Con solo añadir nuestros servidor de correo electrónico e introducir las direcciones a las que queremos que lleguen los emails, estará todo listo.

# Reasonable message delivery — send most everything to email address

# and to the console

Messages {

Name = Standard

#

# NOTE! If you send to two email or more email addresses, you will need

# to replace the %r in the from field (-f part) with a single valid

# email address in both the mailcommand and the operatorcommand.

# What this does is, it sets the email address that emails would display

# in the FROM field, which is by default the same email as they’re being

# sent to. However, if you send email to more than one address, then

# you’ll have to set the FROM address manually, to a single address.

# for example, a ‘no-reply@mydomain.com’, is better since that tends to

# tell (most) people that its coming from an automated source.

#

mailcommand = “/usr/lib/bacula/bsmtp -h mail.tu-dominio.com -f \”\(Bacula\) \\” -s \”Bacula: %t %e of %c %l\” %r”

operatorcommand = “/usr/lib/bacula/bsmtp -h mail.tu-dominio.com -f \”\(Bacula\) \\” -s \”Bacula: Intervention needed for %j\” %r”

mail = alertas@tu-dominio.com = all, !skipped

operator = alertas@tu-dominio.com = mount

console = all, !skipped, !saved

#

# WARNING! the following will create a file that you must cycle from

# time to time as it will grow indefinitely. However, it will

# also keep all your messages if they scroll off the console.

#

append = “/var/lib/bacula/log” = all, !skipped

}

Una vez hecho esto, solo tendremos que reiniciar los demonios de Bacula e instalar los clientes en los equipos/Servidores que queramos. En los clientes, modificaremos en el archivo bacula-fd.conf y le pondremos los datos del demonio Director de Bacula.

Para probar todo, arrancamos la consola de bacula con el comando “bconsole”, creamos los volúmenes con el comando “label” y escribimos “run” desde dentro de esta consola. Nos saldrá una lista con todos nuestros trabajos y solo tendremos que elegir uno.

Si queremos comprobar el estado de los demonios de bacula, ejecutaremos el comando “status”.

Y, por último, para restaurar algo, o bien usamos las tareas de restauración que hemos creado, o bien ejecutamos el comando “restore”.

De este modo es como lo he configurado. Seguro que hay mejores modos de hacerlo, pero a mí de este me funciona bien. Una última cosa, tened siempre a mano una copia del catálogo de Bacula y los archivos bootstrap intentad ponerlos en un sitio que también tengáis a mano. Harán falta si queremos recuperarnos de un desastre.


Backups con Bacula (I)

Hoy, lo único “especial” que he hecho, además de resolver problemas sin mucha ciencia, ha sido empezar a configurar un sistema decopias de seguridad o backup con Bacula en un Debian. Para quien no sepa de lo que hablo, que lea un pocosobre Bacula…y un poco sobre Debian.

Una vez que lo hayáis leído, habréis visto que Bacula es un sistema de copias de seguridad bastante completo y que seguro cumplirá con la gran mayoría de necesidades que una empresa necesita en sus sistemas de backup.

Hago un inciso muy importante…una empresa que no tiene un buen sistema de copias de seguridad…no tiene datos. Al menos así lo pienso yo.

Continuo por donde iba…normalmente en mi empresa usamos elSymantec Backup Exec para realizar las copias de seguridad. Nos va muy bien, no tenemos quejas, salvo cada vez que hay que pagar licencias por usarlo. En este caso, como voy a hacer copias de seguridad de máquinas virtuales Linux, me sobra con Bacula. ¿No sabes lo que es una máquina virtual? Léete algo sobre lasmaquinas virtuales.

Bueno, la instalación de Bacula en Debian es muy sencilla…todo se limita a un:

  • aptitude install bacula

Pero una vez instalado, empiezan las “complicaciones”. Que si quiero usar MySQL como sistema gestor de base de datos, que si no me conectan los demonios entre sí, que no tengo ni idea de como configurar una copia de seguridad, que si no tiene una interfaz gráfica para su administración (Aunque esto no es totalmente cierto…), pero cuando vas profundizando, te das cuenta que es relativamente sencillo de entender en cuanto a su funcionamiento.

Personalmente, prefiero perder mucho tiempo al principio configurando todo lo que necesito como es debido, que configurar las 4 cosas para salir al paso y después verme con problemas que podrían haber tenido solución si hubiese hecho las cosas como es debido.

En informática nunca vayais a salir del paso. Si teneis un problema, hay que intentar dar la mejor solución siempre. Un “Ahora lo hago así y ya lo cambiaré” no vale. Al final no lo cambias, y cuando te das cuenta, la bola ha crecido demasiado y tienes un verdadero problema encima de la mesa. Así que hay que intentar siempre dejarlo todo lo más cerrado posible (Se que hay muchas veces que el tiempo o la urgencia del problema no lo permite, pero siempre hay que intentarlo…)

Voy a realizar una pequeña descripción Bacula y de sus archivos de configuración. Os aviso de que no soy partidario de escribir “recetas mágicas” que todo el mundo pueda copiar y pegar para que funcionen correctamente. Para algunos casos pueden venir bien, pero siempre prefiero entender lo que estoy haciendo, porque si el día de mañana tengo un problema (Seguro que llegan) seré capaz de afrontarlo. Si hago un copy&paste, no me entero de lo que estoy haciendo(Si…de acuerdo, en algunos casos sí xD), y al más mínimo problema…batacazo.

Aun así, intentaré contar como lo he hecho yo (No quiere decir que este bien, porque todo se puede mejorar) paso a paso. Para que cualquiera pueda configurarlo pero sabiendo lo que está haciendo en cada momento.

Bacula no es más (Ni menos) que un conjunto de demonios que interactúan entre sí para realizar las copias de seguridad. Estos demonios pueden residir en el mismo host…o no. A Bacula le es indiferente mientras que le indiquemos correctamente donde está cada uno. Bueno, vamos al lío.

Vamos a definir los demonios de Bacula:

  1. Director (Demonio bacula-director). Es el demonio principal de Bacula. Dice cuando, como y donde se realizan los backup o restore. Este demonio tiene que correr en una máquina con acceso a la base de datos (Catálogo). Su archivo de configuración es:bacula-dir.conf
  2. Storage (Demonio bacula-storage). Es el demonio que se encarga de administrar los dispositivos físicos sobre los que se realizaran los backups. Su archivo de configuración:bacula-fd.conf
  3. File (Demonio bacula-file). Es un agente que debe de estar corriendo en la maquina de cuyos datos queramos realizar un backup. Resumiendo: Empaqueta los datos y se los pasa al demonio bacula-storage para que los “guarde” en los dispositivos físicos. Su archivo de configuración:bacula-sd.conf

Independientemente de estos demonios, hay otras dos cosas que debemos de saber que existen. Una de ellas es el Catálogo y la otra es la consola de bacula.

El Catálogo es la base de datos donde Bacula va a almacenar que copias de seguridad se han hecho, cuando, donde están los archivos, etc. Es muy importante realizar copias de seguridad del Catálogo cada vez que se realice un backup de cualquier máquina. Esto viene configurado por defecto en Bacula, ya lo veremos más adelante.

La consola es la interfaz de administración de Bacula. Desde aquí crearemos los Volumenes (Paciencia, ya veremos que son), ejecutaremos trabajos, los cancelaremos, veremos el estado del servidor, cliente, etc. En resumen, desde aquí gestionaremos Bacula. Es una consola bastante intuitiva y fácil de utilizar. No os asustéis los que solo estáis acostumbrados a funcionar a golpe de ratón. La consola tiene su propio archivo de configuración:bconsole.conf

En Debian, los archivos de configuración se encuentran en el directorio /etc/bacula. Una costumbre que tengo antes de tocar nada, es realizar una copia de seguridad de los archivos de configuración. Así, si metemos la pata (Casi seguro que lo haremos) podemos volver al estado inicial. Por ejemplo, para realizar una copia de seguridad de la configuración del bacula-director, ejecutaremos el siguiente comando:

  • cp /etc/bacula/bacula-dir.conf /etc/bacula/bacula-dir.conf.original

Cuando hagamos esto, ya estaremos tranquilos para poder trabajar con libertad y sin miedo a meter la mata (Aunque esto tampoco es malo…más bien es recomendable, porque así es como se aprende mejor)

En cuanto tenga tiempo, intentaré describir las partes que componen cada archivo de configuración, para que no tengamos problemas en realizar los cambios necesarios a los archivos para adaptarlos a nuestras necesidades.

PD: Que no se me olvide cambiar el motor de BD que usa por defecto Bacula por MySQL.