Mostrando entradas con la etiqueta tape. Mostrar todas las entradas
Mostrando entradas con la etiqueta tape. Mostrar todas las entradas

viernes, 2 de marzo de 2018

¿Cómo uso una unidad de cinta LTO-7 Ultrium en Ubuntu?

La personalidad deportiva de Juan Perón lo hacía adepto a todo tipo de nuevos entretenimientos los cuales promovía en su gobierno como ejemplo funcional del progreso. Mientras inauguraba una sala de bowling, el General enseñaba cómo instalar un sistema LTFS para respaldar en cassettes de cinta magnética LTO Ultrium en Ubuntu.


Si hacemos todo bien no será necesario actuar de forma revolucionaria, sino a través de una constante evolución en lo que lo nuevo y mejor reemplace a lo viejo y peor. Esa es la vertiente natural que han de perseguir los Pueblos siempre que sea posible.

Sin embargo, no siempre las condiciones son lo óptima que los Pueblos necesitan. Este simple juego del bowling, de reglas tan sencillas, contiene en su principio rector, nociones de las que hemos de aprender para aplicarlas en la lid polítca.

Vean señores, hay situaciones donde inevitablemente hay bolas que se corren, y hemos de emplear un método de fuerza para voltear a quien está parado sin moverse.
Naturalmente que una acción de esta característica, que podremos llamar revolucionaria, podemos también encontrarla en la informática, sobre todo en el área del Almacenamiento de Masa.


Ya he explicado cómo operar en forma manual una unidad de lectograbación de cinta convencional, y hemos visto que en estas máquinas de simple tecnología,  realmente debemos controlar el avance y la grabación de las bobinas de cinta magnética, siguiendo complicados y lentos esquemas, ya que los datos se almacenan secuencialmente.


A diferencia de otras unidades de cinta, las unidades tipo LTO son muy sencillas de usar, desde el punto de vista de la administración. Esto es así en parte porque existen variantes internas y externas de las mismas, en otro sentido porque utilizan interfaces de conexión modernas como SAT o SCSI. Y finalmente porque la gestión actual de los archivos no requiere grabar "a lo indio" los datos en un lugar indeterminado en una cinta magnética, sino que los cartuchos modernos disponen de un sistema de archivo dedicado específico, el LTFS.

El LTFS (Sistema de Archivo para Cintas Lineales) fue concebido como un esquema de archivado capaz de avalar el acceso directo a los datos almacenados en una cinta, sin tener que recurrir a índices manuales, o aplicaciones específicas de respaldo. Esto presenta ventajas obvias al acceder a los datos en múltiples unidades de respaldo, aunque los tiempos de acceso, la latencia y demás permanecen bajos y comparables a los de cualquier sistema de cintas magnéticas en lugar de los los más rápidos discos duros magnéticos o las modernas unidades de estado sólido.

Aún así, los casettes o cartuchos de cintas de formato Ultrium LTO (fabricadas por Fujifilm para Quantum, Sony, HP, IBM y otras), son relativamente baratos y muy confiables.

El conjunto completo requiere la unidad de cinta, su controladora, y los controladores LSFS para el sistema operativo que empleemos. En este caso nos haremos prácticos con una unidad de cinta LTO interna, para una bahía de 5,25 pugadas, marca HP Enterprise modelo StoreEver Ultrium 15000 LTO-7).
En nuestro caso particular, también necesitaremos una tarjeta controladora de disco SCSI. Vean señores, algunas presentaciones de unidades  de cinta internas o externas incluyen ya la plaqueta adaptadora a un precio promocional en la caja, conformando un kit. En nuestro caso no la traía, de modo que aprovechamos para incorporarle al servidor una tarjeta controladora peronista LSI 9211-8i SAS/SATA PCI-e, de categoría 6GBps y 8 puertos, la cual también nos representará una mayor velocidad de transferencia a los múltiples discos rígidos con los que contamos en el servidor.

Nuestro servidor cuenta con Ubuntu Server 16.04LTS de 64 bits, que encontró e instaló las controladores de la plaqueta SCSI. Al conectarle los discos rígidos SATA los reconoció sin problemas. También reconoció la unidad de cinta LTO-7 con los controladores nativos.

Ahora bien, para poder utilizar el sistema de archivo para cinta lineal (LTFS), debemos instalar sus controladores. Esta tarea requiere que tengamos conexión a internet, y sólo necesitamos hacerlo por única vez. Tengamos en cuenta que instalaremos LTFS en su versión 2.11, que es compatible con LTO-7 pero también con unidades anteriores como LTO-6 o LTO-5.

Para instalar el controlador del sistema de archivos para cinta lineal en nuestro sistema de 64 bits, debemos estar logueados al servidor, e ingresamos los siguientes Comandos de Organización:

cd ~/Descargas ;
wget http://www.tandbergdata.com/default/assets/File/Downloads/ltfs211/LTFS_BINARIES_RHEL.tar.gz ;

tar xvf LTFS_BINARIES_RHEL.tar.gz ;

rm COPYING.LIB INSTALLING.linux README ;
modprobe fuse ;

sudo tar xvf LTFS_BINARIES_RHEL5.5_x64.tar.gz -C /

Luego reiniciamos el servidor con:

sudo reboot

Una vez instalado el controlador del sistema de archivos de cinta lineal (LTFS),  ya podremos crear particiones en cinta y trabajar de manera simple con la unidades de cinta Ultrium LTO-7 en nuestro sistema. Os enseñaré los procedimientos básicos para almacenar información de manera peronista en cinta LTO.

Crear una partición LTFS en el cartucho de cinta

En primer lugar debemos crear la partición LTFS en la cinta. Naturalmente para ello colocamos un cartucho de cinta en la unidad (en este caso, un cartucho de cinta Ultrium LTO-7 marca Quantum, de media pulgada). Estos cartuchos vienen en una caja plástica y tienen una capacidad nominal de 6TB de capacidad. También se pueden usar cartuchos LTO-5 y LTO-6 (de 1,6TB).
Para crear en la cinta una partición LTFS, podremos usar la terminal de GNU con Linux. Podremos ingresar un comando similar a éste (siendo /dev/nst0 el nombre de dispositivo que el sistema le ha asignado a nuestra unidad de cinta):

time mkltfs --device=/dev/nst0 --tape-serial="123457" --volume-name="CINTA1"
 
Debemos tener en cuenta que tanto los cartuchos LTO-6 como este LTO-7 permite una o más partición por cartucho de cinta. Los cartuchos LTO-5 o anteriores - en cambio - sólo permiten una única partición LTFS (amén de tener menos capacidad).

La unidad de cinta StorEver Ultrium LTO-7 con el cartucho emite unos ruidos similares a una vieja VHS y comienza a trabajar. Nos devuelve en la terminal algo como:

LTFS15000I Starting mkltfs, LTFS version 2.1.1, log level 2
LTFS15041I Launched by "mkltfs --device=/dev/nst0 --tape-serial=123457 --volume-name=CINTA1"
LTFS15042I This binary is built for Linux (x86_64)
LTFS15043I GCC version is 4.1.2 20080704 (Red Hat 4.1.2-48)
LTFS17087I Kernel version: Linux version 4.13.0-36-generic (buildd@lcy01-07) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #118-Ubuntu SMP Thu Dec 17 22:52:10 UTC 2015 i386
LTFS17089I Distribution: DISTRIB_ID=Ubuntu
LTFS17089I Distribution: NAME="Ubuntu"
LTFS15003I Formatting device '/dev/nst0'
LTFS15004I LTFS volume blocksize: 524288
LTFS15005I Index partition placement policy: None

LTFS17085I Plugin: Loading "ltotape" driver
LTFS20013I Drive type is HPE StoreEver LTO7, serial number is xxxxxxxxx
LTFS17160I Maximum device block size is 524288
LTFS15049I Checking the medium
LTFS15010I Creating data partition b on SCSI partition 1
LTFS15011I Creating index partition a on SCSI partition 0
LTFS17165I Resetting the medium's capacity proportion
LTFS11097I Partitioning the medium
LTFS11100I Writing label to partition b
LTFS11278I Writing index to partition b
LTFS11100I Writing label to partition a
LTFS11278I Writing index to partition a
LTFS15013I Volume UUID is: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

LTFS15019I Volume capacity is 2524 GB
LTFS20076I Triggering drive diagnostic dump
LTFS20096I Diagnostic dump complete
LTFS15024I Medium formatted successfully

real    1m1.598s
user    0m0.006s
sys 0m0.006s


Esto nos dice que el el sistema de archivos quedó preparado, y tardó un minuto en hacerlo.

Montar la partición LTFS en nuestro sistema

Cuando queremos grabar información en el cartucho ya particionado, debemos montarlo. Si lo queremos hacer a mano desde la terminal podríamos ingresar los siguientes Comandos de Organización:

sudo mkdir /mnt/ltfs ;

sudo mkdir /tmp/ltfs ;

sudo ltfs /mnt/ltfs -o devname=/dev/st0 -o work_directory=/tmp/ltfs -o trace -o eject -o umask=777 -o noempty -o sync_type=unmount ;


Ahora podremos copiar los datos que deseemos al cartucho de cinta, ya sea por el método "vikingo" de copiar los ficheros con la terminal al directorio montado /mnt/ltfs, o directamente usando nuestro administrador de archivos gráfico y arrastrando los archivos hasta /mnt/ltfs, carpeta que aparecerá en el Escritorio como si fuese un disco o pendrive común y corriente...

Probando capacidad y velocidad.

El cartucho tiene 6TB/15TB (6 terabytes sin compresión, 15 terabytes con compresión), y la velocidad de grabación sin comprimir es de 300 megabytes por segundo, lo cual nos da 1,08 GB/hora. Para llenar los 6 TB duraremos poco menos de 6 horas.

La capacidad de las cintas fue verificada con compresión activada y desactivada. En cuatro pruebas logramos la capacidad máxima del cartucho de cinta, aunque la velocidad de grabación depende de la compresibilidad de los datos (toda vez que activemos la opción de compresión).

Con compresión y encriptación, usando documentos de oficina (PDF, documentos de texto, planillas de cálculo, etc), ciertamente se logran los valores máximos nominales de la cinta, 750mb/s y compresión 2,5:1, lo que nos permite en casi 6 horas alcanzar unos 15TB por cartucho LTO-7 (en tal caso se escribe la cinta a 2,7 TB/h). Sin embargo, esto depende de la velocidad de proceso y la memoria instalada en el servidor, y en un servidor no dedicado podría tardar algo mas más en realizar esta tarea.

Si desactivamos la compresión y encriptación, podremos lograr los valores nominales de almacenamiento, que en el caso de estos cartuchos LTO-7 es de 300mb/s y 6TB de almacenamiento (a una velocidad de escritura de 1,08TB/h). Esto es un resultado real que logramos con videos e imágenes comprimidas, uno de los usos más comunes de estas cintas Ultrium.

Todas las pruebas fueron realizadas con un tamaño de bloque de 256KB, y pudieron ser leídas y descargadas tanto en servidores Ubuntu 16.04LTS como un equipo munido del privativo y limitado Micro$oft Window$ 2012 R2.

Es importante notar que el controlador de este sistema LTO cuenta con capacidad de transferencia nativa constante, la cual está pensada para prevenir las molestas y múltiples operaciones de avance/detenimento en la unidad de cinta. El controlador del sistema de cinta se encarga de regular la velocidad de envío de datos a la unidad a una tasa apropiada a fin de asegurar una grabación continua y homogénea. Esta velocidad variará dependiendo del origen de los datos y de la velocidad y capacidad de la cinta - lo importante es que tanto el servidor como la unidad de cinta coordinan su operación de manera que la unida de cinta no tenga que grabar "a los saltos" como otras unidades de cinta normales o cartuchos.

En este caso, esta característica funcionó muy bien - no hubo casi detenimientos y continuaciones en la grabación mientras se copiaban datos, y funcionó "como una videocasettera". Tampoco se afectaron los tiempos de grabación de respaldo al usar la encriptación nativa de la unidad por medio del controlador LTO, ni se afectó la interoperatividad de las unidades entre sistemas operativos distintos.

En resumen: en condiciones donde se requiera operación muy confiable y la velocidad de respaldo y recuperación no sea crítica, las unidades LTO-7 pueden ser usadas perfectamente como una unidad de respaldo.

Todos las cifras anunciadas por el producto pueden ser logrados de forma realista. La configuración es simple y directa. La funcionalida LTFS opera efectivamente en Ubuntu. La performance esencialmente es el doble que la de la versión LTO-6.

Nota: Si quisiéramos desinstalar el sistema de archivos para cintas lineales (ltfs) de nuestro servidor, deberíamos ingresar en la terminal:

sudo rm /usr/local/bin/*ltfs* 
sudo rm /usr/local/lib/libltfs*
sudo rm /usr/local/lib/ltfs/*


lunes, 26 de febrero de 2018

¿Cómo manejo una unidad de cinta en Ubuntu?

Juan Perón exponía durante los distintos actos públicos la ideología benefactora del Estado Justicialista, y propalaba paternalmente aquellos conocimientos que podían servir al Pueblo. En un discurso en la inauguración del Tambo Nuevo en Santa Fé explica cómo controlar las antiguas unidades de cinta para hacer respaldos en Ubuntu.

Vean señores, en nuestra era, no cabe duda que el medio de almacenamiento mas extendido está constituido por los discos rígidos magnéticos.

De un tamaño original de un lavarropa, la evolución los ha hecho miniaturizarse, de manera tal que hoy no tienen más de 3 pulgadas de ancho y ocupan menos espacio que un atado de Pall Mall.

Si necesitamos transportabilidad y viajar con ellos, a estos chiquitos se le suele adosar de fábrica una interfaz USB, con lo que logramos un disco rígido externo. También, si nuestras necesidades de espacio y velocidad no son tan acuciantes, contamos ya con las prácticas memorias Flash (también con la misma interfaz, conformando un pendrive). Ello los convierte en los más peronistas de los medios de almacenamiento.

Sin embargo, existen medios de almacenamiento que - a pesar de su veteranía - no cejan en dar pelea y constituyen un verdadero "primer peronismo". Esto es así pues la confiabilidad de su almacenamiento y la gran durabilidad y estabilidad de su medio se une al bajo precio que pueden llegar a tener en ciertas condiciones (si lo comparamos con su capacidad). Uno de estos dispositivos para el almacenamiento ha superado la barrera del tiempo y siempre se renueva tecnológicamente: es la cinta magnética.

Desde las unidades de IBM que acompañaban a las mainframe (de un tamaño individual que superaba a una heladera Siam), hasta el simpático Datasette del microordenador Commodore 64, la cinta ha sido protagonista del almacenamiento de Masa.


A nivel empresarial, se utiliza la cinta como medio de respaldo de la información, y actualmente conserva su valía en tal accionar. Es por ello que hoy, a pesar de la inmensidad de los Terabytes disponibles en sistemas de disco duro, la cinta aún conserva su vialidad como medio de resguardo.


Su principal desventaja es tal vez la secuencia lineal que normalmente tiene su operación de escritura (lo cual lo desaconseja para tareas diarias), y también lo lenta de su acción de lectura. Su ventaja radica en la alta capacidad relativa y en el bajo costo del medio de almacenamiento.

En este caso, explicaré el uso de una unidad marca HP modelo C1533A adosada a una placa controladora PCI Adaptec Scsi-2.

Se trata de una unidad tecnológicamente superada pero que puede servir para practicar y para emprender para pequeñas tareas de resguardo a una velocidad de 1,2GB/h. Esto es así pues la unidad de cinta junto con su placa controladora la recibimos como donación, y emplea extendidos casettes de cinta DAT de los cuales conseguimos en cajas bulk de 20 unidades por muy bajo costo.

Específicamente en este caso del Verbatim DataLife formato DDS-2 (cassette con 120 metros cinta de 4mm de ancho (realmente 3,81mm), que permiten almancenar unos 4GB de datos sin compresión y 8GB con compresión.

Nos sirven como una buena opción para respaldar datos de trabajo de múltiples servidores, y distinta información en forma de documentos de texto y planillas electrónicas, así como guardar datos de páginas webs montadas en una miríada de servidores Apache...

Pues bien, los sistemas operativos GNU con Linux (y otros sistemas similares a Unix) son capaces de funcionar a través de estos dispositivos de cinta, que si bien son poco conocidos ya, en casos específicos siguen siendo útiles. Desde el punto de vista del software libre, se emplean el comando mt ("magnetic tape", o cinta magnética) para controlar la operación de la o las unidades de cinta magnética. Necesitaremos utilizarlo toda vez que operemos con este tipo de dispositivos.

Dispositivos de Unidades de Cinta

En primer lugar, debemos conocer cómo nuestro sistema llama o nomencla a nuestra unidad de cinta (en este caso la HP C1533A). Esto es así pues - desde un punto de vista lógico - en los sistemas GNU con Linux los dispositivos de cinta son dispositivos de caracteres nomenclado como simples archivos en nuestro sistema de archivos. O sea, como todos los demás dispositivos, encontraremos un fichero especial en el directorio /dev/ al cual nos referiremos como la unidad de cinta.

Sin embargo, podríamos encontrar varios tipos distintos de dispositivos de cinta, al cual el sistema nomencla dependiendo sus características propias. Por ejemplo:
  • Las unidades de cinta de interfaz SCSI usan los nombres /dev/st0, /dev/nst0, /dev/st1, /dev/nst1, etcétera. La interfaz SCSI y su controlador es considerado de las más confiables, pero naturalmente las unidades de cinta SCSI son más caras que las otras.
  • Los dispositivos de cinta ATAPI comienzan con /dev/ht0 y /dev/nht0.
  • También existe un soporte limitado para unidades de cinta a través del viejo controlador floppy, localizados en /dev/ft0 y /dev/ntf0.

Existen dos versiones de cada dispositivo de cinta en los sistemas GNU con Linux:
  • Un dispositivo rewind rebobina la cinta después de cada operación, por ejemplo /dev/st0 es un dispositivo rewind (con capacidad de rebobinado).
  • Un dispositivo de cinta no-rewind no rebobinará la cinta después de sus operaciones. Los dispositivos No-rewind comenzarán con una n; por ejemplo, /dev/nst0 es un dispositivo no-rewind.
Debemos saber que en vista de esta diferenciación mecánica, los dispositivos rewind como nuestra unidad DDS-2/DAT son prácticamente inútiles para el uso del archivado diario. Su objetivo solamente es realizar respaldos secuenciales en la cinta. En las secciones siguientes veremos que será necesario operarlos reposicionando la cinta mediante las acciones de avance o rebobinado de cinta...

Ahora bien, para identificar nuestra unidad de cinta, podremos ingresar el comando:

dmesg

...y buscar en el mismo las identificadores de la misma:
  Vendor: HP        Model: C1533A            Rev: 9503
  Type:   Sequential-Access                  ANSI SCSI revision: 02
st: Version 20010812, bufsize 32768, wrt 30720, max init. bufs 4, s/g segs 16
Attached scsi tape st0 at scsi0, channel 0, id 4, lun 0

...como vemos, en el caso de la unidad de cinta HP C1533A, recibe en nuestro sistema la nomenclatura de /dev/st0 (el primer nombre de dispositivo de cinta SCSI con capacidad de rebobinado).

Configurar el entorno

Ya que hemos visto qué nombre recibe la unidad de cinta en nuestro sistema, será útil especificarlo en nuestro archivo de entorno .bashrc. Esto es particularmente útil si siempre usaremos la misma unidad de cinta en el sistema, o si sólo tenemos una de ellas, pues nos ahorrará tener que expecificar en cada comando que la unidad de cinta es /dev/st0 o lo que fuese.

Configuraremos entonces la variable de entorno TAPE para que represente el dispositivo que tenemos. En nuestro caso podríamos ingresar:

nano ~/.bashrc

...esto abrirá el editor de texto GNU Nano con archivo de ejecución .bashrc (ya debería tener contenido, no modificamos nada de lo que ya está escrito). Al final del archivo le agregamos las siguientes líneas:

## Agregado de Variable TAPE por Usuario Perón ## 
TAPE=/dev/st0
export TAPE

Finalmente, guardamos el archivo con Ctrl+q y salimos del editor GNU Nano con Ctrl+x.

Trabajando con Unidades de Cinta

La cinta es una de los medios de almacenamiento más simples en existencia. Podríamos pensar en la cinta como una secuencia de archivadas, con una marca de archivo al final de cada una de ellas que la separa de la siguiente, como se muestra en la figura 1. Presten particular atención a que no existe una marca de archivo al principio de la cinta, y que la primera archivada (llamamos así a la tanda de ficheros que se graban secuencialmente) recibirá el número 0.


Figura 1: Archivadas y marcas de archivo en la cinta.

A diferencia de otros dispositivos de almacenamiento más complejo, la cinta normalmente carece de un sistema de archivos. Por otro lado, no existe información en la cinta que indique el nombre de cada archivo (aunque los sistemas de respaldo automático usualmente incluyen un archivo de índice especial al comienzo de la cinta). Cuando operamos manualmente con la cinta, operaremos con los números de archivo y las marcas de archivo, y nada mas.

Por ello tomamos un casette DDS-2 y lo colocamos en la unidad de cinta. Como operaremos "a pelo", debemos tener cuidado de lo que hacemos. Tal es el motivo por el cual usamos una cinta virgen para practicar.

Para acceder a los datos en la cinta, debemos manipular el cabezal de la unidad de lectura. La figura 2 nos muestra la posición inicial del cabezal. Suponiendo que  que nuestro dispositivo de cinta sea st0, empleamos el dispositivo /dev/st0.

Primero, verificamos la posición de la cinta con el comnado status mt (la variable -f /dev/st0 especifica el archivo de dispositivo de la unidad de cinta. No es necesario poner dicha variable si ya especificamos nuestra variable de entorno TAPE.

mt -f /dev/st0 status

Figura 2: El cabezal al comienzo de la cinta.

El sistema debería devolvernos algo así (en el ejemplo, una unidad de cinta DAT):
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x13 (DDS (61000 bpi)).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

Esto nos representa mucha información:
  • El número de archivo actual es 0.
  • El número de bloque actual es 0, de modo que el cabezal está al comienzo del archivo.
  • Debemos ignorar la partición, sólo las unidades de tipo moderno los soportan y esta unidad de cinta tipo DDS-2 no lo hace.
  • El tamaño de bloque es 0, lo que en realidad significa que la unidad de cinta no tienen un tamaño de bloque fijo específico.
  • El código de densidad especifica cuánta información puede caber en la cinta.
  • El soft error count es la cantidad de errores recuperables que han ocurrido desde la última vez que ejecutamos mt status.
  • Los status bits explican más acerca del estado de la cinta y de la unidad de cinta. BOT significa "comienzo de cinta", y ONLINE reporta que la unidad de cinta está lista y cargada.

Creando Archivadas en una cinta

Es difícil entender cómo una unidad de cinta opera pasando a través de varios ficheros en una cinta cualquiera de una colección de respaldos. Por lo tanto, para explicar el proceso de búsqueda en una cinta, lo imaginaremos creando algunas archivadas por nosotros mismos, antes de especificar cómo descargar sus datos. Una vez que hayamos comprendido esto, seremos capaces de avanzar y rebobinar la cinta sin grandes confusiones que nos hagan preocupar por la pérdida de datos. Seremos entonces verdaderos peronistas de pelo en pecho.

Imaginemos que queremos crear tres archivadas en la cinta magnética. Específicamente, usaremos tar para encadenar todos los ficheros que se encuentran en los directorios /lib, /boot y /dev de nuestro sistema GNU con Linux. Estos directorios son algunos de los importantes de sistema y los usaremos como ejemplos.
  1. Colocamos un cartucho de cinta en la unidad (una casette DDS-2 virgen o cuyo contenido no nos interese)-
  2. A diferencia del caso anterior, nos aseguramos que nuestra variable de entorno TAPE esté configurada como un dispositivo no-rewind (sin rebobinado), en este caso podremos emplear /dev/nst0.
  3. Ejecutamos el comando mt status para verificar que la cinta está en la unidad y que la variable TAPE está configurada.
  4. Cambiamos al directorio raíz de nuestro sistema de archivos con el comando cd /.
  5. Creamos una archivada tar del primer archivo en la cinta (el directorio /lib) por medio del comando: tar zcv lib
  6. Ejecutamos el comando mt status. La salida debería ser algo similar a esto, indicando que la cinta está en el siguiente archivo (archivo 1):
    SCSI 2 tape drive:
    File number=1, block number=0, partition=0.
    Tape block size 0 bytes. Density code 0x13 (DDS (61000 bpi)).
    Soft error count since last status=0
    General status bits on (81010000):
     EOF ONLINE IM_REP_EN
    
  7. Luego creamos una archivada de nuestro directorio /boot con el comando: tar zcv boot
  8. Creamos una archiva da nuestro directorio /dev con el comando: tar zcv dev

En cuanto a la performance, las viejas unidades DDS-2 transmiten unos 0,360MB/s sin compresión, y el doble con compresión 2:1. Esto es unos 1.23GB/h, y tarda unas 3h10m minutos para almacenar los 4GB del casette (sin compresión). Al utilizar compresión, la capacidad se duplica a 8GB, pero se tarda el mismo tiempo en grabar o leer.

Los contenidos de la cinta ahora deberían figurar así:

Figura 3: La cinta contiene tres archivadas, y el cabezal estar al comienzo de una nueva archivada.

Leer desde la cinta

Ahora que tenemos algunos archivos en la cinta, podremos intentar leerlos:
  1. Nos posicionamos al directorio /tmp para evitar cualquier accidente (en caso de que accidentalmente tipeásemos x en vez de t en uno de los pasos que siguen). cd /tmp
  2. Rebobinamos la cinta: mt rewind
  3. Verificamos el primer archivo en la cinta, la archivada de /lib: tar ztv
    Debería aparecer un largo listado de los ficheros en la archivada que están duplicados de nuestra carpeta /lib.
  4. Ejecutamos mt status. Debería devolvernos algo como:
    SCSI 2 tape drive:
    File number=0, block number=4557, partition=0.
    Tape block size 0 bytes. Density code 0x13 (DDS (61000 bpi)).
    Soft error count since last status=0
    General status bits on (1010000):
     ONLINE IM_REP_EN
    
La cinta aún está en la Archivada 0, el primer archivo en la cinta. ¿Cómo sucede esto? La respuesta es que tan pronto como termina su lectura, el comando tar se detiende donde está en la cinta, porque uno podría querer hacer algo loco (como cortar el archivo). El cabezal quedó posicionado al final de la Archivada 0 (notemos el contador de número de bloque, en la devolución del comando mt status).

Figura 4: El cabezal está al final de la Archivada 0.

La consecuencia mas importante de esta nueva posición de la cinta es que otro comando tar ztv no accedería al archivo siguiente en la cinta, porque la cabeza no está al comienzo del nuevo archivo, sino que se encuentra al comienzo de la marca de archivo. Para avanzar la cinta hacia adelante hasta el siguiente archivo (que en este caso, sería la Archivada 1 formada por el directorio /boot), usamos el siguiente comando:

mt fsf

Este comando mueve la cinta de manera que el cabezal quede al final de la marca de archivo (al comienzo de la archivada 1 /boot), como se muestra en la figura:

Figura 5: El cabezal está al comienzo de la archivada 1.

13.6.4 Extraer Archivadas

Para extraer archivadas desde la cinta, necesitamos reemplazar la variable t que aparecía en los comandos de la sección anterior, con la variable xp, de modo que queden así:

tar zxpv

Como es usual, debemos revisar bien nuestro directorio de trabajo antes de extraer cualquier archivo. Os recomiendo siempre utilizar el directorio /tmp para estos menesteres, pues en cualquier situación podremos reever qué leímos en tal directorio... Hombre precavido vale por dos.

Avanzando la cinta y haciendo respaldos

Para avanzar la cinta hasta la siguiente archivada ingresamos:

mt fsf

También existe un comando para rebobinar la cinta:

mt bsf

Sin embargo, es importante comprender que este comando rebobina la cinta hasta el final del archivo previo, o sea, hasta el comienzo de la siguiente marca de archivo que vea el cabezal.

Digamos que estamos al comienzo del archivo 1, como se muestra en la figura 4. Al ejecutar mt bsf, quedará como se muestra en la figura 5. Si en tal caso ejecutamos un mt status, el número de archivo debería ser 0 con un número de bloque de -1 (pues el controlador no puede calcular el largo del archivo por si mismo). En general, para volver al comienzo del archivo previo cuando estamos al comienzo de un archivo, debemos rebobinar dos veces y luego avanzar una vez el cabezal. Gracias a que la mayoría de los comandos de movimento de cinta mt soportan un conteo opcional (por ejemplo, un 2 en este caso), podremos ejecutar la siguiente secuencia:

mt bsf 2
mt fsf

Aún así debemos tomar otra consideración, porque la cinta en este ejemplo ya estaba al comienzo del archivo 1. Al correr mt bsf 2, se intentará rebobinar la cinta dos marcas de archivos. Como el principio de la cinta no tiene una marca de archivo, chocará con el inicio de la misma, produciendo un Error de entrada/salida (I/O error). El comando mt fsf subsiguiente adelantará nuevamente la cinta al archivo 1, esquivando el archivo 0. Si queremos volver al Archivo 0, debemos siempre rebobinar la cinta, con el comando:

mt rewind

Algunas modelos de unidades de cinta son capaces de detectar cuál es la última archivada con datos. En tal caso podríamos avanzar rápidamente la cinta hasta que el cabezal esté en dicho lugar, ingresando:

mt -f /dev/nst0 eod

En nuestro caso, el cabezal volvería a quedar como el la Figura 3...

En resúmen, debemos prestar gran atención a la posición del cabezal con respecto a las marcas de archivo, y elegir el comando apropiado. Si todo esto parece ridículo, probablemente podremos utilizar el direccionador a un n específico, que siempre funcionará (aunque será más lento).

mt rewind
mt fsf archivo

Para expulsar la cinta:

mt offline

Variables del comando mt y estatus

En resúmen, estas son las variables más comunes del mt:
  • mt status Nos devuelve el reporte de estado.
  • mt fsf n Avanza hasta el comeinzo del primer bloque del archivo siguiente. El parámetro n es opcional, si está especificado avanza n archivadas en lugar de solo una.
  • mt bsf n Rebobina hasta el final del archivo previo. La n es un contador opcional de archivos.
  • mt rewind Rebobina la cinta.
  • mt offline Rebobina la cinta, y luego la prepara para su remoción. En algunas unidades de cinta, la unidad de cinta eyecta el cartucho. En otros, destraba la unidad de modo que la podemos sacar a mano.
  • mt retension Avanza la cinta hasta el final y luego la rebobina. Esto a veces ayuda con las cintas que tienen problemas de lectura.
  • mt erase Borra toda la cintas. Usualmente esto lleva un largo tiempo.
Hay una gran variedad de variables para el comando, listados en su página de manual, pero normalmente no son muy útiles a no ser que intentemos extraer bloques desde el centro de una archivada o que busquemos opciones específicas para una unidad de cintas SCSI.

Al ejecutar mt status se nos devolverá una serie de códigos de bit de estado (como el código BOT explicado anteriormente. Aquí hay algunos de ellos:
  • ONLINE La unidad está lista, con una cinta cargada.
  • DR_OPEN La unidad está vacía (posiblemente con la puerta abierta).
  • BOT La posición del cabezal es al principio de la cinta.
  • EOF La posición del cabezal es la de comienzo de un archivo (al final de la marca de archivo).. Este es un código algo confuso, porque se puede confundir con el de "final de archivo".
  • EOT El cabezal está al final de la cinta.
  • EOD El cabezal está al final de la parte grabada de la cinta.
  • WR_PROT La cinta actual está protegida contra escritura.

Comandos para respaldar a cinta


El siguiente es un resumen de los comandos necesarios para controlar una unidad de cinta con el propósito de respaldar/restaurar datos.

En estos ejemplos se utiliza siempre la variable -f /dev/st0 para aclararle al sistema que en los ejemplos, tal dispositivo es nuestra unidad de cinta. Naturalmente debemos cambiarlo si nuestro dispositivo es distinto. Asimismo, si ya configuramos la variable de entorno TAPE como se indicó en el paso anterior, podremos omitir "-f /dev/st0" del comando, o lo que corresponda a nuestro dispositivo.


Para rebobinar la cinta:

mt -f /dev/st0 rewind 

Para respadar en la cinta los directorios /www del servidor web Apache y /home con el comando tar (z: usa compresión Gzip):

tar -czf /dev/st0 /www /home

Para saber en qué bloque estamos con el comando mt:

mt -f /dev/st0 tell

Para mostrar una lista de archivos en la unidad de cinta:

tar -tzf /dev/st0

Para restaurar el directorio /www desde la cinta:

cd /
mt -f /dev/st0 rewind
tar -xzf /dev/st0 www

Para descargar el cartucho de cinta:

mt -f /dev/st0 offline

Para mostrar la información de status de la unidad de cinta:

mt -f /dev/st0 status

Para borrar el cartucho de cinta:

mt -f /dev/st0 erase

Podremos avanzar o rebobinar la cinta con el comando mt:

a) ir al final de los datos:
mt -f /dev/st0 eod

b) Ir a la grabación previa:
mt -f /dev/nst0 bsfm 1

c) Avanzar la cinta:
mt -f /dev/nst0 fsf 1


Ejemplo de Respaldos en múltiples cartuchos de cinta en Linux

Para respaldar a múltiples cintas empleamos el siguiente comando (por ejemplo, para respaldar nuestra carpeta de usuario /home):

tar -clpMzvf /dev/st0 /home 

Para comparar el respaldo de cintas, ingresamos:

tar -dlpMzvf /dev/st0 /home

Para restaurar los datos desde la cinta, en caso de pérdida de datos o fallo de disco duro:

tar -xlpMzvf /dev/st0 /home

...donde,

d: encuentra diferencias entre la archivada y el sistema de archivos.
x: extra los ficheros desde una archivada
l: lista los contenidos de un archivo
p: ignora umask cuando extrae los archivos
M: Crea/lista/extrae un archivo multivolúmen (múltiples cintas).
z: comprime el respaldo enpleando gzip
v: Lista detalladamente los archivos siendo comprimidos,
f /dev/st0 es el dispositivo de cinta
/home: Respalda nuestra carpeta de usuario (puede ser cualquier otra).

Acceso directo a los Archivos de la cinta

tar no es el único comando capaz de escribir archivadas a la cinta. Muchas veces podremos no saber qué hay en la cinta, e incluso si sabemos, podríamos querer copiar un archivo desde la cinta al sistema de archivos local para un análisis más profundo (y mas simple). Para ello podremos emplear al viejo y peludo dd, por ejemplo:

dd if=/dev/nst0 of=archivo_de_salida

Esto a veces podría fallar: podríamos recibir un error de E/S debido a que no especificamos el tamaño de bloque correcto. ¿Por qué? La respuesta requiere ciertas explicaciones. Cuando trabajamos con cintas, a menudo necesitaremos conocer el tamaño de bloque de la cinta. Las aplicaciones tienden a escribir en la cinta en un tamaño de bloque predeterminado, y muchas unidades de cinta no permitirán la lectura desde la cinta a no ser que especificamos correctamente el tamaño de bloque. Esto casi nunca es un problema, porque normalmente escribimos y leemos con el mismo programa. Sin embargo, si queremos usar dd para obtener acceso directo a los archivos de la cinta, podríamos necesitar especificar el tamaño de bloque manualmente.

El programa que escribe el archivo en la cinta normalmente es quien determina el tamaño de bloque a utilizar. En el caso del programa tar, el tamaño de bloque por defecto es de 10KB (especificado en dd como 10k). Como en el programa dd el tamaño bloque por defecto es diferente (usa normalmente 512 bytes), habremos de alterar su parámetro bs ("tamaño de bloque", block size) para que se adapte al contenido hecho con tar en la cinta. Para ello usaríamos:
dd bs=10k if=/dev/nst0 of=archivo_de_salida

Os listaré los tamaño de bloques comunes para diferentes programas utilizados para el copiado o volcado de datos:
Archivador
Tamaño de bloque
Parámetro bs
tar
10KB (20 x 512 bytes)
bs=10k
dd
512 bytes
bs=512
cpio
512 bytes
bs=512
dump
10KB (20 x 512 bytes)
bs=10k
Amanda
32KB
bs=32k

Nota:
A diferencia de tar, dd avanza el cabezal hasta el siguiente archivo en la cinta, en vez de sólo moverlo hasta la marca del archivo.



Las cintas LTO son mucho más simples de operar, pues incluyen un Sistema de Archivos para Cintas Lineales (LTFS) lo que las hace más cómodas para buscar archivos específicos. Continen una tabla de alocación, y por lo tanto operan como cualquier partición montada en nuestro sistema de archivos.