En este post se indican los pasos a seguir para instalar y configurar amanda con samba y poder proteger nuestros datos con la realización de copias de seguridad
Ø Copia total
v Este tipo de copias de seguridad se denominan así por que realizan un backup completo al sistema y toda su configuración y sus datos, este tipo de copias de seguridad son las más comunes y solo recomendadas en casos en los que el sistema al que se quiere realizar el backup es de un tamaño no muy grande ya que ocupan una cantidad de espacio en disco importante.
v Normalmente se suele hacer una copia de seguridad completa del sistema de manera periódica, ya que la realización de este tipo de copias resulta larga y tediosa en lo que a tiempo se refiere, puesto que se realiza la copia de la totalidad de ficheros del sistema, la parte buena de este tipo de copias es que se puede recuperar un sistema por completo en un tiempo mínimo, también es posible combinar los backups completos con los diferenciales e incrementales.
Ø Copia incremental
v Las copias incrementales se efectúan conjuntas a una copia de seguridad total del sistema, el método de copia incremental es muy sencillo de entender, cuando se programa una copia incremental del sistema solo se realiza una copia de los archivos modificados respecto a la última copia incremental realizada.
Ø Copia diferencial
v Estas copias de seguridad funcionan de manera similar a las copias incrementales, con la diferencia de que las copias incrementales realizan la copia de aquellos datos que hayan cambiado desde la última copia incremental y las copias diferenciales hacen un backup de los datos que hayan sido modificados desde la última copia completa.
Amanda
Este apartado muestra cómo instalar y configurar el servidor de copias de seguridad Amanda mediante el uso de Samba.
El comando apt-get permite la instalación de Amanda de forma automática, Para ello tecleamos las siguientes órdenes:
apt-get install amanda-server
apt-get install amanda-client
apt-get install amanda-common
En el caso de un cliente sólo sería necesario instalar el paquete amanda-client.
Si todo ha ido bien, tenemos ya instalado el software servidor y las herramientas necesarias para hacer copias y restaurarlas.
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.
Selección del Tipo de Copia
Las imágenes de las copias pueden opcionalmente ser comprimidas en el cliente o el servidor de copias. La compresión vía 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.
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.
El Fichero de Configuración "amanda.conf"
Escoge un nombre para la configuració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 (Diaria será el nombre dado para la configuración). Accede al nuevo directorio. Su uso debería estar restringido al grupo de 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.
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 BD. 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. Para ello añadimos las siguientes líneas en la sección tapetypes del fichero:
Define tapetype DISKSAVE{
Comment “Fake tape description for sabe to disk”
lenght 1000 gbytes
filemark 0 kbytes
speed 2000 kbytes
}
Comentamos la sección en la que se define el "holdingdisk".
Ponemos reserve a 30.
Comentamos el parámetro runtapes.
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 operativos. 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.
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 Linux que corre Samba 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 es “ / ”, y no “ \ ”.
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.
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 realice las copias de seguridad en nuestro sistema.
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.
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.
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.
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, 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.
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.
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 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.
No hay comentarios:
Publicar un comentario