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.
Amanda es el "Archivador de Disco de Red Automatizado Avanzado de
Maryland" ("Advanced Maryland Automated Network Disk Archiver").
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.
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.
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.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:
-
Ponemos el parámetro tapedevice a "no-such-device",
-
Ponemos rawtapedev a "no-such-device",
-
Ponemos changerdev a "no-such-device",
-
Ponemos tapetype a DISKSAVE,
-
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
}
|
-
Comentamos la sección en la que se define el "holdingdisk".
-
Ponemos reserve a 30 (por ejemplo).
-
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".
#
# 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
}
|
# 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
|
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:
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.
Entre las nuevas certificaciones, tanto técnicas como de preventa, y
los requerimientos de renovaciones por parte de los fabricantes son
sinónimo de tiempo (prácticamente garantizado) a invertir fuera del
horario laboral.
