Nadie quiere al administrador de backup
Pero lo cierto es que nadie puede vivir sin él…
Esta es una máxima bastante extendida en el proceloso mundo de la administración de máquinas. Las copia de seguridad son una lata, pero en caso de desastre nos salvan la vida. Literalmente.
Existen cantidad de métodos para realizar una buena política de salvados. Hoy vamos a dedicarle un pequeño espacio de tiempo a una de las más comunes. Ufsdump y Ufsrestores en combinación con nuestras aliadas. Las unidades de cinta.
Es importante conocer qué es lo que queremos salvar. mi experiencia me dice que no es necesario realizar un backup completo de una máquina, sino determinadas piezas de información contenida en ella. Por ejemplo, /var /opt /export/home /oracle, etc…
Conviene determinar claramente cuales son los ficheros y configuraciones impresccindibles y guardarlo a buen recaudo. Un apache se puede instalar desde cero en caso necesario, pero la configuración de cada servidor y el contenido de las páginas son temas más peliagudos.
Por otra parte, no tendremos que copiarlo todo todos los días. Hay archivos y directorios que no sufren variaciones en su contenido, mientras que otros van teniendo información nueva cada día, como una tabla de una base de datos.
Normalmente, hay dos tipos de backup:
- Completo: A realizar el primer día en que hacemos backup
- Incremental: A realizar en los días subsiguientes, y que incluirá únicamente los archivos que hayan sido modificados.
Por último, un pequeño procedimiento para copiado de filesystem completos a cinta. Solo para sus ojos…
Se copian los archivos a la cinta mediante ufsdump completo. En este caso, se realizaría un ufsdump por cada filesystem independiente.
# ufsdump 0uf /dev/rmt/numero_de_cinta /filesyetem
Ejemplos:
# ufsdump 0uf /dev/rmt/0 / # ufsdump 0uf /dev/rmt/0 /var # ufsdump 0uf /dev/rmt/0 /export/home
… etc
Si el salvado que deseamos hacer es incremental, hay que prestar atencion al dump level, que es un valor desde 0 a 9, y establece los ficheros que se van a a copiar que hayan sido modificados desde el último backup realizado a un nivel de dump inferior. Por ejemplo: Si el lunes hemos realizado un dump a nivel 2, y el martes hacemos un dump a nivel 4, en caso de que hagamos un dump a nivel 3 el miércoles copiaría asimismo todos los ficheros modificados o añadidos al sistema desde el backup del lunes.
Hay diferentes combinaciones, pero la que encuentro más adecuada es el llamado modelo de Torres de Hanoi y que viene a ser:
L: Nivel 3 M: Nivel 2 X: Nivel 5 J: Nivel 4 V: Nivel 7 S: Nivel 6 D: Nivel 0
En caso de que se quiera restaurar en un punto fijo, el comando sería:
Desde un directorio creado para contener los FS copiados (Ej: /var/tmp/restauracion)
# ufsrestore rvf /dev/rmt/numero_de_cinta ./filesyetem
Ejemplos:
# ufsrestore rvf /dev/rmt/0 ./ # ufsrestore rvf /dev/rmt/0 ./var # ufsrestore rvf /dev/rmt/0 ./export/home
Recuerden que estas cintas han de guardarse como oro en paño. En caso de que se destruyan o deterioren, es mucho trabajo tirado a la basura 
Si quieren mayor información, lo cual es muy inteligente ya que estas breve pinceladas apenas explican nada, les recomiendo el muy chulo (y divertido) manual Backup & Recovery de W. Preston publicado por O’Reilly.
Esto es grande… Esto es pequeño
La comprobación de que el tamaño de las cosas es elástico (ejem, ejem) y más todavía en Unix.
Como me imagino que todos sabréis, el archivo de /var/adm/lastlog registra y almacena el tiempo de login de cada usuario, sea este correcto o incorrecto. Es útil para saber quien se ha conectado, cuanto tiempo, y desde donde.
En ocasiones, me han dado un toque de atención por el excesivo tamaño de /var y concretamente el de lastlog. Yo siempre les digo que para qué andan mirando donde no deben 
y luego les explico lo que me contaron a mí en su momento: El tamaño del archivo de lastlog al hacer un ls no se corresponde con su tamaño real.
El tamaño indicado al hacer un ls -l del fichero lastlog está basado en el UID más alto de los usuarios que estén conectados a la máquina. La fórmula que utiliza Solaris para esto es tamaño total de lastlog=(UID más alto de los usuarios + 1) * 28
De ésta manera, el fichero de lastlog se convierte en un fichero “disperso” en el que su tamaño real es mucho más pequeño del que pueda parecer. Para comprobarlo, vamos a seguir unos ejemplos sencillos:
Tamaño de /var actual de la máquina nuestra de pruebas:
root@madhatter # df -k /var/ Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/var 2031101 1472886 497282 75% /var
Tamaño de lastlog según ls (Aparente)
root@madhatter # ls -la /var/adm/lastlog -r--r--r-- 1 root root 1820084 Dec 10 14:17 /var/adm/lastlog root@madhatter # ls -lha /var/adm/lastlog -r--r--r-- 1 root root 1.7M Dec 10 14:17 /var/adm/lastlog
Tamaño real del mismo fichero
root@madhatter # du -ks /var/adm/lastlog 24 /var/adm/lastlog
Procedemos a vaciar el fichero lastlog y comprobamos su tamaño
root@madhatter # > lastlog
root@madhatter # ls -la lastlog
-r--r--r-- 1 root root 0 Dec 10 14:30 lastlog
root@madhatter # du -ks lastlog
0 lastlog
Así como el de /var
root@madhatter # df -k /var Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/var 2031101 1472862 497306 75% /var
Vemos que sólo ha aumentado en 24 Kb.
Ahora, entramos como usuario root. Según lo especificado en la fórmula, crece de tamaño en 28 bytes aparentes (Pero solo 1 kb real)
root@madhatter # ls -la lastlog
-r--r--r-- 1 root root 28 Dec 10 14:32 lastlog
root@madhatter # du -ks lastlog
1 lastlog
Kb que se descuenta de /var
root@madhatter # df -k /var Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/var 2031101 1472863 497305 75% /var
Ahora, procedemos a entrar con el usuario que tiene el UID mas alto en la maquina
prueba:x:65002:1::/var/tmp/usuario_prueba:/usr/bin/ksh
De nuevo, el fichero crece según la fórmula (65002+1)*28=1820084
root@madhatter # ls -la lastlog
-r--r--r-- 1 root root 1820084 Dec 10 14:35 lastlog
Pero sólo ha aumentado 23 Kb
root@madhatter # du -ks lastlog 24 lastlog
Así como /var
root@madhatter # df -k /var Filesystem kbytes used avail capacity Mounted on /dev/vx/dsk/var 2031101 1472894 497274 75% /var
Así pues no hay reserva de espacio en/var por parte de last log en lo que concierne al tamaño aparente, sino únicamente al tamaño real.
Y recordad: This is not a bug, is a feature
¡Trata de arrancarlo, por Dios!
¿Qué haríamos sin Veritas Volume Manager, me pregunto?. La cantidad de frustraciones y malos ratos que nos ha ahorraro… al tiempo que nos ha producido frustraciones y malos ratos nuevo es legandaria. Se puede odiar o se puede adorar a Veritas y conozco ambos tipos de gente, e incluso gente que pasa por ambos estado según el día.
Lo que es innegable es la necesidad de usar un buen gestor de volúmenes, que sea fiable, robusto y sencillo de manejar. En mi opinión, VXVM y VXFS lo son.
Sin embargo, nada es de color de rosa, y en ocasiones, al intentar arrancar una máquina que haya caído por cualquier cuestión (Un panic causado por una CPU en mal estado, por ejemplo), puede haber problemas (vaya novedad) y provocar que los volúmenes queden en estado disabled.
root@madhatter:/root# vxprint -htr [...] v crash - DISABLED ACTIVE 2427516 ROUND - fsgen pl crash-01 crash DISABLED ACTIVE 2427516 CONCAT - RW sd rootdisk-03 crash-01 rootdisk 15254567 2427516 0 c0t0d0 ENA pl crash-02 crash DISABLED ACTIVE 2427516 CONCAT - RW sd rootmirror-03 crash-02 rootmirror 8955954 2427516 0 c0t8d0 ENA [...]
Este problema es fácilmente solucionable. Únicamente hace falta deshabilitar uno de los plexes del volumen.
root@madhatter:/root# vxmend off crash-01 [...] v crash - DISABLED ACTIVE 2427516 ROUND - fsgen pl crash-01 crash DISABLED OFFLINE 2427516 CONCAT - RW sd rootdisk-03 crash-01 rootdisk 15254567 2427516 0 c0t0d0 ENA pl crash-02 crash DISABLED ACTIVE 2427516 CONCAT - RW sd rootmirror-03 crash-02 rootmirror 8955954 2427516 0 c0t8d0 ENA [...]
Tras ello, lo habilitamos de nuevo, dejando el plex en DISABLED CLEAN, y lo limpiamos. Es necesario psaar por estos estados, ya que de otro modo VXVM se quejará y no nos dejará continuar.
root@madhatter:/root# vxmend on crash-01 root@madhatter:/root# vxmend fix clean crash-01 root@madhatter:/root# vxprint -htr
[...] v crash - DISABLED ACTIVE 2427516 ROUND - fsgen pl crash-01 crash DISABLED CLEAN 2427516 CONCAT - RW sd rootdisk-03 crash-01 rootdisk 15254567 2427516 0 c0t0d0 ENA pl crash-02 crash DISABLED ACTIVE 2427516 CONCAT - RW sd rootmirror-03 crash-02 rootmirror 8955954 2427516 0 c0t8d0 ENA [...]
El último paso es arrancar el volumen completo.
root@madhatter:/root# vxvol start crash root@madhatter:/root# vxprint -htr [...] v crash - ENABLED ACTIVE 2427516 ROUND - fsgen pl crash-01 crash ENABLED ACTIVE 2427516 CONCAT - RW sd rootdisk-03 crash-01 rootdisk 15254567 2427516 0 c0t0d0 ENA pl crash-02 crash ENABLED ACTIVE 2427516 CONCAT - RW sd rootmirror-03 crash-02 rootmirror 8955954 2427516 0 c0t8d0 ENA [...]
Repetir el proceso en todos los volúmenes afectados. Y ya tenemos la máquina limpita.
Y para acabar, les remito al excelente tutorial de Veritas FS y Veritas VM de Ben Rockwood Aunque se trata de versiones antiguas del software es un punto de partida excelente para comprender esta tecnología.
MPXIO para el nene y la nena. Segunda parte
Una vez comprendidas las generalidades, vamos a proceder a la implementación del asunto, que es lo más interesante.
MPXIO está implementado en Solaris desde la versión 8, pero su configuración ha sido cambiada en Solaris 10, de modo que un caveat antes de ponernos en harina: Imaginemos que el artículo ha sido escrito para las versiones 8 y 9 de Solaris. Haré las matizaciones necesarias para la última versión.
Retomando el ejemplo de la última entrada, vamos a examinar el total de discos que habría en la máquina:
root@madhatter $ format
Searching for disks...done
AVAILABLE DISK SELECTIONS: 0. c0t0d0 /pci@83,4000/FJSV,ulsa@2,1/sd@0,0 1. c0t1d0 /pci@83,4000/FJSV,ulsa@2,1/sd@1,0 2. c2t50060168082006E2d0 /pci@83,2000/pci@2/lpfc@4/fp@0,0/ssd@w50060168082006e2,0 3. c2t50060160082006E2d0 /pci@83,2000/pci@2/lpfc@4/fp@0,0/ssd@w50060160082006e2,0 4. c2t50060168082006E2d1 /pci@83,2000/pci@2/lpfc@4/fp@0,0/ssd@w50060168082006e2,1 5. c2t50060160082006E2d1 /pci@83,2000/pci@2/lpfc@4/fp@0,0/ssd@w50060160082006e2,1 6. c3t50060169082006E2d0 /pci@83,2000/pci@2/lpfc@5/fp@0,0/ssd@w50060169082006e2,0 7. c3t50060161082006E2d0 /pci@83,2000/pci@2/lpfc@5/fp@0,0/ssd@w50060161082006e2,0 8. c3t50060161082006E2d1 /pci@83,2000/pci@2/lpfc@5/fp@0,0/ssd@w50060161082006e2,1 9. c3t50060169082006E2d1 /pci@83,2000/pci@2/lpfc@5/fp@0,0/ssd@w50060169082006e2,1 Specify disk (enter its number): ^D
Antes de nada, será necesario instalar el software de SAN más los parches correspondientes. Diríjanse a Sunsolve a golpe de atambores para recoger el SAN Foundation Kit, así como los drivers y parches para HBA Emulex, que será las que utilicemos en este ejemplo. En caso de Solaris 10, no será necesario, ya que está incluído con el sistema operativo.
Una vez instalado todo, editaremos el fichero /kernel/drv/scsi_vhci.conf
Vamos a buscar la entrada mpxio-disable=”yes”;
Y la cambiaremos para que diga mpxio-disable=”no”;
Nota: En Solaris 10 el fichero a editar es /kernel/drv/fp.conf
Por último, y en caso de que estemos utilizando un dispositivo de almacenamiento externo, habrá que rellenar la parte correspondiente del final del fichero. El ejemplo que pongo a continuación está hecho usando una cabina IBM.
# For enabling MPxIO support for 3rd party symmetric device need an # entry similar to following in this file. Just replace the "SUN SENA" # part with the Vendor ID/Product ID for the device, exactly as reported by # Inquiry cmd. # # This functionality requires patch 113039-02 (or higher). # # device-type-scsi-options-list = # "SUN SENA", "symmetric-option"; # # symmetric-option = 0x1000000; # device-type-scsi-options-list = "IBM 2105800", "symmetric-option"; symmetric-option = 0x1000000;
Eso es todo, ahora será necesario realizar un reboot con reconfiguración. Una vez terminado, podremos ver que los discos en el sistema han cambiado:
AVAILABLE DISK SELECTIONS: 0. c0t0d0 /pci@83,4000/FJSV,ulsa@2,1/sd@0,0 1. c0t1d0 /pci@83,4000/FJSV,ulsa@2,1/sd@1,0 2. c4t6006016061B71000AD0810C9979CD911d0 /scsi_vhci/ssd@g6006016061b71000ad0810c9979cd911 3. c4t6006016061B7100055B12704989CD911d0 /scsi_vhci/ssd@g6006016061b7100055b12704989cd911 Specify disk (enter its number): ^D
De hecho, la correcta composición del dispositivo nuevo se puede ver en el arranque:
Dec 18 11:42:24 madhatter mpxio: [ID 669396 kern.info] /scsi_vhci/ssd@g600c0ff000000000086ab238b2af0600 (ssd11) multipath status: optimal, path /pci@9,600000/SUNW,qlc@1/fp@0,0 (fp1) to target address: 216000c0ff886ab2,0 is online. Load balancing: round-robin
En caso de que haya algún problema con los caminos, sería reportado en el messages:
Aug 24 07:09:01 madhatter mpxio: [ID 669396 kern.info] /scsi_vhci/ssd@g600c0ff000000000086ab238b2af0600 (ssd11) multipath status: degraded, path /pci@9,600000/SUNW,qlc@1/fp@0,0 (fp1) to target address: 216000c0ff886ab2,0 is online. Load balancing: round-robin
Y asimismo, podemos ver lo que hay por debajo, así como los caminos independientes, haciendo un luxadm de los discos. De la misma forma, podemos ver si hay problemas con los caminos de las tarjetas hacia las LUN.
root@madhatter# luxadm display /dev/rdsk/c4t6006016061B71000AD0810C9979CD911d0s2 DEVICE PROPERTIES for disk: /dev/rdsk/c4t6006016061B71000AD0810C9979CD911d0s2 Vendor: SUN Product ID: StorEdge 3510 Revision: 413C Serial Num: 086AB238B2AF Unformatted capacity: 1397535.000 MBytes Write Cache: Enabled Read Cache: Enabled Minimum prefetch: 0x0 Maximum prefetch: 0xffff Device Type: Disk device Path(s):
/dev/rdsk/c4t6006016061B71000AD0810C9979CD911d0s2 /devices/scsi_vhci/ssd@g600c0ff000000000086ab238b2af0600:c,raw Controller /pci@83,2000/pci@2/lpfc@4/fp@0,0 Device Address 216000c0ff886ab2,0 Host controller port WWN 210000e08b14cc40 Class primary State ONLINE Controller /pci@83,2000/pci@2/lpfc@4/fp@0,0 Device Address 266000c0fff86ab2,0 Host controller port WWN 210000e08b144540 Class primary State ONLINE
Este disco ¿De quien es?
Los mensajes de error en almacenamiento, tanto interno como externo, en sistemas Solaris tienen la particularidad de no ser especialmente amistosos con el que los lee por primera vez. Un ejemplo:
Apr 13 06:22:06 madhatter scsi: [ID 107833 kern.warning] WARNING: /pci@7c,600000/SUNW,qlc@1/fp@0,0/ssd@w50060e8003ea6d03,49 (ssd356): Apr 13 06:22:06 madhatter SCSI transport failed: reason 'timeout': retrying command Apr 13 06:22:36 madhatter scsi: [ID 107833 kern.warning] WARNING: /pci@fc,600000/SUNW,qlc@1/fp@0,0/ssd@w50060e8003ea6d13,49 (ssd986): Apr 13 06:22:36 madhatter SCSI transport failed: reason 'timeout': retrying command Apr 13 06:23:06 madhatter scsi: [ID 107833 kern.warning] WARNING: /pci@7c,600000/SUNW,qlc@1/fp@0,0/ssd@w50060e8003ea6d03,49 (ssd356): Apr 13 06:23:06 madhatter SCSI transport failed: reason 'timeout': giving up
El problema es descodificar el chorro que sale en un disco en concreto. Afortunadamente para nosotros, Solaris pone un acceso al nombre de disco concreto dentro del directorio /dev/dsk
De este modo, se trata de una simple cuestión de filtrado.
madhatter:root:/dev/dsk# ls -l *s2 |grep w50060e8003ea6d03,49 lrwxrwxrwx 1 root root 72 Sep 5 2005 c6t50060E8003EA6D03d73s2 -> ../../devices/pci@7c,600000/SUNW,qlc@1/fp@0,0/ssd@w50060e8003ea6d03,49:c
Tachan!. Sabía que ese almacenamiento externo del todo a un euro me iba a causar problemas
¿Y si son muchos los discos que están fallando?. Ah, pues entonces viene a nosotros el poder de la shell:
madhatter:root:/dev/dsk# for i in `grep WARNING /var/adm/messages |nawk ' {print $10}'`;
do ls -arlit *s2 |nawk ' {print $10}'; done
Esto nos sacaría por pantalla únicamente el disco con problemas.
Ahora ya podemos examinar la cabecera del disco para ver si se puede leer correctamente, así como los caminos físicos, por si hubiera problemas en alguna parte de la cadena.
Otro día hablamos de las HBA, esas grandes desconocidas
