Examen de preparación 201 de LPI: Mantenimiento del sistema

Tema 211 de Intermediate Level Administration (LPIC-2)

En este tutorial, David Mertz comienza la preparación para el Examen 201 (LPIC-2) de Intermediate Level Administration® del Linux Professional Institute. En éste, el sexto de ocho tutoriales, se aprenden conceptos básicos sobre sistemas de registro, empaquetamiento de software y estrategias de copias de seguridad.

David Mertz, Developer, Gnosis Software

David MertzDavid Mertz es Turing completo, pero probablemente no apruebe la Prueba de Turing. Para conocer más acerca de su vida, consulte su página Web personal. David escribe las columnas developerWorks Charming Python y XML Matters desde el año 2000. Consulte su libro Text Processing in Python [Procesamiento de texto en Python].



28-07-2010

Antes de comenzar

Aprenda todo lo que estos tutoriales pueden enseñarle y cómo aprovecharlos al máximo.

Acerca de esta serie

El Linux Professional Institute (LPI) otorga certificaciones a administradores del sistema Linux a nivel junior e intermedio. Para obtener cada nivel de certificación, se deberán aprobar dos exámenes del LPI.

Cada examen cubre distintos temas, y cada tema tiene un valor de ponderación. Las ponderaciones indican la importancia relativa de cada tema. En términos generales, la mayor parte de las preguntas del examen suelen ser las de más alto valor de ponderación. Los temas y su ponderación para el examen LPI 201 son:

Tema 201
Kernel Linux (valor 5).
Tema 202
Inicio del sistema (valor 5).
Tema 203
Sistema de archivos (valor 10).
Tema 204
Hardware (valor 8).
Tema 209
Compartir archivos y servicios (valor 8).
Tema 211
Mantenimiento del sistema (valor 4). Tema central de este tutorial.
Tema 213
Personalización y automatización del sistema (valor 3).
Tema 214
Solución de problemas (valor 6).

El Linux Professional Institute no avala ningún material de preparación ni técnica de examen en particular por parte de terceros. Para más detalles, contáctese con info@lpi.org.

Acerca de este tutorial

Bienvenidos a "Mantenimiento del sistema," el sexto de ocho tutoriales diseñados para preparar el examen 201 del LPI. En este tutorial, se aprenden conceptos básicos sobre registros del sistema, empaquetamiento de software y estrategias de copias de seguridad.

El tutorial se organiza, de acuerdo con los objetivos del LPI para este tema, de la siguiente forma:

2.211.1 Registro del sistema (valor 1)
Se podrá configurar syslogd para que actúe como servidor central de registros en red. Este objetivo también incluye la configuración de syslogd para enviar registros de datos de salida a un servidor central de registros, registrando conexiones remotas, y utilizando grep y otras utilidades de texto, para automatizar el análisis de registros.
2.211.2 Empaquetamiento de software (valor 1)
Se podrán construir paquetes. Este objetivo incluye la construcción (o reconstrucción) del software empaquetado tanto de RPM (Red hat Package Manager – Sistema de administración e instalación de paquetes de software) como de DEB (extensión del formato de paquetes de software de Debian).
2.211.3 Operaciones de copias de seguridad (valor 2)
Se podrá diseñar un plan de almacenamiento de seguridad fuera del sitio.

Este tutorial, al igual que el correspondiente examen LPI, comprende una variedad de distintos temas que no se ajustan estrictamente a otras categorías. El registro de sistemas y el análisis de archivos de registro son tareas importantes con las cuales un administrador de sistemas se debe familiarizar. Asimismo, un sistema con buen mantenimiento debería tener una estrategia de copias de seguridad práctica usando herramientas Linux estándar.

No todos los administradores del sistema necesitarán crear paquetes de software personalizados, pero los administradores de instalaciones múltiples (y similares), necesitarán instalar todos los paquetes de software específicos del sitio o de la empresa, como parte de sus obligaciones. Este tutorial contempla los formatos de paquetes de Debian y RPM, y menciona algunos "tarballs” básicos.

Requisitos previos

Para aprovechar al máximo este tutorial, se debería contar con un conocimiento básico sobre Linux y con un sistema Linux en funcionamiento sobre el cual poder practicar los comandos contemplados en este tutorial.


Registro del sistema

Acerca de los registros

Muchos procesos y servidores bajo un sistema Linux anexan información de estado variable a "archivos de registro." Estos archivos de registro a menudo están localizados en el directorio /var/log/ y frecuentemente comienzan con una marca de tiempo indicando cuando ocurrió el evento descrito. Pero, para bien o para mal, no existe una consistencia real en cuanto al formato preciso de los archivos de registro. La única característica confiable es que los archivos de registro de Linux son simples archivos ASCII, y contienen solo un "evento" por línea de archivo. A menudo (pero no siempre) los archivos de registro contienen un conjunto, relativamente consistente, de campos de datos delimitados por espacios o por pestañas.

Algunos procesos, especialmente los servicios de Internet, controlan la escritura de los archivos de registro dentro de su propio proceso. En el fondo, escribir a un archivo de registro son solo datos anexados a un control de archivo abierto. Pero muchos programas (especialmente los daemons y los trabajos cron usan el syslog API estándar para permitir que los daemons syslogd o klogd controlen el proceso de registro específico.

Análisis de chivos de registro

La forma exacta de cómo realizar el análisis de un archivo de registro dependerá mucho del formato específico que tome. Para los archivos de registro con formato de tabla normal, herramientas tales como cortet, separe, cabeza, y cola seguramente serán útiles. Para todos los archivos de registro, grep es una excelente herramienta para hallar y filtrar contenidos de interés. Para tareas de procesamiento más complejas, probablemente se considere sed, awk, perl o python como herramientas opcionales.

Para una buena introducción a muchas de las herramientas de procesamiento de texto, que probablemente se utilicen en el proceso y análisis de archivos de registro, ver el tutorial developerWorks de IBM de David en las utilidades de procesamiento de textos GNU. También existen distintas buenas herramientas de mayor nivel para trabajar con archivos de registro, pero estas herramientas son generalmente utilidades de distribución específica y/o no estándar (pero a menudo de Software Libre).

Registrar con syslogd y klogd

El klogd daemon intercepta y registra mensajes kernel de Linux. En general, klogd utiliza las capacidades más generales de syslogd, pero en casos especiales puede registrar mensajes directamente a un archivo.

El syslogd daemon general provee registro para muchos programas. Cada mensaje registrado contiene al menos un campo de tiempo y de nombre de host y generalmente un campo de nombre del programa. El comportamiento específico del syslogd está controlado por el archivo de configuración /etc/syslog.conf. Los mensajes de aplicaciones (incluyendo los de kernel) pueden ser registrados a archivos, que generalmente se encuentran bajo /var/log/ o en forma remota sobre el socket de red.

Configuración del /etc/syslog.conf

El archivo /etc/syslog.conf contiene un conjunto de reglas, una por línea. Se deberán ignorar las líneas vacías y las líneas que comienzan con un "#". Cada regla consiste en dos campos separados por espacios en blanco, un campo selector y un campo de acción. El selector, a su vez, contiene uno de varios pares de facilidades separadas por puntos/prioritarios. Una facilidad es un subsistema que intenta registrar mensajes y puede tener valores (puede no distinguir mayúsculas de minúsculas): auth, authpriv, cron, daemon, ftp, kern, lpr, mail, mark, news, security, syslog, user, uucp y local0 hasta local7.

Las prioridades tienen un orden específico y el hecho de coincidir con una determinada prioridad significa "ésta o una más alta" a menos que se inicie con un "=" (o "!="). Las prioridades son, en orden ascendente: debug, info, notice, warning o warn, err o error, crit, alert, emerg o panic (algunos nombre tienen sinónimos). none significa que no se indica una prioridad.

Ambas facilidades y prioridades pueden aceptar el comodín "*". Hay múltiples facilidades que pueden ser separadas por una coma y múltiples selectores que pueden ser separados por un punto y coma. Por ejemplo:

# from /etc/syslog.conf # all kernel mesages kern.*
-/var/log/kern.log # `catch-all' logfile *.=info;*.=notice;*.=warn;\
auth,authpriv.none;\ cron,daemon.none;\ mail,news.none -/var/log/messages #
Emergencies are sent to everybody logged in *.emerg *

Configuración de un registro remoto

Para habilitar el registro remoto de mensajes syslogd (en realidad mensajes de aplicación controlados por syslogd), se debe primero habilitar el servicio "syslog" tanto en las máquinas de escucha como en las de envío. Para ello, se debe agregar una línea a cada archivo de configuración /etc/services que contenga algo como:

syslog 514/UDP

Para configurar el syslogd (de envío) local para que pueda enviar mensajes a un host remoto, se especifica una facilidad y una prioridad normal pero se indica una acción comenzando con un símbolo "@" para el host de destino. Un host se puede configurar de la manera habitual, ya sea con /etc/hosts o vía DNS (no se necesita tenerlo ya resuelto al momento de lanzar syslogd por primera vez). Por ejemplo:

# from /etc/syslog.conf # log all critical messages to
master.example.com *.crit @master.example.com # log all mail messages except
info level to mail.example.com mail.*;mail.!=info @mail.example.com

Rotación de archivos de registro

Frecuentemente no es deseable dejar crecer ciertos archivos de registro de forma descontrolada. La utilidad logrotate se puede utilizar para archivar información registrada con anterioridad. Usualmente, logrotate se ejecuta como un trabajo cron (programador de tareas a intervalos de tiempo predeterminados), por lo general siempre en forma diaria. logrotate permite una rotación automática, compresión, eliminación, y envío de archivos de registro. Cada archivo de registro puede ser controlado en forma diaria, semanal, mensual o sólo cuando crece de manera desmesurada.

El comportamiento de logrotate se controla mediante el archivo de configuración /etc/logrotate.conf (o algún otro archivo especificado). El archivo de configuración puede contener tanto opciones globales como opciones de archivos específicos. Generalmente, los registros archivados se guardan por un período de tiempo finito y se les da nombres de copias de seguridad secuenciales. Por ejemplo, tengo un sistema que contiene los siguientes archivos debido a su calendario de rotación.

-rw-r----- 1 root adm 4135 2005-08-10 04:00
/var/log/syslog -rw-r----- 1 root adm 6022 2005-08-09 07:36 /var/log/syslog.0
-rw-r----- 1 root adm 883 2005-08-08 07:35 /var/log/syslog.1.gz -rw-r----- 1
root adm 931 2005-08-07 07:35 /var/log/syslog.2.gz -rw-r----- 1 root adm 888
2005-08-06 07:35 /var/log/syslog.3.gz -rw-r----- 1 root adm 9494 2005-08-05
07:35 /var/log/syslog.4.gz -rw-r----- 1 root adm 8931 2005-08-04 07:35
/var/log/syslog.5.gz

Empaquetamiento de software

En el principio era el

En realidad, para distribuir software personalizado en Linux, se requiere mucho menos de lo que se cree. Linux tiene un estándar bastante claro en cuanto a la ubicación de archivos de distintos tipos e instalar software personalizado, en el fondo, no implica mucho más que ubicar los archivos correctos en el lugar correcto.

La herramienta Linux tar (que significa "tape archive [archivo de almacenamiento de cinta]" a pesar de que no necesita y generalmente no utiliza cintas) es perfectamente adecuada para crear un archivo de almacenamiento de archivos con las ubicaciones de los sistemas de archivos especificadas. Para la distribución, generalmente es deseable comprimir un archivo de almacenamiento tar con gzip (GNU ZIP) (o bzip2). Para más información sobre estas utilidades ver la sección final de este tutorial en la copia de seguridad. Generalmente se denomina a un archivo de almacenamiento comprimido tar con las extensiones .tar.gz o .tgz (o .tar.bz2).

Las primeras distribuciones Linux, y algunas de las actuales, tales como Slackware, usan simplemente tarballs como mecanismo de distribución. Para una distribución personalizada de software interno de la empresa a sistemas Linux mantenidos centralmente, continúa siendo el método más sencillo.

Formatos de archivos de almacenamiento personalizados

Muchos lenguajes de programación y otras herramientas vienen con sistemas de distribución personalizados que son neutrales entre las distribuciones Linux y, generalmente, entre sistemas operativos totalmente diferentes. Python tiene sus herramientas distutils y formatos de archivo de almacenamiento; Perl tiene archivos de almacenamiento CPAN; Java tiene archivos .jar; Ruby (lenguaje de programación) tiene gems. Muchas aplicaciones no idiomáticas tienen un sistema estándar para distribuir los complementos, u otras mejoras, también a una base de aplicación.

Si bien se puede usar perfectamente un formato de paquete como DEB o RPM para, por ejemplo, distribuir un paquete Python, en general tiene más sentido seguir los estándares de empaquetamiento de la herramienta para la cual se creó el paquete. Por supuesto, para utilidades y aplicaciones a nivel sistema o para la mayoría de las aplicaciones userland compiladas, ese estándar equivale a los estándares de empaquetamiento de distribución Linux. Pero para las herramientas personalizadas escritas en lenguajes de programación específicos, algo diferente podría promover una más simple reutilización de las herramientas en todas las distribuciones y plataformas (ya sea que los destinatarios elegidos sean usuarios internos de la empresa o externos).

Los “dos grandes” de los formatos de paquetes

Existen dos formatos de paquetes principales utilizados por las distribuciones Linux: Redhat Package Manager (RPM) y Debian (DEB). Ambas son similares en cuanto al propósito pero difieren en sus detalles. En general, los dos son un formato para un archivo de almacenamiento de archivos “mejorado”. Las mejoras aportadas por estos formatos de paquete incluyen anotaciones para números de versión, dependencias de una aplicación sobre otras aplicaciones o bibliotecas, descripciones de herramientas empaquetadas de legibilidad humana, y un mecanismo general para gestionar la instalación, actualización y desinstalación de herramientas empaquetadas.

Bajo los archivos DEB, el archivo de configuración anidado control contiene la mayor parte de los metadatos del paquete. Para los archivos RPM, el archivo spec es el que juega este rol. Todos los detalles de la creación de buenos paquetes, en cualquiera de los formatos, va más allá de este tutorial, de todas formas esbozaremos aquí los fundamentos básicos.

">¿Qué hay dentro de un archivo .deb?

Un paquete DEB se crea con la herramienta de archivos de almacenamiento, y primo de tar, ar (o mediante alguna herramienta de mayor nivel que utilice ar). Por lo tanto podemos usar ar solo para ver que hay realmente dentro de un archivo .deb file. Normalmente se usarían herramientas de mayor nivel tales como dpkg, dpkg-deb o apt-get para de hecho trabajar con un paquete DEB. Por ejemplo:

% ar tv unzip_5.51-2ubuntu1.1_i386.deb rw-r--r-- 0/0 4
Aug 1 07:23 2005 debian-binary rw-r--r-- 0/0 1007 Aug 1 07:23 2005
control.tar.gz rw-r--r-- 0/0 133475 Aug 1 07:23 2005 data.tar.gz

El archivo debian-binario simplemente contiene la versión DEB (actualmente 2.0). El tarball data.tar.gz contiene en realidad los archivos de aplicación; ejecutables, documentación, páginas del manual, archivos de configuración, etc.

El control.tar.gz tarball es el más interesante desde una perspectiva de empaquetamiento. Veamos el ejemplo de paquete DEB elegido:

% tar tvfz control.tar.gz drwxr-xr-x root/root 0
2005-08-01 07:23:43 ./ -rw-r--r-- root/root 970 2005-08-01 07:23:43 ./md5sums
-rw-r--r-- root/root 593 2005-08-01 07:23:43 ./control

Como es de esperar, md5sums contiene hashes cifrados de todos los archivos distribuidos con fines de verificación. El archivo control es do nde se aloja la metadata. En algunos casos también se podría encontrar o desear incluir scripts llamados postinst y prerm en control.tar.gz para, realizar los determinados y respectivos pasos luego de la instalación o antes de la remoción.

Creación de un archive de control DEB

Los scripts de instalación pueden hacer todo lo que podría hacer un script shell. (para hacerse una idea ver algunos ejemplos en paquetes existentes). Pero esos scritps son opcionales y, a menudo, no necesarios o incluidos. Lo que se requiere para un paquete .deb es su archivo de control. El formato de este archivo contiene varios campos de metadata que se ilustra mejor por medio de un ejemplo:

% cat control Package: unzip Version: 5.51-2ubuntu1.1
Section: utils Priority: optional Architecture: i386 Depends: libc6 (>=
2.3.2.ds1-4) Suggests: zip Conflicts: unzip-crypt (<< 5.41)
Replaces: unzip-crypt (<< 5.41) Installed-Size: 308 Maintainer:
Santiago Vila <sanvila@debian.org> Description: De-archiver for
.zip files InfoZIP's unzip program. With the exception of multi-volume archives
(ie, .ZIP files that are split across several disks using PKZIP's /&
option), this can handle any file produced either by PKZIP, or the corresponding
InfoZIP zip program. . Esta versión soporta encriptado.

Básicamente, exceptuando los valores de datos personalizados, se debería hacer que el archivo de control sea igual a éste. Para paquetes específicamente no-CPU5, ya sean scripts, documentación pura o código fuente, se debe usar Architecture: all (Arquitectura: todas).

Creación de un paquete DEB

La creación de un paquete DEB se realiza con la herramienta dpkg-deb. No se pueden cubrir todas las complejidades de un buen empaquetamiento, pero la idea básica es la de crear un directorio de trabajo, ./debian/, y agregarle los contenidos necesarios antes de ejecutar dpkg-deb. También sería deseable establecer permisos en sus archivos para que coincidan con el estado pretendido al momento de su instalación. Por ejemplo:

% mkdir -p ./debian/usr/bin/ % cp foo-util
./debian/usr/bin # copy executable/script % mkdir -p ./debian/usr/share/man/man1
% cp foo-util.1 ./debian/usr/share/man/man1 # copy the manpage % gzip --best
./debian/usr/share/man/man1/foo-util.1 % find ./debian -type d | xarg chmod 755
# set dir permissions % mkdir -p ./debian/DEBIAN % cp control ./debian/DEBIAN #
first create a matching 'control' % dpkg-deb --build debian # create the archive
% mv debian.deb foo-util_1.3-1all.deb # rename to final package name

Más sobre la creación de paquetes DEB

En el panel previo se puede observar que la estructura del directorio local debajo de ./debian/ debería coincidir con la estructura de instalación pretendida. Vale la pena tomar en cuenta algunos otros puntos con respecto a la creación de un buen paquete.

  • Generalmente se debería crear un archivo llamado ./debian/usr/share/doc/foo-util/copyright como parte de su distribución (adaptar al nombre del paquete).
  • También es de buena práctica crear los archivos ./debian/usr/share/doc/foo-util/changelog.gz y ./debian/usr/share/doc/foo-utils/changelog.Debian.gz.
  • La herramienta lintian verificará cualquier aspecto cuestionable de un paquete DEB. No es necesario rep arar absolutamente todo lo que lintian señale como cuestionable; pero si se pretende una distribución más amplia, sería bueno reparar todos los problemas que indique.
  • La herramienta fakeroot es útil para que el empaquetamiento se realice con el dueño correcto. Habitualmente el destino desea herramientas instaladas como raíz, no como el usuario individual que simplemente generó el paquete (lintian advertirá sobre esto). Esto se puede lograr con:

    % fakeroot dpkg-deb --build debian

¿Qué hay dentro de un archivo .rpm?

Cuando crea paquetes RPM adopta una estrategia ligeramente distinta a DEB. Su archivo de configuración se llama spec en vez de control, pero el archivo spec también realiza más trabajo que un archivo de control. Todos los detalles sobre los pasos previos necesarios para la instalación, los posteriores a la instalación, los previos a la eliminación y los necesarios para la instalación en sí, están contenidos como archivos script incrustados en una configuración spec. De hecho, el formato spec incluye hasta un macros para acciones comunes.

Cuando se crea un paquete RPM, se lo hace con la utilidad rpm -b. Por ejemplo:

% rpm -ba foo-util-1.3.spec # perform all build
                    steps

Este proceso de construcción de paquetes no depende de directorios con nombres específicos como es el caso de DEB, sino más bien de las directivas de un archivo spec más complejo.

Creación de metadatos RPM

Los metadatos básicas en un RPM es muy similar a la que está en un DEB. Por ejemplo, foo-util-1.3.spec podría contener algo como:

# spec file for foo-util 1.3 Summary: A utility that
fully foos Name: foo-util Version: 1.3 Release: 1 Copyright: GPL Group:
Application/Misc Source: ftp://example.com/foo-util.tgz URL:
http://example.com/about-foo.html Distribution: MyLinux Vendor: Acme Systems
Packager: John Doe <jdoe@acme.example.com> %description The
foo-util program is an advanced fooer that combines the capabilities of OneTwo's
foo-tool and those in the GPL bar-util.

Scripting en un RPM

Distintas secciones de un archivo spec RPM pueden contener mini scripts de shell. Las mismas incluyen:

  • %prep: Pasos necesarios para preparar la construcción tales como la limpieza general de construcciones anteriores (parciales). A menudo el siguiente macro es útil y suficiente:
    %prep%setup
  • %build: Pasos para la construcción en sí de la herramienta. Si se usa la facilidad make, esto podría equivaler a:
    %buildmake
  • %install: Pasos para instalar la herramienta. Nuevamente si se usa make esto podría significar:
    %installmake
                            install
  • %files: Se debet incluir un listado de archivos que sean parte del paquete. Aún cuando el Makefile pueda usar estos archivos, el programa de gestión de paquete (rpm) no se enterará a menos que se los incluya aquí:
    %files%doc README
                                /usr/bin/foo-util /usr/share/man/man1/foo-util.1

Operaciones de copias de seguridad

Acerca de copias de seguridad

La primera regla para hacer copias de seguridad es: ¡Hágalas! Es muy fácil, en la administración de servidores, o aún con Linux en el escritorio, descuidar la realización de las copias de seguridad con una determinada frecuencia adecuada a sus necesidades.

La forma más sencilla de hacer copias de seguridad en forma sistemática y programada es hacerlas en un trabajo cron. Ver en el tutorial del Tema 213 una discusión sobre la configuración de crontab. En parte, la elección de la frecuencia depende de la herramienta de copias de seguridad y del medio que se utilice para realizarlo.

Hacer copias de seguridad en cinta es una técnica tradicional y una unidad de cinta continúa ofreciendo la mayor capacidad dentro de lo que son los medios relativamente económicos. Pero, recientemente, los CDs y DVD con acceso de escritura y reescritura se han convertido en algo de uso común y con frecuencia serán un medio extraíble razonable para hacer copias de seguridad.

Que se debe guardar en las copias de seguridad

Algo positivo acerca de Linux es que usa una organización de archivos jerárquica predecible. Consecuentemente, rara vez será necesario hacer copias de seguridad de toda una jerarquía de sistemas de archivo; la mayor parte de una jerarquía de sistemas de archivos Linux puede ser reinstalada fácilmente desde un medio de distribución. En ámbitos grandes, una imagen master server se podría usar para crear un sistema básico Linux que se puede personalizar mediante la restauración de unos pocos archivos seleccionados que hayan sido guardados en copias de seguridad en alguna otra parte.

Básicamente, lo que se desea resguardar es /home/, /etc/, /usr/local/, y tal vez /root/ y /boot/. Frecuentemente también se deseará resguardar algunas partes de /var/, tales como /var/log/ y /var/mail/.

Hacer copias de seguridad con cp y scp

Quizás la forma más simple de hacer una copia de seguridad sea con cp o scp y el switch -r (recursión). Los primeros copian a medios “locales” (pero que incluyen montajes NFS), los últimos pueden copiar a servidores remotos en una forma cifrada segura. En cualquiera de los casos, se necesitará una unidad de disco montada que, por supuesto, tenga suficiente espacio para poder acomodar los archivos que se desean guardar. Para poder lograr cualquier protección real de hardware, es deseable que la partición que se copia sea un dispositivo físico distinto al de la/las unidades de disco desde las cuales se hacen las copias de seguridad.

Copiar con cp o scp puede ser parte de una frecuencia para copias de seguridad adicionales actualizadas. El truco está en usar la utilidad find para descifrar cuales archivos han sido modificados recientemente. He aquí un simple ejemplo en el que copiamos todos los archivos en /home/ que fueron modificados durante el primer día:

#!/bin/bash# File: backup-daily.sh # ++ Run this on a
daily cron job ++ #-- first make sure the target directories exist for d in
`find /home -type d` ; do mkdir -p /mnt/backup$d ; done #-- then copy all the
recently modified files (one day) for f in `find /home -mtime -1` ; do cp $f
/mnt/backup$f ; done

El indicador cp -u es bastante similar, pero depende de la continuidad del sistema de archivos en cuanto a los eventos en los que se efectúan las copias de seguridad. El enfoque de búsqueda funciona bien si se le cambia el punto de montaje de /mnt/backup a una ubicación NFS distinta. Además el sistema de búsqueda trabaja igualmente bien con scp una vez que se especifica la información de inicio de sesión necesaria al sitio remoto.

Hacer copias de seguridad con tar

A pesar de que el cp y el scp son trabajables para hacer copias de seguridad, en general se usa más tar, ya que se diseñó específicamente para crear archivos de cinta. A pesar del origen del nombre, tar (tape archive – archive de cinta) es igualmente capaz de de crear un simple archivo .tar como datos sin procesar en una unidad de cinta. Por ejemplo, se podrían hacer copias de seguridad en una cinta usando un comando como:

% tar -cvf /dev/rmt0 /home # Archive /home to
tape

Dirigir los datos de salida a un archivo, no es muy distinto de:

% tar -cvf /mnt/backup/2005-08-12.tar /home

De hecho, dado que gzip es transmisible por secuencias, se puede fácilmente comprimir un archivo durante la creación:

% tar -cv /home | gzip - >
/mnt/backup/2005-08-12.tgz

Se puede combinar tar con find usando las mismas formas indicadas para cp o scp. Para listar los archivos en una unidad de cinta, se podría usar:

% tar -tvf /dev/rmt0

Para recuperar un archivo específico:

% tar -xvf /dev/rmt0 file.name

Hacer copias de seguridad con cpio

La utilidad cpio es un superconjunto de tar. Maneja archivos tar, pero también podría trabajar con varios otros formatos y tiene muchas más opciones incorporadas. cpio viene con una gran variedad de switches para filtrar aquellos archivos que están respaldados con copias de seguridad e inclusive da soporte interno de copias de seguridad remotas (más que necesitar canalizar a través de scp o similares). La principal ventaja que cpio tiene sobre tar es que puede tanto agregar archivos a archivos de mantenimiento como eliminar archivos en retroceso.

He aquí algunos rápidos ejemplos de cpio:

  • Crear un archivo de almacenamiento en un dispositivo de cinta: % find /home -print |cpio -ocBv /dev/rmt0.
  • Listar las entradas en un archivo de almacenamiento en un dispositivo de cinta: % cpio -itcvB < /dev/rmt0.
  • Recuperar un archivo de una unidad de cinta: % cpio -icvdBum file.name < /dev/rmt0.

Hacer copias de seguridad con dump y restore

Los conjuntos de herramientas llamados dump y restore (o nombres relacionados) son, cada tanto, utilizados para hacer copias de seguridad de sistemas de archivos enteros. Lamentablemente, estas herramientas son específicas para tipos de sistemas de archivo y no están uniformemente disponibles. Por ejemplo, los dump y restore originales son ext2/3-specific mientras que las herramientas xfsdump y xfsrestore son usadas para sistemas de archivos XFS. No todo tipo de sistema de archivos tiene las herramientas equivalentes y aún si así fuera, los switches no son necesariamente uniformes.

Es bueno estar al tanto de estas utilidades, pero no son muy uniformes en todos los sistemas Linux. Para algunos propósitos, como por ejemplo si solo se usa particiones XFS, el rendimiento de dump y restore puede significar un gran avance por sobre un simple tar o cpio.

Copias de seguridad adicionales actualizadas con rsync

rsync es una utilidad que provee una rápida transferencia de archivos adicionales actualizados. Para copias de seguridad remotas automatizadas, rsync es a menudo la mejor herramienta para hacer el trabajo. Una buena característica de rsync sobre otras herramientas es que puede, en forma opcional, imponer una sincronización bidireccional. Es decir, más que simplemente hacer copias de seguridad de archivos más nuevos o modificados, también puede eliminar de forma automática archivos borrados localmente de las copias de seguridad remotas.

Para tener una idea sobre las distintas opciones, es de gran utilidad ver este ligeramente complejo script (ubicado en las páginas Web de rsync):

#!/bin/sh# This script does personal backups to a
rsync backup server. You will # end up with a 7 day rotating incremental backup.
The incrementals will # go into subdirs named after the day of the week, and the
current # full backup goes into a directory called "current" #
tridge@linuxcare.com # directory to backup BDIR=/home/$USER # excludes file -
this contains a wildcard pats of files to exclude EXCLUDES=$HOME/cron/excludes #
the name of the backup machine BSERVER=owl # your password on the backup server
export RSYNC_PASSWORD=XXXXXX BACKUPDIR=`date +%A` OPTS="--force --ignore-errors
--delete-excluded --exclude-from=$EXCLUDES --delete --backup
--backup-dir=/$BACKUPDIR -a" export PATH=$PATH:/bin:/usr/bin:/usr/local/bin #
the following line clears the last weeks incremental directory [ -d
$HOME/emptydir ] || mkdir $HOME/emptydir rsync --delete -a $HOME/emptydir/
$BSERVER::$USER/$BACKUPDIR/ rmdir $HOME/emptydir # now the actual transfer rsync
$OPTS $BDIR $BSERVER::$USER/current

Recursos

Aprender

  • En el programa LPIC encontrará listas de tareas, ejemplos de preguntas, y objetivos detallados para los tres niveles de certificación de administración de sistemas del Linux Professional Institute.
  • "Uso de utilidades de texto GNU" (developerWorks, marzo 2004) muestra cómo usar la colección de utilidades de texto GNU para procesar archivos de registro, documentación, base de datos de textos estructurados y otras fuentes en texto de datos o contenidos.
  • "Comprensión de archivos de configuración Linux" (developerWorks, diciembre 2001) explica los archivos de configuración en un sistema Linux, que controlan los permisos del usuario, las aplicaciones del sistema, los daemons, los servicios y otras tareas administrativas en un ámbito de múltiples tareas para múltiples usuarios.
  • "Windows-to-Linux roadmap: Part 8. Backup and recovery" (developerWorks, noviembre 2003) es una rápida guía a las copias de seguridad y recuperación de Linux.
  • Encuentre más recursos para desarrolladores en la zona developerWorks de Linux.

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Linux
ArticleID=502653
ArticleTitle=Examen de preparación 201 de LPI: Mantenimiento del sistema
publish-date=07282010