Logotipo del grupo GSO

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.