8.4. Información específica a Red Hat Enterprise Linux

Hay poco sobre el tópico general de desastres y su recuperación que tenga un impacto directo en cualquier sistema operativo específico. Después de todo, las computadoras en un centro de datos inundado estaran inoperativas bien sea que ejecuten Red Hat Enterprise Linux o cualquier otro sistema operativo. Sin embargo, hay partes de Red Hat Enterprise Linux que se relacionan con aspectos específicos de la recuperación de desastres; estos aspectos se discuten en esta sección.

8.4.1. Soporte de Software

Como fabricante de software Red Hat tiene varias opciones de soporte para sus productos, incluyendo Red Hat Enterprise Linux. En estos momentos usted está utilizando la herramienta más básica de soporte al leer este manual. La documentación para Red Hat Enterprise Linux está disponible en el CD de Documentación de Red Hat Enterprise Linux (el cual también se puede instalar en su sistema para un acceso rápido), en forma impresa y en el sitio web de Red Hat en http://www.redhat.com/docs/.

Las opciones de auto asistencia están disponibles a través de varias listas de correo hospedadas por Red Hat (disponibles en https://www.redhat.com/mailman/listinfo). Estas listas de correo aprovechan el conocimiento combinado de la comunidad de usuarios de Red Hat; además, muchas listas son monitorizadas por personal de Red Hat, que contribuyen cuando el tiempo se los permite. También están disponibles otros recursos desde la página principal de soporte de Red Hat en http://www.redhat.com/apps/support/.

Existen opciones de soporte más completas; se puede encontrar información sobre ellas en el sitio web de Red Hat.

8.4.2. Tecnologías de respaldo

Red Hat Enterprise Linux viene con diferentes programas para el respaldo y recuperación de datos. Por sí mismos, estos programas de utilidades no constituyen una solución de respaldo completa. Sin embargo, se pueden utilizar como el núcleo de tal situación.

NotaNota
 

Como se comentó en la Sección 8.2.6.1, la mayoría de las computadoras basadas en la arquitectura de PC estándar, no tienen la funcionalidad necesaria para arrancar directamente desde una cinta. En consecuencia, Red Hat Enterprise Linux no es capaz de realizar un arranque desde cinta cuando se esté ejecutando en hardwares de este tipo.

Sin embargo, es posible utilizar su CD-ROM de Red Hat Enterprise Linux como un ambiente de recuperación del sistema. Para más información vea el capítulo sobre recuperación básica del sistema en el Manual de administración del sistema de Red Hat Enterprise Linux.

8.4.2.1. tar

La utilidad tar es bien conocida entre los administradores UNIX. Es el método de archivado preferido para compartir bits de código fuente y archivos entre sistemas. La implementación tar incluída con Red Hat Enterprise Linux es GNU tar, una de las implementaciones de tar más ricas en funcionalidades.

Usando tar, el respaldo de los contenidos de un directorio puede ser tan simple como ejecutar un comando similar a lo siguiente:

tar cf /mnt/backup/home-backup.tar /home/

Este comando crea un fichero de archivos llamado home-backup.tar en /mnt/backup/. El fichero incluye los contenidos del directorio /home/.

El archivo resultante será casi tan grande como hacer un respaldo de los datos. Dependiendo del tipo de datos que se están respaldando, se puede también comprimir el archivo para reducir su tamaño. El archivo de respaldo se puede comprimir añadiendo una opción al comando anterior.

tar czf /mnt/backup/home-backup.tar.gz /home/

El fichero de archivos home-backup.tar.gz resultante es ahora comprimido con gzip[1].

Hay muchas otras opciones para tar; para aprender más sobre ellas, lea la página man de tar(1).

8.4.2.2. cpio

La utilidad cpio es otro programa UNIX tradicional. Es un excelente programa de propósito general para mover datos de un lugar a otro y, como tal, puede servir muy bien como un programa para hacer respaldos.

El comportamiento de cpio es ligeramente diferente a tar. A diferencia de tar, cpio lee los nombres de los archivos que va a procesar a través de la entrada estándar. Un método común para generar una lista de archivos para cpio es utilizar un programa como find cuya salida se puede entubar a cpio:

find /home/ | cpio -o > /mnt/backup/home-backup.cpio

Este comando crea un fichero de archivos cpio (que contiene todo lo que hay en /home/) llamado home-backup.cpio en el directorio /mnt/backup/.

SugerenciaSugerencia
 

Como find tiene un conjunto de pruebas de selección de archivos muy rico, se pueden realizar respaldos sofisticados. Por ejemplo, el comando siguiente realiza un respaldo solamente de los archivos que no se accesaron el año pasado.

find /home/ -atime +365 | cpio -o > /mnt/backup/home-backup.cpio
            

Hay muchas otras opciones para cpio (y find); para conocer un poco más sobre ellas, lea las páginas man de cpio(1) y de find(1).

8.4.2.3. dump/restore: Atención: No se recomienda para sistemas de archivos montados.

Los programas dump y restore son los equivalentes de Linux a los programas de UNIX con el mismo nombre. Como tales, muchos administradores de sistemas con experiencia UNIX pueden pensar que dump y restore son candidatos aceptables para un buen programa de respaldo bajo Red Hat Enterprise Linux. Sin embargo, un método de usar dump puede causar problemas. He aquí un comentario de Linus Torvald sobre este tema:

From:	 Linus Torvalds
To:	 Neil Conway
Subject: Re: [PATCH] SMP race in ext2 - metadata corruption.
Date:	 Fri, 27 Apr 2001 09:59:46 -0700 (PDT)
Cc:	 Kernel Mailing List <linux-kernel At vger Dot kernel Dot org>

[ linux-kernel added back as a cc ]

On Fri, 27 Apr 2001, Neil Conway wrote:
> > I'm surprised that dump is deprecated (by you at least ;-)).  What to
> use instead for backups on machines that can't umount disks regularly? 


Note that dump simply won't work reliably at all even in 2.4.x: the buffer
cache and the page cache (where all the actual data is) are not
coherent. This is only going to get even worse in 2.5.x, when the
directories are moved into the page cache as well.

So anybody who depends on "dump" getting backups right is already playing
Russian roulette with their backups.  It's not at all guaranteed to get the
right results - you may end up having stale data in the buffer cache that
ends up being "backed up".

Dump was a stupid program in the first place. Leave it behind.

> I've always thought "tar" was a bit undesirable (updates atimes or
> ctimes for example).

Right now, the cpio/tar/xxx solutions are definitely the best ones, and
will work on multiple filesystems (another limitation of "dump"). Whatever
problems they have, they are still better than the _guaranteed_(*)  data
corruptions of "dump".

However, it may be that in the long run it would be advantageous to have a
"filesystem maintenance interface" for doing things like backups and
defragmentation..

		Linus

(*) Dump may work fine for you a thousand times. But it _will_ fail under
the right circumstances. And there is nothing you can do about it.

Dado este problema, el uso de dump/restore en sistemas de archivos montados no se recomienda para nada. Sin embargo, dump originalmente fue diseñado para respaldar sistemas de archivos desmontados; por lo tanto, en situaciones donde es posible tomar un sistema de archivos fuera de línea con umount, dump sigue siendo una tecnología de respaldos viable.

8.4.2.4. El Advanced Maryland Automatic Network Disk Archiver (AMANDA)

AMANDA es una aplicación de respaldos basada en cliente/servidor producida por la Universidad de Maryland. Teniendo una arquitectura cliente/servidor, un simple servidor de respaldo (normalmente un sistema sustancialmente poderoso con bastante espacio libre, discos rápidos y configurado con el dispositivo de respaldo deseado) puede respaldar muchos sistemas clientes, que solamente necesitan el software cliente AMANDA.

Este enfoque hacia los respaldos tiene mucho sentido, pues concentra los recursos necesarios para los respaldos en un sistema, en vez de requerir hardware adicional para cada sistema que requiere servicios de respaldo. El diseño de AMANDA también sirve para centralizar la administración de los respaldos, haciendo más fácil la vida del administrador del sistema.

El servidor AMANDA maneja un fondo de media de respaldo y rota su uso a través de este fondo para asegurarse de que todos los respaldos son guardados por el período de retención dictado por el administrador. Toda la media está preformateada con datos que permiten a AMANDA detectar si la media adecuada está disponible o no. Además, AMANDA puede interactuar con media robótica para el cambio de unidades, haciendo posible automatizar completamente los respaldos.

AMANDA puede utilizar tar o dump para hacer los respaldos (aunque bajo Red Hat Enterprise Linux es preferible el uso de tar, debido a los problemas con dump mencionados en la Sección 8.4.2.3). Como tal, los respaldos de AMANDA no requieren AMANDA para su respaldo - una ventaja considerable.

En operación, AMANDA normalmente es planificada para ejecutarse una vez al día durante la ventana de respaldo del centro de datos. El servidor AMANDA se conecta a los sistemas clientes y los dirige a producir tamaños estimados de los respaldos a realizar. Una vez que estén disponibles todos los estimados, el servidor construye un horario, determinando automáticamente el orden en el cual se hará el respaldo de los sistemas.

Una vez que comiencen los respaldos, los datos son enviados sobre la red desde el cliente al servidor, donde son almacenados en un disco temporal. Una vez terminado el respaldo, el servidor comienza a escribirlo fuera del dico temporal a la media de respaldo. Al mismo tiempo, los otros clientes envían sus respaldos al servidor para su almacenamiento en el disco temporal. Esto resulta en una corriente contínua de datos disponibles para escritura a la media de respaldo. A medida que se escriben los respaldos a la media, se van eliminando del disco temporal del servidor.

Una vez completados todos los respaldos, se envía un correo electrónico al administrador del sistema con un informe del estado de los respaldos, haciendo la revisión fácil y rápida.

Si es necesario restaurar los datos, AMANDA contiene un programa de utilidades que permite al operador identificar el sistema de archivos, fecha y nombre(s) de archivo(s). Una vez que se hace esto, AMANDA identifica la media de respaldo correcta y luego ubica y restaura los datos deseados. Como se mencionó anteriormente, el diseño de AMANDA también hace posible restaurar los datos aún sin la asistencia de AMANDA, aunque la identificación de la media correcta sería un proceso manual y más lento.

Esta sección solamente menciona los conceptos más básicos de AMANDA. Para una investigación más profunda sobre AMANDA, comience por la página man amanda(8).

Notas

[1]

La extensión .gz se utiliza tradicionalmente para identificar que los archivos han sido comprimidos con gzip. Algunas veces .tar.gz se acorta con .tgz para mantener los nombres de archivos en un tamaño razonable.