martes, 28 de abril de 2015

Innstalacion de MYSQL en ubuntu14.04

En esta publicacion hablaremos de algo relacionado a base de datos, especificamente la instalación de MySQL.

Para ello utilizaremos como sistema operativo Ubuntu.

Paso 1: Algo muy importante es actualizar el repositorio del sistema operativo
#sudo apt-get update

Paso 2: Instalaremos los paquetes mysql-sever, mysql-common y mysql-client
#sudo apt-get install mysql-sever mysql-common mysql-client

Paso 3: Comprobar la instalación
#ps -ef|grep mysql

Debe mostrar algo parecido a esto
mysql 1690 1 3 17:49 ? 00:00:00 /usr/sbin/mysqld

También se puede utilizar el siguiente comando
#sudo netstat -tap | grep mysql

Debe mostrar algo parecido a esto
tcp 0 0 localhost:mysql *:* ESCUCHAR 1690/mysqld

Paso 4: Conectarse a MySQL.
#mysql -u root -p

Introducir el password que se especifico en la instalación de MySQL, nos mostrará el siguiente mensaje
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. 
mysql>

Paso 5: Crear o restaurar una base de datos

Si no cuenta con backup de una base de datos, puedes crearla con el siguiente comando
mysql> create database dbtest;

Si deseas restaurar una base de datos, ejecuta el siguiente comando, donde ‘bk’ es el directorio donde se encuentran los backups, en tu caso especificar la ruta donde tienes tu backup
mysql> exit
#mysql -u root -p < /bk/dbtest-Atila-20120908-1642.sql 
#mysql -u root -p

Paso 6: Dar permiso para acceder a nuestra base de datos desde otros host
 
mysql> GRANT ALL PRIVILEGES ON dbtest.* TO usuario@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION; 
mysql> flush privileges;

Si se deseas dar permiso a una equipo con un IP especifico(ejm: 192.168.5.113), para que pueda acceder a la base de datos, hacer lo siguiente
mysql> GRANT ALL PRIVILEGES ON dbtest.* TO usuario@'192.168.5.113' IDENTIFIED BY 'password' WITH GRANT OPTION; 
mysql> flush privileges;

Si se desea dar acceso a toda la red local(no es lo recomendable), hacer lo siguiente
mysql> GRANT ALL PRIVILEGES ON dbtest.* TO usuario@'%' IDENTIFIED BY 'password' WITH GRANT OPTION; 
mysql> flush privileges;

Para verificar los usuarios y permisos creados:
mysql> select Host,User,Password from mysql.user;  
 
+---------------+------------------+-------------------------------------------+
| Host | User | Password | 
+---------------+------------------+-------------------------------------------+ 
| localhost | root | *571E3BE003B3C46169D7487C6ADB903D96B92409 | 
| ubuntu | root | *571E3BE003B3C46169D7487C6ADB903D96B92409 | 
| 127.0.0.1 | root | *571E3BE003B3C46169D7487C6ADB903D96B92409 | 
| localhost | debian-sys-maint | *3C6354DF9A1AF534EB9B879FFABCE8CB7CDFA419 | 
| 192.168.5.113 | usuario | *2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19 | 
| localhost | usuario | *2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19 | 
| % | usuario | *2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19 | 
+---------------+------------------+-------------------------------------------+ 
7 rows in set (0.00 sec) mysql>exit

Paso 7:
Si deseas revisar el log, puedes hace lo siguiente
#vi /var/log/mysql/error.log

Si deses optimizar la configuración de MySQL, debes editar el siguiente archivo
#vi /etc/mysql/my.cnf

En un posterior post, colocare algunos tips para optimizar el servicio de MySQL.

Paso 8: Para detener, iniciar o reiniciar el servicio.
#sudo service mysql stop 
mysql stop/waiting
#sudo service mysql start 
mysql start/running, process 2120
#sudo service mysql restart 
mysql start/running, process 2200
Bueno, espero que esta publicacion les sirva para una correcta instalacion de MYSQL.

Instalacion y configuracion del sistema de backups AMANDA

En esta publicacion vamos a instalar y configurar basicamente el sistema AMANDA

1. Introducción

El motivo por el que se ha elegido Amanda para este cometido es principalmente su versatilidad, ya que permite cubrir la necesidad de salvaguardar información importante almacenada tanto en el propio servidor como en los clientes (tanto Linux como Windows) en todos los soportes posibles: dispositivos multicinta, unidades grabadoras de CD, discos ópticos, e incluso discos duros. Además esta tarea puede ser realizada cómodamente de modo automático mediante la introducción de Amanda en el cron.
Este documento está enfocado hacia la realización de las copias de seguridad utilizando el disco duro como soporte, por lo tanto se omite todo lo referente a la utilización de otro tipo de dispositivos, como pueden ser cintas o cd´s (puede encontrarse información en las referencias de la sección "Más Información" de este mismo documento).
Veremos el proceso de instalación y configuración para nuestro sistema particular, pero tratando siempre de darle un enfoque lo más genérico posible. Se explicarán las secciones más importantes de los ficheros de configuración del servidor y clientes y se estudiarán mediante ejemplificaciones los reportes proporcionados por Amanda.

2. Conceptos Básicos

2.1. ¿Qué es Amanda?

Amanda es el "Archivador de Disco de Red Automatizado Avanzado de Maryland" ("Advanced Maryland Automated Network Disk Archiver").

2.2. ¿De quién es?

Amanda fue escrito originalmente por James da Silva del Departamento de Ciencias de la Computación de la Universidad de Maryland sobre 1992. El objetivo era crear un sistema capaz de hacer copias de seguridad de múltiples clientes en una única máquina servidora de copias de seguridad. Es una utilidad de dominio público. Es tan avanzado como lo puede ser una utilidad gratuita de copias de seguridad, y cuenta con un gran número de usuarios.

2.3. ¿Para qué sirve?

Se usa para hacer copias de seguridad (backups). Amanda te permite establecer un único servidor de copias de seguridad (tu server Linux) para salvaguardar datos de múltiples máquinas en un mismo dispositivo de copia (también trabaja con un buen número de stackers o apiladores de cintas). Amanda puede usar diferentes programas para realizar las copias, tales como programas de copia comerciales o el simple GNUtar, y puede hacer copias de un gran número de estaciones clientes corriendo múltiples versiones de Unix. Las versiones más recientes de Amanda también pueden usar Samba para hacer copias de máquinas Windows (95/98/NT/2000) en el servidor.
Es decir, Amanda permite salvaguardar de forma automatizada la información importante de tu red, ya esté ubicada en el servidor central, o en los clientes Windows/Unix.

2.4. Y si tengo problemas ¿A quién acudo?

En caso de problemas son muy recomendables las listas de correo de Amanda. En concreto, suscríbete a <amanda-user@amanda.org>. Date de alta en la lista desde la página web de Amanda.

2.5. Un ejemplo práctico

Imagina la siguiente situación: eres el administrador de una red de 30 puestos, todos ellos clientes Windows de un servidor Linux. Los clientes Windows almacenan sus documentos importantes en la carpeta "Mis Documentos", y no quieren la responsabilidad de tener que hacer copias de seguridad de su información (dicen que bastante tienen ya con trabajar). Esa red de 30 puestos está servida por una máquina Linux que, entre otras muchas cosas, les da salida a Internet, correo interno/externo, acceso a ficheros de la empresa ubicados en el servidor Linux desde las máquinas windows (a través de Samba), etc. Esa máquina Linux dispone de una unidad de cinta (streamer), con suficiente espacio para almacenar tanto los contenidos del servidor como los de las carpetas "Mis Documentos" de los clientes. Pues bien, con Amanda puedes programar la copia de toda esa información. Además, la puedes automatizar, añadiendo una simple orden en el crontab del servidor.

3. Obtención de Amanda e Instalación de Paquetes Relacionados

Existen dos posibilidades distintas a la hora de instalar Amanda. La primera consiste en la instalación y configuración de forma "manual" de Amanda y todos los paquetes relacionados necesarios para su funcionamiento. Esta opción, si bien requiere un poco más de tiempo y esfuerzo, nos permite un mayor control sobre la configuración en el momento de la instalación (mediante el paso de parámetros a la hora de configurar y compilar).
La segunda opción consiste en la utilización del comando apt-get (como veremos a continuación) que realiza la configuración e instalación de forma automática.
En nuestro caso hemos decidido probar ambas instalaciones a fin de comprobar su correcto funcionamiento. Hemos de decir que ambas han funcionado de manera correcta, si bien te recomiendo el uso de la instalación automática, sobre todo a los usuarios más noveles en Linux, ya que configura por sí solo la mayoría de las cosas (siempre será necesario adaptar la configuración a nuestro caso particular).

3.1. Instalación Manual

3.1.1. Obtención de la Última Distribución de Amanda

Algunas de las distribuciones existentes actualmente incorporan Amanda "de serie". A pesar de ello no está de más dirigirnos a la página web de Amanda a fin de comprobar si existe una versión más actual que la que tenemos. Conviene aclarar algunos conceptos antes de elegir la distribución que nos bajaremos.
Amanda viene como distribución de fuentes. Algunos distribuidores de sistemas operativos proporcionan versiones precompiladas de Amanda, pero debido a que Amanda incluye algunos valores en determinados programas, puede que no concuerden con la configuración. Se está trabajando en mover estos valores a ficheros de configuración de tiempo de ejecución, pero por ahora Amanda debería ser generado desde código fuente.
La típica distribución de Amanda es un gzip comprimido con un nombre de fichero tal como amanda-2.4.2.tar.gz, lo cual significa que la versión es la 2.4.2. Existen ocasionales parches de las versiones que tienen un nombre como amanda-2.4.2p1.tar.gz (versión 2.4.2 más parche versión 2). Las versiones Beta tienen nombres como amanda-2.5.0b3.tar.gz (tercera beta pre-versión de la versión 2.5.0).
Es áltamente recomendable utilizar una versión estable de la distribución y cuyo parche sea el más actual. Así pues esta será nuestra elección: amanda-2.4.2p2.tar.gz.

3.1.2. Instalación de Paquetes Relacionados

Esto hay que tenerlo muy en cuenta. Amanda no es independiente de otro software. Otros paquetes pueden ser requeridos para completar nuestra instalación. Antes de continuar, deberías localizar/instalar los paquetes necesarios. En concreto, son los siguientes:
  • GNU tar 1.12 o superior (http://www.gnu.org)
    La versión GNU del programa "tar" con capacidades para realizar copias parciales y omitir los ficheros seleccionados. Este es uno de los programas clientes de realización de copias que Amanda sabe utilizar.
  • Samba 1.9.18p10 o superior (http://www.samba.org, y la "Traducción del Manual de Samba", en S.O.B.L.)
    Samba es una implementación del protocolo "System Message Block" (SMB) usado por los sistemas basados en Windows para el accesoa ficheros. Contiene una herramienta, "smbclient", que Amanda puede usar para realizar copias a través de Samba.
  • Perl 5.004 o superior (http://www.perl.org)
    Perl es un lenguaje de programación tipo script, orientado a la administración de sistema y la manipulación de textos. Es usado por una serie de herramientas de informes de Amanda y por algunos intercambiadores de cintas.
  • GNU readline 2.2.1 o superior (http://www.gnu.org)
    La librería "GNU readline" puede ser incorporada para su uso por programas interactivos, para proporcionar históricos de línea de comando y para edición. Se crea en la herramienta de restauración de Amanda "amrecover", si está disponible.
  • GNU awk 3.0.3 o superior (http://www.gnu.org)
    La versión GNU del lenguaje de programación "awk" contiene una versión común a plataformas y algunas características adicionales. Es usada por la herramienta opcional de estadísticas de Amanda "amplot".
  • gnuplot 3.5 o superior (ftp://ftp.dartmouth.edu/pub/gnuplot/)
    Esta librería "gnuplot" (que no tiene nada que ver con las herramientas GNU, mira el fichero README de la distribución) es un paquete gráfico de ploteado. Se usa por la herramienta de uso opcional de estadísticas de Amanda "amplot".
Asegúrate de buscar en el directorio de parches de Amanda y de mirar en la sección de parches de la página web, para posibles necesidades de actualizaciones de estos paquetes. Las versiones de Samba anteriores a la 2.0.3, en particular, deben ser parcheadas para que funcionen correctamente con Amanda. Sin estos parches, las copias de seguridad parecerán que se están realizando correctamente, pero las imágenes resultantes estarán corruptas.
Cuando Amanda es configurado, las localizaciones de software adicional usado en los clientes, tales como GNU tar y Samba, se incorporan a los programas de Amanda, de forma que el soft adicional debe ser instalado en el mismo sitio donde se encuentra instalado Amanda y en todos los clientes.

3.2. Instalación y Configuración Automáticas con "apt-get"

Como se comentó anteriormente, el comando apt-get permite la instalación de Amanda de forma automática, al igual que resuelve, instala y configura las dependencias que pueda tener ésta con otros paquetes. Para ello tecleamos la siguente orden:
# apt-get install amanda-server amanda-client amanda-common
Como se puede ver, estamos indicando que sean instalados los paquetes correspondientes al servidor, cliente y los comunes. Así pues, en el caso de un cliente sólo sería necesario instalar el paquete amanda-client.

4. Compilación e Instalación de Amanda

Este apartado sólo será necesario en caso de haber elegido la instalación manual. Si hemos realizado la instalación mediante el comando apt-get, todo lo que aquí se explica habrá sido ya configurado de forma automática (mediante la configuración por defecto).
Antes de nada debemos descomprimir el paquete (en un directorio cualquiera, por ejemplo /usr/local/src).

4.1. Configuración Preliminar

La típica configuración de Amanda se ejecuta como un usuario distinto a root, como por ejemplo "backup" o "amanda", con los permisos necesarios para relizar copias de seguridad (en adelante, backups). Frecuentemente, la posibilidad de hacer un login para el usuario que se cree está desactivada (recomendado). Por lo tanto si probáis a hacer un login con ese nombre de usuario, comprobaréis que no puede entrar al sistema.
Para usar el programa comercial "dump" en lugar del GNU tar, el usuario que controla Amanda debe estar en un grupo con permisos de lectura contra los dispositivos de copia. El número de miembros en este grupo debería estar muy controlado, ya que tienen permiso para abrir cada uno de los ficheros de los clientes.
Hay dos formas para enlazar Amanda y el grupo de miembros del dispositivo de copia. Poniendo al usuario Amanda en el grupo al que actualmente pertenecen los dispositivos de copia, como el grupo primario o el secundario, o creando un nuevo grupo para Amanda y pasando a este nuevo grupo a los propietarios de los dispositivos. Amanda (actualmente, el programa "dump") necesita acceso de sólo lectura, de modo que desactiva los permisos de escritura del grupo. Desactiva también los permisos del "resto del mundo". Nosotros asociaremos el usuario "amanda" al grupo "disk".
Para usar GNU tar, Amanda funciona bajo un programa setuid-root que garantiza los permisos necesarios. La versión GNU de "tar" debe ser la usada con Amanda. Las versiones comerciales (a menos que tengan origen en la GNU y sean al menos versión 1.12) no funcionarán, porque Amanda depende de características adicionales.

4.2. Configuración de la Generación de Amanda

Ahora viene la parte del ./configure. Este es el típico script con el que nos encontramos en todo paquete de fuentes, que sirve para preparar las órdenes que posteriormente vamos a pasarle al compilador.
Usa el usuario y grupo Amanda para las opciones --with-user y --with-group en ./configure. Por ejemplo, para usar "amanda" como nombre de usuario y "disk" como nombre de grupo:
# ./configure --with-user=amanda --with-group=disk
No se necesitan obligatoriamente más opciones para ./configure, pero si quieres puedes ver todas las posibilidades con ./configure --help. No te vuelvas loco cambiando opciones. Los valores por defecto son normalmente adecuados, y se requiere de cierta experiencia con Amanda para hacer cambios en dichos valores. Deja --with-debugging para que los ficheros de depuración de errores sean creados en los clientes. Consumirán algo de espacio, pero son "casi" necesarios y sobre todo muy útiles a la hora de resolver posibles problemas.
La generación normal crea tanto el servidor de cintas como el software cliente. La parte servidora del sistema necesita las partes de cliente.Sin embargo, los clientes normalmente no necesitan la parte servidora de Amanda. Te puedes ahorrar y tiempo de compilación añadiendo --without-server a los argumentos de ./configure cuando compiles para ellos.
En nuestro supuesto práctico (un servidor Linux y clientes W98), sólo necesitas instalar Amanda en el servidor. Los clientes no necesitan ninguna instalación de software adicional.
El mecanismo de seguridad por defecto usa un fichero con el mismo formato que .rhosts, pero llamado .amandahosts. Esto mantiene a las operaciones de Amanda separadas del trabajo normal rsh/rcp que usa el mismo usuario. No es recomendable, pero .rhosts y hosts.equiv pueden ser usados, añadiendo --without-amandahosts a los argumentos de ./conFigure. Mejor usa .amandahosts.
Amanda usa sus propios protocolos TCP y UDP. Normalmente, los que ves a continuación (extraído del /etc/services):
amanda 10080/tcp # Amanda backup services
amanda 10080/udp # Amanda backup services
amandaidx 10082/tcp # Amanda backup services
amidxtape 10083/tcp # Amanda backup services
Los puertos TCP usados para la transferencia de datos pueden restringirse con --with-portrange para usar Amanda entre hosts separados por un cortafuegos (firewall). Una entrada típica podría ser:
# ./configure --with-portrange=50000,50100 …
Esto no afecta a las peticiones UDP iniciales hechas desde el servidor de cintas a los clientes. El puerto UDP de amanda (normalmente 10080) debe tener paso permitido a través del firewall. Que no se te olvide esto, si usas un cortafuegos.
Si vas a usar muchas opciones con ./configure, puedes ponerlas todas juntas en /usr/local/share/config.site o en /usr/local/etc/config.site para mantenerlas entre una compilación y otra. Tienes un ejemplo de esto en example/config.site.

4.3. Compilación e Instalación

Una vez hemos ejecutado ./configure, teclea make para compilar Amanda, y luego teclea make install para instalarlo. El paso "make install" debes hacerlo necesariamente como root porque algunos programas de Amanda requieren privilegios de sistema.
A menos que la hayas cambiado la ubicación por defecto, Amanda se instala en estas áreas:
  • /usr/local/sbin: Programas que ejecutan los administradores.
  • /usr/local/lib: Librerías.
  • /usr/local/libexec: Programas privados que sólo usa Amanda.
  • /usr/local/man: Documentación.
Ahora es un buen momento para leer la página principal de amanda. Proporciona una rápida explicación de Amanda, una descripción de cada programa e información detallada sobre la configuración.
Los siguientes programas deben tener setuid-root (lo cual lo hace si tecleas make install como root). El primer grupo (amcheck, dumper, y planner) corren en la máquina servidora de cintas, y necesitan un puerto privilegiado de red para una comunicación segura con los clientes. El resto de programas son utilidades usadas en los clientes, en función del programa de copia usado y el tipo de s.o.
  • sbin/amcheck: Programa de chequeo de Amanda.
  • libexec/dumper: Programa cliente de comunicaciones.
  • libexec/planner: Programa de estimación de procentaje de volumen copiado.
  • libexec/killpgrp: Usado para matar (kill) proramas de copia que corren como root.
  • libexec/rundump: Setuid wrapper para sistemas que necesitan correr el programa de copiado como root.
  • libexec/runtar: Setuid wrapper para ejecutar GNU tar como root.
Todos estos programas son instalados con los permisos de acceso de grupo y del "resto del mundo" desactivados para el grupo de Amanda, denominado según --with-group. Asegúrate de que todos los miembros el grupo son los que deben ser, ya que rundump y runtar en particular dan acceso a cada uno de los ficheros en el sistema.
Si el software Amanda está accesible via NFS, asegúrate de que las opciones mount admiten programas setuid. Además, si se usa GNU tar, el root necesita acceso de escritura a /usr/local/var/amanda/gnutar-lists (o el valor que hayas usado con --with-gnutar-list para el ./configure) para almacenar información sobre cada nivel parcial.
Si la generación te da problemas o Amanda necesita volver a ser generado, sobre todo si tienes nuevas opciones para ./configure, la siguiente secuencia te garantiza que todo es perfectamente instalado, elminando cualquier rastro de la instalación anterior:
# make distclean 
# ./configure … 
# make 
# make install (como root)
Se pueden diagnosticar posibles problemas en los procesos de ./configure, mirando en el fichero config.log. Contiene una salida detallada de los tests que realiza ./configure. Advierte que es normal que algunos de dichos tests "fallen" , como consecuencia de las pruebas que ./configure realiza para determinar cómo acceder a varias características del sistema.
Un problema común cuando usa el compilador GNU C es no reinstalarlo cuando cambia la versión de S.O. GCC es particularmente sensible a los ficheros de cabecera del sistema y debe ser reinstalado o tener incluidos las modificaciones adecuadas en sus ficheros include (mira las notas sobre instalación de tu versión de gcc) si el S.O. es actualizado. Ejecutando gcc --verbose verás de dónde obtiene gcc su información, y contiene una indicación de la versión de s.o. que espera encontrar.
Amanda necesita realizar cambios en los servicios de red y en el fichero de configuración relativos a inetd. El script client-src/patch-system debería actualizar tu sistema en la mayoría de los casos. Este no maneja actualmente sistemas que entreguen servicios via YP/NIS. Si el script no te funciona, añade las siguientes entradas al fichero services (p.e., /etc/services) or YP/NIS map:
Amanda 10080/udp 

Amandaidx 10082/tcp 

Amidxtape 10083/tcp
Suele venir todo preconfigurado. Tan sólo tienes que descomentar las líneas en el inetd.conf. Pero de todas formas, repasa el /etc/services, que nunca está de más.
Cada cliente Unix/Linux necesita una entrada como estas en su fichero de configuración de inetd (p.e., /etc/inetd.conf), sustituyendo al "usuario_Amanda" por Amanda y la ruta completa al directorio libexec de Amanda para RUTA:
amanda dgram udp wait usuario_Amanda /RUTA/libexec/amandad amandad
El servicio amanda es usado por todos los servicios controlados por Amanda para realizar funciones en los clientes. El servidor de cintas necesita entradas como éstas para poder ejecutar la herramienta amrecover:
amandaidx stream tcp nowait Amanda /PATH/libexec/amindexd amindexd 
amidxtape stream tcp nowait Amanda /PATH/libexec/amidxtaped amidxtaped
En algunas distribuciones ya existen estas líneas, aunque comentadas. Simplemente descoméntalas, y comprueba que la ruta de acceso a amindexd y a amidxtaped concuerdan con las de tu configuración. Si no es así, pues las cambias y listo. No olvides hacer un killall -HUP inetd si has hecho cambios al inetd.conf.
El servicio amandaidx proporciona acceso a los catálogos, mientras que el servicio amidxtape proporciona acceso remoto al dispositivo de cinta.

5. Pasos Previos a la Puesta en Marcha

Si todo ha ido bien, tenemos ya instalado el software servidor y las herramientas necesarias para hacer copias y restaurarlas. En nuestro supuesto práctico, hablamos de usar un disco duro como soporte físico para almacenar la información.

5.1. Selección del Tipo de Dispositivo de Copia

En nuestro caso hemos optado por usar un disco duro como soporte de destino para las copias de seguridad. Los motivos de dicha elección son numerosos, si bien cabe destacar como más importantes los siguientes: permite una mayor velocidad en la realización de las copias, no es necesario estar pendiente de colocar la cinta adecuada, resulta más económico utilizar un dispositivo existente que tener que adquirir uno nuevo, nos evitamos tener una estantería repleta de cintas de copias de seguridad..., etc.
Puesto que Amanda es un servidor de copias de seguridad inicialmente pensado para el almacenamiento de las mismas en cintas será necesario realizar algunas modificaciones en los ficheros de configuración inicial, para poder usar un disco duro como dispositivo de copia.

5.2. Selección del Tipo de Copia

Las imágenes de las copias pueden opcionalmente ser comprimidas en el cliente o el servidor de copias (o mediante el hardware del dispositivo de cinta, si es ese el caso). La compresión via software permite a Amanda rastrear el uso y hacer mejores estimaciones de los tamaños de las imágenes, pero la compresión hardware es más eficiente en cuanto al consumo de recursos de la CPU. Desactiva la compresión de hardware cuando uses compresión software en el cliente o el servidor. Mira la documentación del S.O. para ver cómo se controla la compresión via hardware; en muchos sistemas esto se hace a través del nombre del fichero del dispositivo con el flag no-rebobinable. AIX usa el comando chdev.

6. Configuración de Amanda

En esta parte se realiza la configuración del funcionamiento de Amanda. Básicamente, tenemos que tocar dos ficheros. El que le dice a Amanda cómo debe funcionar, amanda.conf, y el que le indica qué es lo que tiene que copiar, disklist.

6.1. El Fichero de Configuración "amanda.conf"

Escoge un nombre para la configuración (el nombre "Diaria" será usado para el resto de la sección). Crea un directorio en la máquina servidora de cintas para almacenar los ficheros de configuración, normalmente en /usr/local/etc/amanda/Diaria. Accede al nuevo directorio (o quizás mejor al directorio). Su uso debería estar restringido al grupo de Amanda, o mejor, para acceso sólo del usuario Amanda.
Amanda limita el uso de red, de forma que las copias de seguridad no acaparen toda la capacidad del sistema. Este límite es impuesto cuando Amanda está decidiendo si realizar una copia estimando la salida y añadiéndola a las copias que se están ejecutando en ese momento. Si el valor excede del ancho de banda asignado a Amanda, entonces la copia es retenida hasta que las otras hayan terminado. Una vez que se inicia una copia, Amanda permite a otros componentes de la red ejecutar cualquier operación, reduciendo su predominio.
Copia la plantilla de ejemplo del fichero example/amanda.conf al directorio de configuración que hemos creado y edítalo. Tienes completa información sobre su contenido en la página man de Amanda. Hay muchos parámetros, pero en nuestro caso sólo es necesario cambiar unos pocos y añadir alguno. Comienza con los siguientes (algunos de ellos se explicarán más adelante):
  • org: Esta cadena estará en la línea de Asunto (Subject) de los reportes recibidos vía e-mail desde Amanda.
  • mailto: Usuarios destinatarios de los reportes que genera Amanda y envía vía e-mail.
  • dumpuser: Igual que --with-user en ./configure.
  • dumpcycle: Ciclo de Copia.
  • runspercycle: Ejecuciones por ciclo.
  • tapecycle: Número mínimo de cintas necesarias para el ciclo.
  • runtapes: Número de cintas a usar por ejecución.
  • tapedev: El dispositivo de cinta "no-rewind" (no rebobinable) si no se va a usar un cambiador de cintas, o si se va a usar el cambio manual.
  • tapetype: Tipo de cinta.
  • netusage: Ancho de banda de la Red asignado a Amanda.
  • labelstr: Una expresión regular (grep pattern) usada para garantizar que cada cinta está asignada a esa configuración de Amanda. Nuestro ejemplo debería usar "Diaria-[0-9][0-9][0-9]".
Los siguientes parámetros probablemente no necesitarán ser cambiados, pero mira sus valores para que sepas dónde espera Amanda encontrar las cosas:
  • infofile: Localización de la B.D. que contiene el histórico de operaciones de Amanda. Versiones antiguas de Amanda usan esto como el nombre base de un fichero de bases de datos. Las nuevas versiones lo usan como nombre de directorio.
  • logdir: Directorio donde los registros de Amanda son almacenados.
  • indexdir: Localización de la base de datos de catálogos (opcional) de Amanda.
Es necesario realizar las siguientes modificaciones en el presente fichero de configuración, a fin de seleccionar el disco duro como dispositivo de almacenamiento de las copias de seguridad. Esta configuración es genérica para el uso de cualquier tipo de disco duro, así que debería funcionarte:
  1. Ponemos el parámetro tapedevice a "no-such-device",
  2. Ponemos rawtapedev a "no-such-device",
  3. Ponemos changerdev a "no-such-device",
  4. Ponemos tapetype a DISKSAVE,
  5. Definimos un nuevo tipo de cinta, que en este caso representa al disco duro, y que llamaremos DISKSAVE por ejemplo. Para ello añadimos las siguientes líneas en la sección tapetypes del fichero:
      
    define tapetype DISKSAVE  {
    
     comment "Fake tape description for save to disk"
     length 1000 gbytes
     filemark 0 kbytes
     speed 2000 kbytes
    
    }
  6. Comentamos la sección en la que se define el "holdingdisk".
  7. Ponemos reserve a 30 (por ejemplo).
  8. Comentamos el parámetro runtapes.

6.2. El Fichero de Configuración "disklist"

Una vez que el fichero amanda.conf ha sido correctamente configurado, escogemos al primer cliente, normalmente el propio servidor, y los sistemas de archivos o directorios a copiar. Por cada área a salvaguardar, selecciona el programa de copia que vayas a usar (dump comercial o GNU tar). Los programas de copia comerciales suelen ser más eficientes y no perturban a los archivos que están copiando, pero normalmente no son portables entre diferentes sistemas operatvos. GNU tar es portable y tiene algunas características adicionales, como la habilidad de excluir patrones de ficheros, pero altera el último tiempo de acceso para cada fichero copiado y puede no llegar a ser tan eficiente. GNU tar también puede repartirse con sistemas de archivos activos mejor que los programas de copia comerciales, y es capaz de manejar sistemas de archivos muy grandes, rompiéndolos en subdirectorios.
Hemos de comentar que en nuestro caso nos hemos tenido que decantar por la segunda opción (el GNU tar) ya que algún tipo de incompatibilidad con nuestro sistema (cuya razón no es el objetivo de este documento) imposibilitaba a Amanda para usar correctamente el dump. Serán en cada caso las circunstancias concretas las que determinen que programa usaremos o podremos usar.
A continuación seleccionaremos el tipo de compresión para cada área, si la hay. Considera desactivar la compresión de las áreas críticas, necesarias para recuperar el sistema de una máquina, en el caso de que el programa de descompresión no esté disponible. La compresión de cliente extiende la carga a múltiples máquinas y reduce el tráfico de la red, pero puede no resultar apropiada para el caso de clientes lentos o bien ocupados con mucha carga de procesos. La compresión de Servidor incrementa la carga del servidor de cintas. En su lugar, si usas GNU gzip , la compresión puede hacerse de forma más rápida y menos agresiva. Establece la compresión a ninguna para desactivar compresión via software o usar compresión via hardware.
Escoge o modifica un tipo de copia o dumptype ya existente que coincida con las opciones que deseas, o crea uno nuevo. Cada dumptype debería referenciar al dumptype global. Este es usado para establecer opciones para el resto de dumptypes. Por ejemplo, para usar la característica de indexación o indexing, actívala en el dumptype global, y los demás tipos que definas heredarán ese valor. Para nuestra instalación, y por los motivos antes comentados hemos seleccionado siempre aquellos dumptypes que hacen uso del programa GNU tar.
La capacidad de indexación genera un catálogo comprimido de cada imagen de copia (dump image). Esto es útil para encontrar archivos perdidos, y es la base del programa amrecover. Ciclos de copia muy grandes o áreas con muchos o muy activos archivos pueden provocar que los catálogos usen mucho espacio en disco. Amanda automáticamente elimina los catálogos de las imágenes que ya no están en el disco (u otro dispositivo de almacenamiento usado).
Crea un fichero llamado disklist en el mismo directorio donde reside tu amanda.conf o bien copia el que tienes en example/disklist. Asegúrate de que es legible por el usuario Amanda. Cada línea en disklist define un área a ser copiada. El primer campo es el nombre de la máquina cliente (se aconsejan nombres completamente cualificados de dominio), el segundo es el área a ser salvaguardada en el cliente, y el tercero es el método de copia, o dumptype. El área puede introducirse como nombre de disco, sd0a, como nombre de dispositivo , /dev/rsd0a, o como nombre lógico, /usr. Los nombres lógicos son más fáciles para recordar qué es lo que se está copiando, así como a la hora de restauración o la reconfiguración del disco.
Para configurar un cliente Windows, estableceremos el nombre de la máquina al nombre de la máquina Unix que corre Samba (el mismo servidor Linux que corre Amanda es nuestro caso) y el área al nombre del recurso compartido de Windows, como por ejemplo //algun-pc/C$. Advierte que las barras que se usan como separadores son las de Unix, y no las de Windows.
Activa el acceso de Amanda al cliente desde el servidor de cintas (a menos que el cliente sea el propio servidor de cintas) editando el fichero .amandahosts (o .rhosts, dependiendo de cómo lo configuraste en ./configure) en el directorio raíz del usuario Amanda en el cliente. Introduce el nombre completamente cualificado de dominio del servidor de copias de seguridad y el usuario Amanda (o el correspondiente en cada caso), separados por un espacio o tabulador. Asegúrate de que el fichero es propiedad del usuario Amanda y no permite acceso a nadie más que al propietario (p.e. modo 0600 o 0400).
Para los clientes Windows, coloca la contraseña del recurso en /etc/amandapass en el servidor que corre Samba. El primer campo es el nombre de recurso compartido de Windows, el segundo es la contraseña en modo texto, y el tercer campo (opcional) es el dominio. Debido a que este fichero contiene contraseñas visibles, debería estar muy protegido, ser propiedad del usuario Amanda y sólo accesible a él. Por defecto, Amanda usa al usuario Samba. Esto lo puedes cambiar con --with-samba-user en ./configure.

7. Ejemplos de Ficheros de Configuración

A continuación listamos el resultado de nuestros ficheros de configuración: "amanda.conf" y "disklist".

7.1. "amanda.conf"

#
# amanda.conf - sample Amanda configuration file.
#
# If your configuration is called, say, "DailySet1", then this file
# normally goes in /etc/amanda/DailySet1/amanda.conf.
#
# for explanation of the parameters refer to amanda(8) and
# /usr/doc/amanda/WHATS.NEW.gz

org "Diaria"         # your organization name for reports
mailto "amanda"           # space separated list of operators at your site
dumpuser "amanda"       # the user to run dumps under
#
inparallel 4            # maximum dumpers that will run in parallel
netusage  600           # maximum net bandwidth for Amanda, in KB per sec

# a filesystem is due for a full backup once every  days
dumpcycle 4 weeks       # the number of days in the normal dump cycle
tapecycle 8 tapes       # the number of tapes in rotation

bumpsize 1 MB           # minimum savings (threshold) to bump level 1 -> 2
bumpdays     1          # minimum days at each level
bumpmult     4          # threshold = bumpsize * (level-1)**bumpmult

#runtapes     9         # explained in WHATS.NEW
#tpchanger "no-changer" # the tape-changer glue script, see TAPE.CHANGERS
tapedev "no-such-device"        # Linux @ tuck, important: norewinding
rawtapedev "no-such-device"     # the raw device to be used (ftape only)
#changerfile "/mnt/amanda/changer"
changerdev "no-such-device"

tapetype DISKSAVE       # what kind of tape it is (see tapetypes below)
labelstr "^HISS[0-9][0-9]*$"    # label constraint regex: all tapes must match

diskdir "/mnt/backup"          # where the holding disk is
disksize 10 MB                  # how much space can we use on it
reserve 30
#diskdir "/dumps/amanda/work"   # additionaly holding disks can be specified
#diskdir "/mnt/disk4"
#disksize 1000 MB               #       they are used round-robin


# Amanda needs a few MB of diskspace for the log and debug files,
# as well as a database.  This stuff can grow large, so the conf directory
# isn't usually appropriate.

infofile "/var/lib/amanda/DailySet1/curinfo"    # database filename
logfile  "/var/log/amanda/DailySet1/log"        # log filename

# where the index files live
indexdir "/var/lib/amanda/DailySet1/index"

# Specify holding disks.  These are used as a temporary staging area for
# dumps before they are written to tape and are recommended for most sites.
# The advantages include: tape drive is more likely to operate in streaming
# mode (which reduces tape and drive wear, reduces total dump time); multiple
# dumps can be done in parallel (which can dramatically reduce total dump time.
# The main disadvantage is that dumps on the holding disk need to be flushed
# (with amflush) to tape after an operating system crash or a tape failure.
# If no holding disks are specified then all dumps will be written directly
# to tape.  If a dump is too big to fit on the holding disk than it will be
# written directly to tape.  If more than one holding disk is specified then
# they will all be used round-robin.

#holdingdisk hd1 {
#    comment "main holding disk"
#    directory "/mnt/amanda1"     # where the holding disk is
#    use 30 Mb           # how much space can we use on it
#                        # a non-positive value means:
#                        #        use all space but that value
#    chunksize 1Mb       # size of chunk if you want big dump to be
#                        # dumped on multiple files on holding disks
#                        #  N Kb/Mb/Gb split images in chunks of size N
#                        #             The maximum value should be
#                        #             (MAX_FILE_SIZE - 1Mb)
#                        #  0          same as INT_MAX bytes
#}

# tapetypes
#
# Define the type of tape you use here, and use it in "tapetype" above.
# Some typical types of tapes are included here.  The tapetype tells amanda
# how many MB will fit on the tape, how big the filemarks are, and how
# fast the tape device is.
#
# For completeness Amanda should calculate the inter-record gaps too, but it
# doesn't.  For EXABYTE and DAT tapes this is ok.  Anyone using 9 tracks for
# amanda and need IRG calculations?  Drop me a note if so.

define tapetype DISKSAVE  {
   comment "Fake tape description for save to disk"
   length 1000 gbytes
   filemark 0 kbytes
   speed 2000 kbytes
}

define tapetype QIC-60 {
    comment "Archive Viper"
    length 60 mbytes
    filemark 100 kbytes         # don't know a better value
    speed 100 kbytes            # dito
}

define tapetype DEC-DLT2000 {
    comment "DEC Differential Digital Linear Tape 2000"
    length 15000 mbytes
    filemark 8 kbytes
    speed 1250 kbytes
}

# goluboff@butch.Colorado.EDU
# in amanda-users (Thu Dec 26 01:55:38 MEZ 1996)
define tapetype DLT {
    comment "DLT tape drives"
    length 20000 mbytes         # 20 Gig tapes
    filemark 2000 kbytes        # I don't know what this means
    speed 1500 kbytes
}

define tapetype SURESTORE-1200E {
    comment "HP AutoLoader"
    length 3900 mbytes
    filemark 100 kbytes
    speed 500 kbytes
}

define tapetype EXB-8500 {
    comment "Exabyte EXB-8500 drive on decent machine"
    length 4200 mbytes
    filemark 48 kbytes
    speed 474 kbytes
}

define tapetype EXB-8200 {
    comment "Exabyte EXB-8200 drive on decent machine"
    length 2200 mbytes
    filemark 2130 kbytes
    speed 240 kbytes
}

define tapetype HP-DAT {
    comment "DAT tape drives"
    length 1900 mbytes          # these numbers are not accurate
    filemark 100 kbytes         # but you get the idea
    speed 500 kbytes
}

define tapetype DAT {
    comment "DAT tape drives"
    length 1000 mbytes          # these numbers are not accurate
    filemark 100 kbytes         # but you get the idea
    speed 100 kbytes
}

define tapetype MIMSY-MEGATAPE {
    comment "Megatape (Exabyte based) drive through Emulex on Vax 8600"
    length 2200 mbytes
    filemark 2130 kbytes
    speed 170 kbytes            # limited by the Emulex bus interface, ugh
}

define tapetype QIC-3080 {
    comment "QIC 3080"
    length 2000 mbytes
    filemark 64 kbytes
    speed 250 kbytes
}

# dumptypes
#
# These are referred to by the disklist file.  The dumptype specifies
# certain "options" for dumping including:
#       index           - keep an index of the files backed up
#       compress-fast   - (default) compress on the client using fast algorithm
#       compress-best   - compress using the best (and slowww) algorithm
#       no-compress     - don't compress the dump output
#       srvcompress     - Compress dumps on the tape host instead of client
#                         machines.  This may be useful when a fast tape host
#                         is backing up slow clients.
#       record          - (default) record the dump in /etc/dumpdates
#       no-record       - don't record the dump, for testing
#       no-hold         - don't go to the holding disk, good for dumping
#                         the holding disk partition itself.
#       skip-full       - Skip the disk when a level 0 is due, to allow
#                         full backups outside Amanda, eg when the machine
#                         is in single-user mode.
#       skip-incr       - Skip the disk when the level 0 is NOT due.  This
#                         is used in archive configurations, where only full
#                         dumps are done and the tapes saved.
#       no-full         - Do a level 1 every night.  This can be used, for
#                         example, for small root filesystems that only change
#                         slightly relative to a site-wide prototype.  Amanda
#                         then backs up just the changes.
#
# Also, the dumptype specifies the priority level, where "low", "medium" and
# "high" are the allowed levels.  These are only really used when Amanda has
# no tape to write to because of some error.  In that "degraded mode", as
# many incrementals as will fit on the holding disk are done, higher priority
# first, to insure the important disks are dumped first.

define dumptype always-full {
    comment "Full dump of this filesystem always"
    options no-compress
    priority high
    dumpcycle 0
    maxcycle 0
}

define dumptype comp-user-tar {
    program "GNUTAR"
    comment "partitions dumped with tar"
    options compress-fast, index, exclude-list "/etc/amanda/exclude.gtar"
    priority medium
}

define dumptype comp-root-tar {
    program "GNUTAR"
    comment "Root partitions with compression"
    options compress-fast, index, exclude-list "/etc/amanda/exclude.gtar"
    priority low
}

define dumptype user-tar {
    program "GNUTAR"
    comment "partitions dumped with tar"
    options no-compress, index, exclude-list "/etc/amanda/exclude.gtar"
    priority medium
}

define dumptype high-tar {
    program "GNUTAR"
    comment "partitions dumped with tar"
    options no-compress, index, exclude-list "/etc/amanda/exclude.gtar"
    priority high
}

define dumptype root-tar {
    program "GNUTAR"
    comment "Root partitions dumped with tar"
    options no-compress, index, exclude-list "/etc/amanda/exclude.gtar"
    priority low
}

define dumptype comp-user {
    comment "Non-root partitions on reasonably fast machines"
    options compress-fast
    priority medium
}

define dumptype nocomp-user {
    comment "Non-root partitions on slow machines"
    options no-compress
    priority medium
}

define dumptype holding-disk {
    comment "The master-host holding disk itself"
    options no-hold
    priority medium
}

define dumptype comp-root {
    comment "Root partitions with compression"
    options compress-fast
    priority low
}

define dumptype nocomp-root {
    comment "Root partitions without compression"
    options no-compress
    priority low
}

define dumptype comp-high {
    comment "very important partitions on fast machines"
    options compress-best
    priority high
}

define dumptype nocomp-high {
    comment "very important partitions on slow machines"
    options no-compress
    priority high
}

define dumptype nocomp-test {
    comment "test dump without compression, no /etc/dumpdates recording"
    options no-compress, no-record
    priority medium
}

define dumptype comp-test {
    comment "test dump with compression, no /etc/dumpdates recording"
    options compress-fast, no-record
    priority medium
}

7.2. "disklist"

# sample Amanda2 disklist file, derived from CS.UMD.EDU's disklist
#
# If your configuration is called, say, "DailySet1", then this file
# normally goes in /etc/amanda/DailySet1/disklist.
#
# File format is:
#
#       hostname diskdev dumptype
#
# where the dumptypes are defined by you in amanda.conf.

# Configuración en Litio

localhost /mnt/copia comp-root-tar

8. Ejecutando Amanda

Ya tenemos todo listo para que el sistema funcione. Vamos a ver qué hay que hacer para que Amanda entre en ejecución y nos resuelva el problema de la realización de las copias de seguridad en nuestro sistema.

8.1. Comprobación del Funcionamiento: "amcheck"

Una de las cosas buenas que tiene Amanda es que puedes saber si va a funcionar o no, antes de ejecutarlo. Puedes testear tu configuración con el comando amcheck. Ejecuta este comando como usuario amanda, y no como root:
Si en éste momento estás como root, usa:
# su amanda -c "amcheck Diaria"
Si estás como usuario amanda, usa:
# amcheck Diaria
Muchos de los errores reportados por amcheck están descritos en docs/FAQ, o en la página man de amcheck. El error más común reportado es "selfcheck request timed out", lo que significa que amcheck no ha podido hablar con el demonio amandad (mira el /etc/inetd.conf)en el cliente. Es importante recordar en este punto que las listas de correo funcionan de forma muy eficiente, ya que la gente responde en el mismo día.
Para un testeo inicial, establece la opción record a no en el dumptype global, pero acuérdate de ponerlo a yes cuando Amanda vaya a realizar su funcionamiento normal. Este parámetro controla si el programa de copia en el cliente actualiza su propia base de datos, tal como /etc/dumpdates.
Para empezar completamente desde cero, elimina los archivos o directorios nominados en los directorios info e index, el fichero tapelist, y todos los ficheros amdump.* en el directorio de configuración, así como todos los ficheros del tipo log.*. Estos ficheros contienen información histórica que Amanda necesita entre sus ejecuciones y también son necesarios para encontrar imágenes de copias para su restauración. Deberían estar protegidos cuando Amanda entre en funcionamiento en tu sistema. Las rutas y nombres posibles de todos estos ficheros vienen definidas en el fichero de configuración amanda.conf.

8.2. Ejecución de la Copia: "amdump"

El script amdump controla una ejecución normal de Amanda. Simplemente hay que tener en cuenta estos puntos:
Su ejecución es tan simple como esto: amdump, y a continuación el nombre del tipo de configuración. En nuestro caso, sería: amdump Diaria. Se ejecuta como usuario amanda, no como root. Lo puedes ejecutar manualmente, desde consola, o meterlo como tarea del cron del usuario amanda, para que las copias se hagan automáticamente.
Si cuando se va a ejecutar amdump, este detecta otra copia en ejecución, o una copia anterior abortada, amdump genera un error y se detiene. Usa amcleanup para limpiar el sistema de ejecuciones abortadas, y luego podrás ejecutar de nuevo amdump.
Cuando Amanda termina una ejecución, manda un reporte en forma de correo electrónico al destinatario o destinatarios establecidos en el fichero amanda.conf (recuerda el parámetro "mailto", en las primeras líneas del fichero de configuración). También renombra el fichero de registro de la ejecución a un nombre de fichero único, con el formato log.YYYYMMDD.N nombre.
Es recomendable, al menos durante los primeros días de funcionamiento del sistema, léerse los reportes que llegan al correo.

8.3. Recuperación de Datos: "amrecover" y "amrestore"

Es el momento de hablar sobre cómo podemos restaurar la información desde una copia de seguridad a su origen. En pocas palabras, de eso se encargan los comandos amrecover y amrestore, que tendremos que ejecutar como root. A continuación se explica el uso de ambos, así como las particularidades, ventajas y desventajas de cada uno de ellos.

8.3.1. Configuración y uso de "amrecover"

amrecover es el comando que vamos a usar para restaurar archivos con Amanda. Antes de que amrecover pueda funcionar, Amanda debe ejecutarse con el parámetro dumptype index establecido a yes, y los servicios amindexd y amidxtaped deben estar instalados y activados en el archivo /etc/inetd.conf del servidor de cintas (esto lo hace por defecto la instalación). Además, el cliente debe figurar en el fichero .amandahosts (o .rhosts) del servidor de cintas. Es imprescindible ejecutar el comando amrecover como root. amrecover no debería hacerse setuid-root, ya que podría entonces abrir catálogos del sistema entero para todo el mundo.
Veremos a continuación un ejemplo prático que ilustra la situación. El usuario X ha pedido que se le restauren dos archivos, ambos con el mismo nombre "molecule.dat", en los subdirectorios llamados work/sample-21 y work/sample-22 y dice que quiere las versiones que se modificaron por última vez el 13 de enero. Nos hacemos root en el cliente donde vamos a restaurar la información (si es un cliente unix/linux. Si no, desde el server), vamos al área y ejecutamos amrecover:
$ su 
Password: 
# cd ~jj 
# amrecover Diaria
AMRECOVER Version 2.4.1p1. Contacting server on amanda.cc.purdue.edu ... 
220 amanda Amanda index server (2.4.1p1) ready. 
200 Access OK 
Setting restore date to today (1999-01-18) 
200 Working date set to 1999-01-18. 
200 Config set to Diaria.
200 Dump host set to pete.cc.purdue.edu. 
$CWD '/home/pete/u66/jj' is on disk '/home/pete/u66' mounted at '/home/pete/u66'. 
200 Disk set to /home/pete/u66. 
amrecover>
En este punto, un interfaz de línea de comandos nos permite navegar por la imagen de los catálogos. Navega mediante el comando cd, mira qué está disponible con ls, cambia las fechas con setdate, añade archivos y directorios a la lista de extracción con add. El comando extract inicia la extracción de lo que hayas seleccionado. Y si tienes dudas, o no te acuerdas de los comandos, siempre está el comando help:
amrecover> setdate ---14 
200 Working date set to 1999-01-14. 
amrecover> cd work/sample-21 
/home/pete/u66/jj/work/sample-21 
amrecover> add molecule.dat 
Added /jj/work/sample-21/molecule.dat 
amrecover> cd ../sample-22 
/home/pete/u66/jj/work/sample-22 
amrecover> add molecule.dat 
Added /jj/work/sample-22/molecule.dat 
amrecover> extract 
Extracting files using tape drive /dev/rmt/0mn on host amanda.cc.purdue.edu. 
The following tapes are needed: Diaria-034 
Restoring files into directory /home/pete/u66 
Continue? [Y/n]: y 
Load tape Diaria-034 now 
Continue? [Y/n]: y 
Warning: ./jj: File exists 
Warning: ./work: File exists 
Warning: ./work/sample-21: File exists 
Warning: ./work/sample-22: File exists 
set owner/mode for '.'? [yn] n 
amrecover> quit
amrecover localiza los directorios y archivos que contienen las imágenes, opcionalmente la descomprime (si has usado compresión), llega al cliente a través de la red y se entuba en el apropiado programa de restauración con los argumentos necesarios para extraer los archivos solicitados. amrecover no sabe cómo ejecuta cada cliente el programa de restauración. Mira la página man de amrecover para información actualizada. amrecover no debería usarse para una restauración total del sistema de archivos con herramientas de resturación comerciales, pero funciona de maravilla con el GNU tar. Las herramientas comerciales deberían ejecutarse con el flag r para una restauración completa, y con el flag x para extraer archivos individuales. Una restauración completa con herramientas comerciales debería realizarse cen el comando amrestore.

8.3.2. Uso de "amrestore"

Respecto a este comando, comentar que su función es recuperar imágenes completas desde el disco o cualquier otro soporte utilizado, aunque está más orientado a dar un soporte para la realización de copias de seguridad en cintas, ya que proporciona facilidades como la búsqueda de cintas mediante indexación de sus contenidos, y otras.
Puede encontrarse más información acerca del uso de dispositivos de cinta y del comando amrestore en las referencias listadas en la sección "Más Información" de este documento.

9. Interpretación de los Reportes

Cada vez que ejecutemos el comando amdump para la realización de una copia de seguridad Amanda generará un reporte que nos será directamente enviado al correo del usuario especificado en el fichero de configuración amanda.conf. Este reporte tiene varias secciones que paso a explicar a continuación mediante un ejemplo. Este ejemplo hace referencia al uso de cintas como soporte para las copias, pero la mayoría de las cosas son aplicables al caso del uso de un disco duro como soporte (caso que nos ocupa).
These dumps were to tape Daily-009, Daily-010 
Tonight's dumps should go onto 2 tapes: Daily-011, Daily-012.
Estas líneas muestran qué cintas fueron usadas durante la ejecución, y cuáles serán usadas en la próxima vez. En nuestro caso siempre harán referencia al disco duro usado como soporte, ya que es este el que almacena dichas copias.
FAILURE AND STRANGE DUMP SUMMARY: 
gurgi.cc.p /var lev 0 FAILED [Request to gurgi.cc.purdue.edu timed out.] 
gurgi.cc.p / lev 0 FAILED [Request to gurgi.cc.purdue.edu timed out.] 
pete.cc.pu /var/mail lev 0 FAILED ["data write: Broken pipe"] 
samba.cc.p //nt-test.cc.purdue.edu/F$ lev 1 STRANGE 
mace.cc.pu /master lev 0 FAILED [dumps too big, but cannot incremental dump new disk]
Los problemas que se encontraron durante la ejecución son sumarizados en ésta sección. En el ejemplo:
gurgi.cc.purdue.edu estaba caído (apagado), así que todas sus copias fallaron.
El problema en /var/mail en la máquina pete.cc.purdue.edu y el problema F$ en nt-test.cc.purdue.edu se detallan abajo.
EL área /master en mace.cc.purdue.edu es nueva para Amanda así que se requiere una copia completa, pero esta no cabía en el espacio que le quedaba libre a la cinta.
STATISTICS: 
      
 Total  Full 
 Daily 

 
 -------------------------------------------------------------------------------- 
Dump Time (hrs:min) 
 5:03 
 3:23 
 0:33 
 (0:14 start, 0:53 idle) 

Output Size (meg) 
 20434.4 
 17960.0 
 2474.4 

Original Size (meg) 
 20434.4 
 17960.0 
 2474.4 
  
Avg Compressed Size (%) 
 -- 
 -- 
 -- 
   
Tape Used (%) 
 137.4 
 120.0 
 17.4 
 (level:#disks ...) 

Filesystems Dumped 
 90 
 21 
 69 
 (1:64 2:2 3:3) 

Avg Dump Rate (k/s) 
 1036.5 
 1304.3 
 416.2 

Avg Tp Write Rate (k/s) 
 1477.6 
 1511.2 
 1271.9
Esto sumariza toda la ejecución. Tomó unas cinco horas, unas 3.5 horas escribiendo copias completas y una hora y media para copias parciales. Se tomó 14 minutos para iniciar la ejecución, y la cinta estuvo una hora esperando a las copias que le venían desde el disco de almacenamiento.
En este ejemplo, la compresión hardware fue usada, de forma que Avg Compressed Size no es aplicable y el tamaño de la salida o Output Size escrita a la cinta coincide con el tamaño original de los clientes. Aproximadamente un 137% de la longitud de la cinta tal como se definió en el tapetype fue usado (recuerda que se grabaron dos cintas), 120% para copias completas y 17% para parciales. Las líneas Rate nos dan la velocidad de la copia desde el cliente al servidor de cintas y la velocidad de escritura en cinta, todo ello en KBytes por segundo. La línea Filesystems Dumped indica que 90 áreas fueron procesadas, 21 copias completas y 69 parciales. De las parciales, 64 fueron de nivel 1, dos de nivel 2 y tres de nivel 3.
FAILED AND STRANGE DUMP DETAILS: 

  /-- pete.cc.pu /var/mail lev 0 FAILED ["data write: Broken pipe"] 
  sendbackup: start [pete.cc.purdue.edu:/var/mail level 0] 
  sendbackup: info BACKUP=/usr/sbin/ufsdump 
  sendbackup: info RECOVER_CMD=/usr/sbin/ufsrestore -f... - 
  sendbackup: info end 
  |   DUMP: Writing 32 Kilobyte records 
  |   DUMP: Date of this level 0 dump: Sat Jan 02 02:03:22 1999 
  |   DUMP: Date of last level 0 dump: the epoch 
  |   DUMP: Dumping /dev/md/rdsk/d5 (pete.cc.purdue.edu:/var/mail) to standard output. 
  |   DUMP: Mapping (Pass I) [regular files] 
  |   DUMP: Mapping (Pass II) [directories] 
  |   DUMP: Estimated 13057170 blocks (6375.57MB) on 0.09 tapes. 
  |   DUMP: Dumping (Pass III) [directories] 
  |   DUMP: Dumping (Pass IV) [regular files] 
  |   DUMP: 13.99% done, finished in 1:02 
  |   DUMP: 27.82% done, finished in 0:52 
  |   DUMP: 41.22% done, finished in 0:42 

  /-- samba.cc.p //nt-test.cc.purdue.edu/F$ lev 1 STRANGE 
  sendbackup: start [samba.cc.purdue.edu://nt-test/F$ level 1] 
  sendbackup: info BACKUP=/usr/local/bin/smbclient 
  sendbackup: info RECOVER_CMD=/usr/local/bin/smbclient -f... - 
  sendbackup: info end 
  - Can't load /usr/local/samba-2.0.2/lib/smb.conf - run testparm to debug it 
  | session request to NT-TEST.CC.PURD failed 
  |                 directory \top\ 
  |                 directory \top\Division\ 
  |        238 (    2.7 kb/s) \top\Division\contract.txt 
  |      19456 (  169.6 kb/s) \top\Division\stuff.doc 
...
Los fallos y resultados inesperados son detallados aquí. La copia de /var/mail no cambía en la primera cinta, así que la copia fue abortada y vuelta a iniciar en la segunda cinta, tal como se describe en la siguiente sección.
La copia de F$ en nt-test.cc.purdue.edu falló debido a un problema con la configuración del fichero de configuración de SAMBA. Se marcó como STRANGE porque la línea con una barra "|" no coincide con ninguna de las expresiones regulares construidas en Amanda. Cuando se hacen copias de clientes Windows a través de SAMBA, es normal obtener errores sobre ficheros ocupados, tales como PAGEFILE.SYS y el registro. Se deberían hacer otros arreglos para que este tipo de archivos se salvaguardasen correctamente, tales como tareas periódicas en el PC que creasen una copia que no estuviese ocupada en el momento de la ejecuión de Amanda.
NOTES: 
  planner: Adding new disk j.cc.purdue.edu:/var. 
  planner: Adding new disk mace.cc.purdue.edu:/master. 
  planner: Last full dump of mace.cc.purdue.edu:/src on tape Daily-012 overwritten in 2 runs. 
  planner: Full dump of loader.cc.purdue.edu:/var promoted from 2 days ahead. 
  planner: Incremental of sage.cc.purdue.edu:/var bumped to level 2. 
  taper: tape Daily-009 kb 19567680 fm 90 writing file: short write 
  taper: retrying pete.cc.purdue.edu:/var/mail.0 on new tape: [writing file: short write] 
  driver: pete.cc.purdue.edu /var/mail 0 [dump to tape failed, will try again] 
  taper: tape Daily-010 kb 6201216 fm 1 [OK]
Notas informativas sobre la ejecución se listan aquí. Los mensajes dicen:
Hay nuevas entradas en el disklist para j.cc.purdue.edu y para mace.cc.purdue.edu.
La cinta Daily-012 va a ser sobreescrita en dos ejecuciones más y contienen la copia completa más reciente de /src desde mace.cc.purdue.edu, así que el ciclo de la cinta no debería ser más largo.
La siguiente copia completa programada de /var en loader.cc.purdue.edu fue movida dos días para mejorar el balance de la carga.
La copia parcial de /var en sage.cc.purdue.edu se pasó del nivel 1 al nivel 2 debido a que el nivel más alto se estimó que podría tener suficiente espacio para la copia.
El resto de notas dicen que la unidad de cinta no podía escribir todos lo datos deseados, probablemente debido a que se llegó al final de la cinta. Llegados a este punto, se habían escrito 19567680 KBytes en 90 archivoe sobre la cinta Daily-009. Otro intento de realizar una copia completa de /var/mail desde pete.cc.purdue.edu se hizo en la siguiente cinta (Daily-010) y tuvo éxito, escribiendo 6201216 KBytes en un fichero.
DUMP SUMMARY:  
    DUMPER STATS TAPER STATS 
     ------------------------------------------------------------------------------------- 
 HOSTNAME  DISK  L  ORIG-KB  OUT-KB  COMP%  MMM:SS  KB/s  MMM:SS  KB/s  
 boiler.cc  /  1  2624  2624  --  0:13  200.1  0:02  1076.0  
 boiler.cc  /home/boiler/a  1  192  192  --  0:07  26.7  0:02  118.5  
 boiler.cc  /usr  1  992  992  --  0:41  24.2  0:02  514.7  
 boiler.cc  /usr/local  1  288  288  --  0:09  31.2  0:04  86.3  
 boiler.cc  /var  1  4256  4256  --  0:21  205.9  0:04  1104.3  
 egbert.cc  /  1  41952  41952  --  1:26  487.3  0:37  1149.4  
 egbert.cc  /opt  1  224  224  --  0:06  37.5  0:02  136.0  
 egbert.cc  -laris/install  1  64  64  --  0:11  5.8  0:02  49.5  
 gurgi.cc.  /  0  FAILED  ------------------------------------------------------------------- 
 gurgi.cc.  /var  0  FAILED  ------------------------------------------------------------------- 
 pete.cc.p  /  1  13408  13408  --  0:41  328.2  0:08  1600.5  
 pete.cc.p  /opt  1  3936  3936  --  1:04  61.2  0:03  1382.6  
 pete.cc.p  /usr  1  1952  1952  --  0:29  67.0  0:03  584.3  
 pete.cc.p  /var  1  300768  300768  --  2:33  1963.8  2:50  1768.8  
 pete.cc.p  /var/mail  0  6201184  6201184  --  73:45  1401.3  73:47  1400.8  
 ... 
 (brought to you by Amanda version 2.4.1p1)
Esta sección (que ha sido abreviada) reporta cada área copiada, mostrando el cliente, el área, nivel de copia, tamaños, tiempo de copia y tiempo de escritura a cinta. Las entradas están en orden alfabético por cliente y luego por área. Esto no es lo mismo que el orden de cinta. El orden de cinta puede ser determinado por la subopción find o info del comando amadmin, amtoc puede generar una tabla de contenidos de cinta tras cada ejecución, o amreport puede generar una lista impresa. Por defecto, los nombres de los clientes con truncados por la derecha, los nombres de área por la izquierda, para mantener el reporte con menos de 80 caracteres.
Dos archivos de registro son creados durante una ejecución de Amanda. Uno es llamado amdump.NN,donde NN es un número secuencial (1 es el más reciente, 2 es el siguiente más reciente, etc), y se encuentra en el mismo directorio que amanda.conf. El fichero contiene información detallada sobre la ejecución y es usado para estadísticas por amplot y amstatus, y también para depuración de errores. El otro fichero es llamado log.YYYYMMDD.N, donde YYYYMMDD es la fecha de la ejecución de Amanda, y N es un número secuencial, en el caso de que más de una ejecución se haya realizado el mismo día (0 para la primera ejecución, 1 para la segunda, etc). Este fichero está en el directorio especificado por el parámtero logdir del fichero amanda.conf. Contiene un sumario de la ejecución y es la base para el reporte que recibes por correo electrónico. De hecho, amreport puede ser ejecutado manualmente para regerar un reporte en base a un fichero de registro antiguo.
Lo viejos archivos amdump.NN son removidos por el script amdump. Los viejos archivos log.YYYYMMDD.N no son automáticamente eliminados, y deberían ser eliminados periódicamente a mano. Mantener un ciclo completo de cinta es una buena idea. Si el ciclo de la cinta es 40 y Amanda se ejecuta una vez al día, el siguiente comando haría el trabajo:
# find log.????????.* -mtime +40 -print | xargs rm 
Si la opción --with-pid-debug-files fue usada en el ./configure, los clientes acumularán ficheros de depuración de errores en /tmp/amanda (o donde tú lo hayas configurado con --with-debug) y deberían ser eliminados periódicamente. Sin esta opción, los ficheros de depuración de los clientes tienen nombres fijos, y son rehusados de una ejecución a otra.

Conociendo la aplicacion BACULA

Esta publicacion trata de explicarnos basicamente que es BACULA y cuales son sus beneficios.

¿Qué es el Bacula?

Consiste en una serie de programas Open Source que te permiten gestionar y realizar las copias de seguridad a través de la red. Es una aplicación fácil de utilizar y ofrece muchas opciones de almacenamiento y recuperación.

  • Bacula es la soluci on de backup distribuda, multiplataforma y OpenSource.
  • Permite recuperar, restaurar y veri car datos en un entorno de red heterogeneo.

Ventajas al usar Bacula
  • Bacula reduce el riesgo de perdida de datos a un bajo costo y cumpliendo con los estandares de la industria.
  • No requiere de un nivel alto de mantenimiento, liberando a su equipo de IT para realizar otras tareas.
  • Bacula es un sistema escalable y mantenible, que lleva estabilidad y seguridad a su organización a un costo más bajo que el de cualquier herramienta paga.

Soluciones Distribuidas

Bacula se compone de varios elementos que interactúan entre si:

  • Director: el mas importante de todos, supervisa los backups, recuperaciones y verificaciones. El director es quien planifica las tareas a realizar. El director se instala a modo de servicio.
  • Consola (Console): la consola es el programa que nos permite lanzar comando sobre el resto de componentes, existen tanto consolas con modo texto o consolas con interfaz gráfico para GNOME y KDE.
  • Cliente (File Daemon): el cliente es un servicio que se instala en cada equipo que queremos hacer una copia de seguridad de sus datos. El cliente es específico para cada Sistema Operativo y se encarga de suministrar los ficheros cuando el director los pide. Existen clientes en Unix, Linux y en Windows.
  • Almacenamiento (Storage): el servicio de almacenamiento es el encargado de realizar el almacenamiento o recuperación de los datos al medio físico (disco duro, cintas, DVD's, etc). En resumen, es el responsable de la lectura y escritura sobre los volúmenes físicos.
  • Monitor: el monitor nos permite saber cual es el estado de los distintos servicios como el director, almacenamiento o el cliente.
Cada uno puede instalarse en máquinas separadas.
Ahora vemos como se integran entre si los componentes de Bacula
En la foto podemos observar como el director de Bacula es el encargado de conectarse con el servidor de almacenamiento y con la base de datos para realizar la copia de seguridad sobre una máquina. Este esquema nos permite tener instalados los módulos de Bacula en distintos servidores, así pues podemos tener instalado por una parte el servidor de almacenamiento en una máquina conectada a una NAS/SAN y el director y la base de datos en otro servidor totalmente distinto.

Solución Multiplataforma
  • Los elementos que componen Bacula pueden instalarse sobre diferentes plataformas (Linux, Windows, BSD).
  • El storage de Bacula soporta una variedad importante de cintas y robots cambiadores.
Solución Open Source
Debido a su licencia OpenSource:
  • No hay que pagar regalías por su utilización.
  • Además, dispone de una comunidad importante de usuarios, por lo que es fácil encontrar documentación y gente capacitada para operarlo.
Razones para hacer backups
  • Error de los usuarios.
  • Falla del hardware.
  • Falla del software.
  • Situación de desastre (Incendio, inundación).
  • Robo.
Funcionamiento de Bacula

  • Sistema distribuido y multiplataforma.
  • Las componentes de Bacula pueden instalarse en máquinas separadas.
  • Tener en cuenta la relación entre Pool, Volumen y el Período de retención.

Instalacion de BACULA

En esta publicacion vamos a realizar una instalacion basica de BACULA

Instalación Sistema de Respaldo Bacula

Esquema de Bacula
Bacula es un software cliente-servidor, éste se divide en 4 módulos que son:
Director (bacula-dir)
Storage Daemon (bacula-sd)
File Daemon (bacula-fd)
Console (bconsole)

Pasos

  1. Actualizar los Ports.
  2. Instalar MySQL Server 4.1.XY.
  3. Instalar Bacula-Server con soporte para MySQL.
  4. Instalar Bacula-Client desde los ports.
  5. Configurar la base de datos MySQL Server.
  6. Configurar Bacula-Server para MySQL.
  7. Cambio de extensiones a archivos de bacula.
  8. Configurar archivo bacula-fd.conf(Cliente de bacula).
  9. Configurar archivo bacula-sd.conf(Storage Daemon).
  10. Configurar archivo bconsole.conf(Console).
  11. Configurar archivo bacula-dir.conf(Director Daemon).
  12. Probando los archivos de Bacula.
  13. Instalando el Cliente de Bacula en Windows NT4/2000/XP/2003.
  14. Ejecutar Bacula-Server por primera vez.
  15. Accesando a Bacula desde bconsole.
  16. Ejecutando el primer Respaldo Full y Diferencial.
  17. Restaurando archivos con Bacula.

PASO 2: Instalación de MySQL

1. instalar el software MySQL server desde el árbol de ports:
root# cd /usr/ports/databases/mysql51-server/ && make install clean
2. Generamos las tablas de permisos para MySQL:
root# /usr/local/bin/mysql_install_db
3. Cambiamos el propietario y grupo del directorio de datos:
root# chown -R mysql:mysql /var/db/mysql/
4. Una vez completados los pasos anteriores vamos a editar el arvhico rc.conf para que nos inicie automáticamente MySQL
root# ee /etc/rc.conf
Y agregamos la siguiente línea:
mysql_enable=”YES”
Cuando estemos listos pulsamos la tecla ESC “escape”, luego sabe y finalmente sabe change.
5. Ahora reiniciamos la maquina con un simple “reboot
6. A continuación establecer la contraseña del administrador de la base de datos (Atención no poner la contraseña que tenemos para el usuario root):
root# /usr/local/bin/mysqladmin -u root password tupassword
7. Reiniciamos y listo.

PASO 3: Instalar Bacula-Server con soporte para MySQL.


root#cd /usr/ports/sysutils/bacula-server

root #make install clean
Seleccionar el soporte para MySQL. También puede utilizarse PostgreSQL.

PASO 4: Instalar Bacula-Client desde los ports.



root #cd /usr/ports/sysutils/bacula-client
root #make install clean
Este paso debe hacerse en todos los equipos CLIENTES de Bacula. 

PASO 5: Configurar la base de datos MySQL Server.



1. Ejecutar mysql_install_db con el usuario mysql que fue creado cuando instalamos mysql, este script lo encontramos en /usr/local/bin
root #/usr/local/bin/mysql_install_db --user=mysql
Con esto hemos creado las bases de datos que usa mysql para funcionar internamente, aun no se está ejecutado el servidor, esto lo hacemos en el siguiente paso.
2. Iniciar la base de datos con el scrip mysqld_safe
root #/usr/local/bin/mysqld_safe &
Aquí nos arroja cierta información o bien no se ejecuta el servidor, pero vamos probando si está corriendo:
root #sockstat -l4
USER     COMMAND    PID   FD   PROTO   LOCAL ADDRESS         FOREIGN ADDRESS 
mysql    mysqld     530   10   tcp4        *:3306            *:*
Aquí podemos ver si está corriendo el servidor mysql, si no aparece por ahí el puerto 3306 abierto, nos indica que no se ejecuto, a veces una reinicio del sistema arregla todo. Agregar mysql al archivo /etc/rc.conf, con la siguiente línea:
mysql_enable="YES"
Este es el básico para llevar a cabo esto, pero también tenemos estos que son opcionales:
mysql_limits (bool):  YES o NO
mysql_dbdir="/var/db/mysql"
mysql_args (str):
Por último tenemos unos scripts en el directorio de mysql /usr/local/share/mysql que podemos copiar en /etc/ para que mysql lea antes de ejecutarse, estos archivos son parámetros globales para mysql y estos son:
  • my-huge.cnf
  • my-large.cnf
  • my-medium.cnf
  • my-small.cfg
Cada uno tiene sus características, pero solo podemos darle uno a mysql, en mí caso usé my-large.cfg, así que mando una copia a /etc:
root #cp /usr/local/share/mysql/my-large.cnf  /etc/
Cada uno de ellos trae comentarios sobre cuando aplica.
Reiniciar el sistema y verificar que mysql debe estar ejecutándose. 


PASO 6: Configurar Bacula-Server para MySQL.



a) Ejecutar el script de nombre grant_mysql_privileges. Ejecutar el script con el nombre de usuario y contraseña que se le dio a MySQL, esto se hace así:
root#cd /usr/local/share/bacula
root#./grant_mysql_privileges -u root -p
Enter password:
... información
... información
... información
La última línea nos indica que todo salió bien y dice así:
"Privileges for bacula granted."
b) Enseguida debemos ejecutar el script de nombre create_mysql_databases, así:
root#./create_mysql_databases -u root -p
Enter password:
Creation of bacula databases succeeded.
Con esto se ha creado la base de datos de bacula en MySQL.
c) Crear las tablas de bacula, para ello debemos ejecutar el script de nombre create_mysql_tables asi:
root#./make_mysql_tables -u root -p
Enter password:
Creation of Bacula MySQL tables succeeded.
Con todo lo anterior el servidor de bacula está listo para empezar a trabajar con él. Esto se puede comprobar accesando a la consola de mysql y ver las bases de datos que esta posee.
root#mysql -u root -p
Enter password:
...Informacion que arroja mysql
mysql>show databases;
+------------------------------+
|Databases                                    |
+------------------------------+
|information_schema                      |
|bacula                                          |
|mysql                                           |
|test                                              |
+------------------------------+
d) Salir de mysql.


PASO 7: Cambiar extensiones a archivos de configuracion de bacula



Los archivos de configuración están en el directorio /usr/local/etc, todos terminan con la extensión .new o .sample, para que bacula los pueda leer deben terminar en .conf, así que los copiamos en el mismo directorio pero eliminando la extensión .new o .sample.
root#cd /usr/local/etc
root#cp bacula-dir.conf.sample bacula-dir.conf
Esto lo hacemos con los demás archivos los cuales en total son 4:
  • bacula-sd
  • bacula-fd
  • bconsole

paso 8: CONFIGURACIÓN archivo bacula-fd.conf (Cliente de Bacula).


Nota: la configuración de cada uno de los archivos, es la ocupada en el DECOM. Se debe reemplazar todos los “tool”, por el usuario que se quiera, asi como las contraseñas. Ojo con las contraseñas en el cliente, storage y bconsole, ya que debe n ser las mismas que están en el Director.
El archivo a editar es el bacula-fd.conf, esto se hace con el siguiente comando:
root#ee bacula-fd.conf
Configuración:
 Director {
  Name = tool-dir                 #Name=Nombre del director que puede accesar a este cliente.
  Password = "cristian3"     #Password = Password que debe utilizar el director si desea accesar a este cliente.
 }
 Director {
  Name = tool-mon              #Name = Nombre del monitor a donde vamos a mandar nuestros mensajes de lo que estamos haciendo.
  Password = "console"      #Password que debemos utilizar si deseamos comunicarnos con el monitor.
  Monitor = yes
}
 FileDaemon {                                                                       
  Name = tool-fd                  #Name=Nombre del cliente
  FDport = 9102                  #Los demas datos dejarlos igual.    
  WorkingDirectory = /var/db/bacula
  Pid Directory = /var/run
  Maximum Concurrent Jobs = 20
}
 #Aquí solo le indicamos que los mensajes generados se los mande a el director aquí indicado.
#director= Nombre del director al que deseamos informar de nuestros mensajes.
 Messages {
  Name = Standard
  director = tool-dir = all, !skipped, !restored
}


paso 9: Configuracion archivo bacula-sd.conf (Storage bacula).



El archivo a editar es el bacula-sd.conf, esto se hace con el siguiente comando:
root#ee bacula-sd.conf
Configuración:
Storage {                                                              # definition of myself
  Name = tool-sd                                                  #Name= Nombre de demonio
  SDPort = 9103                                                  # Director's port
  WorkingDirectory = "/var/db/bacula"
  Pid Directory = "/var/run"
  Maximum Concurrent Jobs = 20
}
# List Directors who are permitted to contact Storage daemon
Director {
  Name = tool-dir                 #Name=Nombre del director que desea contactar a este demonio.
  Password = "bacula-sd"   #Password=Password que debe usar este director para contactar a este demonio.
}
Director {
  Name = tool-mon
  Password = "console"
  Monitor = yes
}
 #DISPOSITIVO PARA RESPALDAR EN ARCHIVO
Device {
  Name = FileStorage
  Media Type = File
  Archive Device = /tmp                    #Archive Device=Lugar del disco donde vamos a almacenar los respaldos.
  LabelMedia = yes;                             # lets Bacula label unlabeled media
  Random Access = yes;
  AutomaticMount = yes;                    # when device opened, read it
  RemovableMedia = no;
  AlwaysOpen = no;
}
 # DISPOSITIVO PARA RESPALDAR EN DVD
#Device {
#  Name = "DVD-Writer"
#  Media Type = DVD
#  Archive Device = /dev/hdc
#  LabelMedia = yes;                   # lets Bacula label unlabeled media
#  Random Access = Yes;
#  AutomaticMount = yes;               # when device opened, read it
#  RemovableMedia = yes;
#  AlwaysOpen = no;
#  MaximumPartSize = 800M;
#  RequiresMount = yes;
#  MountPoint = /mnt/cdrom;
#  MountCommand = "/bin/mount -t iso9660 -o ro %a %m";
#  UnmountCommand = "/bin/umount %m";
#  SpoolDirectory = /tmp/backup;
#  WritePartCommand = "/etc/bacula/dvd-handler %a write %e %v"
#  FreeSpaceCommand = "/etc/bacula/dvd-handler %a free"
#}
# Send all messages to the Director,
# mount messages also are sent to the email address
Messages {
  Name = Standard
  director = tool-dir = all
}