Los contenidos pueden estar desactualizados con respecto al original
Copias de seguridad
Siguiente: Autenticación de usuarios Subir: Seguridad del sistema Anterior: Auditoría del sistema Índice General
Subsecciones
- Introducción
- Dispositivos de almacenamiento
- Algunas órdenes para realizar copias de seguridad
- Políticas de copias de seguridad
Copias de seguridad
Introducción
Las copias de seguridad del sistema son con frecuencia el único mecanismo de recuperación que poseen los administradores para restaurar una máquina que por cualquier motivo - no siempre se ha de tratar de un pirata que borra los discos - ha perdido datos. Por tanto, una correcta política para realizar, almacenar y, en caso de ser necesario, restaurar los backups es vital en la planificación de seguridad de todo sistema.Asociados a los backups suelen existir unos problemas de seguridad típicos en muchas organizaciones. Por ejemplo, uno de estos problemas es la no verificación de las copias realizadas: el administrador ha diseñado una política de copias de seguridad correcta, incluso exhaustiva en muchas ocasiones, pero nadie se encarga de verificar estas copias...hasta que es necesario restaurar ficheros de ellas. Evidentemente, cuando llega ese momento el responsable del sistema se encuentra ante un gran problema, problema que se podría haber evitado simplemente teniendo la precaución de verificar el correcto funcionamiento de los backups; por supuesto, restaurar una copia completa para comprobar que todo es correcto puede ser demasiado trabajo para los métodos habituales de operación, por lo que lo que se suele hacer es tratar de recuperar varios ficheros aleatorios del backup, asumiendo que si esta recuperación funciona, toda la copia es correcta.
Otro problema clásico de las copias de seguridad es la política de etiquetado a seguir. Son pocos los administradores que no etiquetan los dispositivos de backup, algo que evidentemente no es muy útil: si llega el momento de recuperar ficheros, el operador ha de ir cinta por cinta (o disco por disco, o CD-ROM por CD-ROM...) tratando de averiguar dónde se encuentran las últimas versiones de tales archivos. No obstante, muchos administradores siguen una política de etiquetado exhaustiva, proporcionando todo tipo de detalles sobre el contenido exacto de cada medio; esto, que en principio puede parecer una posición correcta, no lo es tanto: si por cualquier motivo un atacante consigue sustraer una cinta, no tiene que investigar mucho para conocer su contenido exacto, lo que le proporciona acceso a información muy concreta (y muy valiosa) de nuestros sistemas sin ni siquiera penetrar en ellos. La política correcta para etiquetar los backups ha de ser tal que un administrador pueda conocer la situación exacta de cada fichero, pero que no suceda lo mismo con un atacante que roba el medio de almacenamiento; esto se consigue, por ejemplo, con códigos impresos en cada etiqueta, códigos cuyo significado sea conocido por los operadores de copias de seguridad pero no por un potencial atacante.
La ubicación final de las copias de seguridad también suele ser errónea en muchos entornos; generalmente, los operadores tienden a almacenar los backups muy cerca de los sistemas, cuando no en la misma sala. Esto, que se realiza para una mayor comodidad de los técnicos y para recuperar ficheros fácilmente, es un grave error: no hay más que imaginar cualquier desastre del entorno, como un incendio o una inundación, para hacerse una idea de lo que les sucedería a los backups en esos casos. Evidentemente, se destruirían junto a los sistemas, por lo que nuestra organización perdería toda su información; no obstante, existen voces que reivindican como correcto el almacenaje de las copias de seguridad junto a los propios equipos, ya que así se consigue centralizar un poco la seguridad (protegiendo una única estancia se salvaguarda tanto las máquinas como las copias). Lo habitual en cualquier organización suele ser un término medio entre ambas aproximaciones: por ejemplo, podemos tener un juego de copias de seguridad completas en un lugar diferente a la sala de operaciones, pero protegido y aislado como esta, y un juego para uso diario en la propia sala, de forma que los operadores tengan fácil la tarea de recuperar ficheros; también podemos utilizar armarios ignífugos que requieran de ciertas combinaciones para su apertura (combinaciones que sólo determinado personal ha de conocer), si decidimos almacenar todos los backups en la misma estancia que los equipos.
Por último, >qué almacenar? Obviamente debemos realizar copias de seguridad de los archivos que sean únicos a nuestro sistema; esto suele incluir directorios como /etc/, /usr/local/ o la ubicación de los directorios de usuario (dependiendo del Unix utilizado, /export/home/, /users/, /home/...). Por supuesto, realizar una copia de seguridad de directorios como /dev/ o /proc/ no tiene ninguna utilidad, de la misma forma que no la tiene realizar backups de directorios del sistema como /bin/ o /lib/: su contenido está almacenado en la distribución original del sistema operativo (por ejemplo, los CD-ROMs que utilizamos para instalarlo).
Dispositivos de almacenamiento
Existen multitud de dispositivos diferentes donde almacenar nuestras copias de seguridad, desde un simple disco flexible hasta unidades de cinta de última generación. Evidentemente, cada uno tiene sus ventajas y sus inconvenientes, pero utilicemos el medio que utilicemos, éste ha de cumplir una norma básica: ha de ser estándar. Con toda probabilidad muchos administradores pueden presumir de poseer los streamers más modernos, con unidades de cinta del tamaño de una cajetilla de tabaco que son capaces de almacenar gigas y más gigas de información; no obstante, utilizar dispositivos de última generación para guardar los backups de nuestros sistemas puede convertirse en un problema: >qué sucede si necesitamos recuperar datos y no disponemos de esa unidad lectora tan avanzada? Imaginemos simplemente que se produce un incendio y desaparece una máquina, y con ella el dispositivo que utilizamos para realizar copias de seguridad. En esta situación, o disponemos de otra unidad idéntica a la perdida, o recuperar nuestra información va a ser algo difícil. Si en lugar de un dispositivo moderno, rápido y seguramente muy fiable, pero incompatible con el resto, hubiéramos utilizado algo más habitual (una cinta de 8mm., un CD-ROM, o incluso un disco duro) no tendríamos problemas en leerlo desde cualquier sistema Unix, sin importar el hardware sobre el que trabaja.Aquí vamos a comentar algunos de los dispositivos de copia de seguridad más utilizados hoy en día; de todos ellos (o de otros, no listados aquí) cada administrador ha de elegir el que más se adapte a sus necesidades. En la tabla 7.1 se muestra una comparativa de todos ellos.
Discos flexibles
Sí, aunque los clásicos diskettes cada día se utilicen menos, aún se pueden considerar un dispositivo donde almacenar copias de seguridad. Se trata de un medio muy barato y portable entre diferentes operativos (evidentemente, esta portabilidad existe si utilizamos el disco como un dispositivo secuencial, sin crear sistemas de ficheros). Por contra, su fiabilidad es muy baja: la información almacenada se puede borrar fácilmente si el disco se aproxima a aparatos que emiten cualquier tipo de radiación, como un teléfono móvil o un detector de metales. Además, la capacidad de almacenamiento de los floppies es muy baja, de poco más de 1 MB por unidad; esto hace que sea casi imposible utilizarlos como medio de backup de grandes cantidades de datos, restringiendo su uso a ficheros individuales.
Un diskette puede utilizarse creando en él un sistema de ficheros, montándolo bajo un directorio, y copiando en los archivos a guardar. Por ejemplo, podemos hacer un backup de nuestro fichero de claves en un disco flexible de esta forma.
luisa:~# mkfs -t ext2 /dev/fd0 mke2fs 1.14, 9-Jan-1999 for EXT2 FS 0.5b, 95/08/09 Linux ext2 filesystem format Filesystem label= 360 inodes, 1440 blocks 72 blocks (5.00%) reserved for the super user First data block=1 Block size=1024 (log=0) Fragment size=1024 (log=0) 1 block group 8192 blocks per group, 8192 fragments per group 360 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done luisa:~# mount -t ext2 /dev/fd0 /mnt/ luisa:~# cp /etc/passwd /mnt/ luisa:~# umount /mnt/ luisa:~#Si quisiéramos recuperar el archivo, no tendríamos más que montar de nuevo el diskette y copiar el fichero en su ubicación original. No obstante, este uso de los discos flexibles es minoritario; es más habitual utilizarlo como un dispositivo secuencial (como una cinta), sin crear en él sistemas de ficheros - que quizás son incompatibles entre diferentes clones de Unix - sino accediendo directamente al dispositivo. Por ejemplo, si de nuevo queremos hacer un backup de nuestro fichero de passwords, pero siguiendo este modelo de trabajo, podemos utilizar la orden tar (comentada más adelante) para conseguirlo:
luisa:~# tar cvf /dev/fd0 /etc/passwd tar: Removing leading `/' from absolute path names in the archive etc/passwd luisa:~#Para recuperar ahora el archivo guardado, volvemos a utilizar la orden tar indicando como contenedor la unidad de disco correspondiente:
luisa:~# tar xvf /dev/fd0 etc/passwd luisa:~#Discos duros
Es posible utilizar una unidad de disco duro completa (o una partición) para realizar copias de seguridad; como sucedía con los discos flexibles, podemos crear un sistema de ficheros sobre la unidad o la partición correspondiente, montarla, y copiar los ficheros que nos interese guardar en ella (o recuperarlos). De la misma forma, también podemos usar la unidad como un dispositivo secuencial y convertirlo en un contenedor tar o cpio; en este caso hemos de estar muy atentos a la hora de especificar la unidad, ya que es muy fácil equivocarse de dispositivo y machacar completamente la información de un disco completo (antes también podía suceder, pero ahora la probabilidad de error es más alta). Por ejemplo, si en lugar del nombre del dispositivo correcto (supongamos /dev/hdc) especificamos otro (como /dev/hdd), estaremos destruyendo la información guardada en este último.
Algo muy interesante en algunas situaciones es utilizar como dispositivo de copia un disco duro idéntico al que está instalado en nuestro sistema, y del que deseamos hacer el backup; en este caso es muy sencillo hacer una copia de seguridad completa. Imaginemos por ejemplo que /dev/hda y /dev/hdc son dos discos exactamente iguales; en este caso, si queremos conseguir una imagen especular del primero sobre el segundo, no tenemos más que utilizar la orden dd con los parámetros adecuados:
luisa:~# dd if=/dev/hda of=/dev/hdc bs=2048 1523+0 records in 1523+0 records out luisa:~#Cintas magnéticas
Las cintas magnéticas han sido durante años (y siguen siendo en la actualidad) el dispositivo de backup por excelencia. Las más antiguas, las cintas de nueve pistas, son las que mucha gente imagina al hablar de este medio: un elemento circular con la cinta enrollada en él; este tipo de dispositivos se utilizó durante mucho tiempo, pero en la actualidad está en desuso, ya que a pesar de su alta fiabilidad y su relativa velocidad de trabajo, la capacidad de este medio es muy limitada (de hecho, las más avanzadas son capaces de almacenar menos de 300 MB., algo que no es suficiente en la mayor parte de sistemas actuales).
Después de las cintas de 9 pistas aparecieron las cintas de un cuarto de pulgada (denominadas QIC), mucho más pequeñas en tamaño que las anteriores y con una capacidad máxima de varios Gigabytes (aunque la mayor parte de ellas almacenan menos de un Giga); se trata de cintas más baratas que las de 9 pistas, pero también más lentas. El medio ya no va descubierto, sino que va cubierto de una envoltura de plástico.
A finales de los ochenta aparece un nuevo modelo de cinta que relegó a las cintas QIC a un segundo plano y que se ha convertido en el medio más utilizado en la actualidad: se trata de las cintas de 8mm., diseñadas en su origen para almacenar vídeo. Estas cintas, del tamaño de una cassette de audio, tienen una capacidad de hasta cinco Gigabytes, lo que las hace perfectas para la mayoría de sistemas: como toda la información a salvaguardar cabe en un mismo dispositivo, el operador puede introducir la cinta en la unidad del sistema, ejecutar un sencillo shellscript, y dejar que el backup se realice durante toda la noche; al día siguiente no tiene más que verificar que no ha habido errores, retirar la cinta de la unidad, y etiquetarla correctamente antes de guardarla. De esta forma se consigue que el proceso de copia de seguridad sea sencillo y efectivo.
No obstante, este tipo de cintas tiene un grave inconveniente: como hemos dicho, originalmente estaban diseñadas para almacenar vídeo, y se basan en la misma tecnología para registrar la información. Pero con una importante diferencia ([P$^+$94]): mientras que perder unos bits de la cinta donde hemos grabado los mejores momentos de nuestra última fiesta no tiene mucha importancia, si esos mismos bits los perdemos de una cinta de backup el resto de su contenido puede resultar inservible. Es más, es probable que después de unos cuantos usos (incluidas las lecturas) la cinta se dañe irreversiblemente. Para intentar solucionar estos problemas aparecieron las cintas DAT, de 4mm., diseñadas ya en origen para almacenar datos; estos dispositivos, algo más pequeños que las cintas de 8mm. pero con una capacidad similar, son el mejor sustituto de las cintas antiguas: son mucho más resistentes que éstas, y además relativamente baratas (aunque algo más caras que las de 8mm.).
Hemos dicho que en las cintas de 8mm. (y en las de 4mm.) se pueden almacenar hasta 5 GB. de información. No obstante, algunos fabricantes anuncian capacidades de hasta 14 GB. utilizando compresión hardware, sin dejar muy claro si las cintas utilizadas son estándar o no ([Fri95]); evidentemente, esto puede llevarnos a problemas de los que antes hemos comentado: >qué sucede si necesitamos recuperar datos y no disponemos de la unidad lectora original? Es algo vital que nos aseguremos la capacidad de una fácil recuperación en caso de pérdida de nuestros datos (este es el objetivo de los backups al fin y al cabo), por lo que quizás no es conveniente utilizar esta compresión hardware a no ser que sea estrictamente necesario y no hayamos podido aplicar otra solución.
CD-ROMs
En la actualidad sólo se utilizan cintas magnéticas en equipos antiguos o a la hora de almacenar grandes cantidades de datos - del orden de Gigabytes. Hoy en día, muchas máquinas Unix poseen unidades grabadoras de CD-ROM, un hardware barato y, lo que es más importante, que utiliza dispositivos de muy bajo coste y con una capacidad de almacenamiento suficiente para muchos sistemas: con una unidad grabadora, podemos almacenar más de 650 Megabytes en un CD-ROM que cuesta menos de 150 pesetas. Por estos motivos, muchos administradores se decantan por realizar sus copias de seguridad en uno o varios CD-ROMs; esto es especialmente habitual en estaciones de trabajo o en PCs de sobremesa corriendo algún clon de Unix (Linux, Solaris o FreeBSD por regla general), donde la cantidad de datos a salvaguardar no es muy elevada y se ajusta a un par de unidades de CD, cuando no a una sola.
En el punto 7.3.4 se comenta el mecanismo para poder grabar en un CD-ROM; aunque los ejemplos que comentaremos son básicos, existen multitud de posibilidades para trabajar con este medio. Por ejemplo, podemos utilizar dispositivos CD-RW, similares a los anteriores pero que permiten borrar la información almacenada y volver a utilizar el dispositivo (algo muy útil en situaciones donde reutilizamos uno o varios juegos de copias), o utilizar medios con una mayor capacidad de almacenamiento (CD-ROMs de 80 minutos, capaces de almacenar hasta 700 MB.); también es muy útil lo que se conoce como la grabación multisesión, algo que nos va a permitir ir actualizando nuestras copias de seguridad con nuevos archivos sin perder la información que habíamos guardado previamente.
Algunas órdenes para realizar copias de seguridad
Aunque muchos clones de Unix ofrecen sus propias herramientas para realizar copias de seguridad de todo tipo (por ejemplo, tenemos mksysb y savevg/restvg en AIX, fbackup y frecover en HP-UX, bru en IRIX, fsphoto en SCO Unix, ufsdump/ufsrestore en Solaris...), casi todas estas herramientas suelen presentar un grave problema a la hora de recuperar archivos: se trata de software propietario, por lo que si queremos restaurar total o parcialmente archivos almacenados con este tipo de programas, necesitamos el propio programa para hacerlo. En determinadas situaciones, esto no es posible o es muy difícil: imaginemos un departamento que dispone de sólo una estación Silicon Graphics corriendo IRIX y pierde todos los datos de un disco, incluida la utilidad bru; si ha utilizado esta herramienta para realizar backups, necesitará otra estación con el mismo operativo para poder restaurar estas copias, lo que obviamente puede ser problemático.Por este motivo, muchos administradores utilizan herramientas estándar para realizar las copias de seguridad de sus máquinas; estas herramientas suelen ser tan simples como un shellscript que se planifica para que automáticamente haga backups utilizando órdenes como tar o cpio, programas habituales en cualquier clon de Unix y que no presentan problemas de interoperabilidad entre diferentes operativos. De esta forma, si en la estación Silicon Graphics del ejemplo anterior se hubiera utilizado tar para realizar las copias de seguridad, éstas se podrían restaurar sin problemas desde una máquina SPARC corriendo Solaris, y transferir los ficheros de nuevo a la Silicon.
dump/restore
La herramienta clásica para realizar backups en entornos Unix es desde hace años dump, que vuelca sistemas de ficheros completos (una partición o una partición virtual en los sistemas que las soportan, como Solaris); restore se utiliza para recuperar archivos de esas copias. Se trata de una utilidad disponible en la mayoría de clones del sistema operativo8.1, potente (no diremos `sencilla') y lo más importante: las copias son completamente compatibles entre Unices, de forma que por ejemplo podemos restaurar un backup realizado en IRIX en un sistema HP-UX. Además, como veremos luego, la mayor parte de las versiones de dump permiten realizar copias de seguridad sobre máquinas remotas directamente desde línea de órdenes (en el caso que la variante de nuestro sistema no lo permita, podemos utilizar rdump/rrestore) sin más que indicar el nombre de máquina precediendo al dispositivo donde se ha de realizar la copia.La sintaxis general de la orden dump es
dump opciones argumentos fs
donde `opciones' son las opciones de la copia de seguridad, `argumentos' son los argumentos de dichas opciones, y `fs' es el sistema
de ficheros a salvaguardar. Se trata de una sintaxis algo peculiar: mientras
que lo habitual en Unix es especificar cada argumento a continuación de
la opción adecuada (por ejemplo, `find . -perm 700 -type f' indica un
argumento `700' para la opción `perm' y uno `f' para `type'), en la orden dump primero especificamos toda la lista de
opciones y a continuación todos sus argumentos; no todas las opciones
necesitan un argumento, y además la lista de argumentos tiene que
corresponderse exactamente, en orden y número, con las opciones que los
necesitan (por ejemplo, si `find' tuviera una sintaxis similar, la orden
anterior se habría tecleado como `find . -perm -type 700 f'). AIX
y Linux son los únicos Unices donde la sintaxis de dump (recordemos que en el primero se denomina backup) es la habitual.
Las opciones de `dump' más utilizadas son las que se muestran en la tabla 7.2; en las páginas man de cada clon de Unix se suelen incluir recomendaciones sobre parámetros específicos para modelos de cintas determinados, por lo que como siempre es más que recomendable su consulta. Fijándonos en la tabla, podemos ver que la opción `u' actualiza el archivo /etc/dumpdates tras realizar una copia de seguridad con éxito; es conveniente que este archivo exista antes de utilizar dump por primera vez (podemos crearlo con la orden touch), ya que si no existe no se almacenará información sobre las copias de seguridad de cada sistema de ficheros (información necesaria, por ejemplo, para poder realizar backups progresivos). En este archivo dump - la propia orden lo hace, el administrador no necesita modificar el archivo a mano...y no debe hacerlo - registra información de las copias de cada sistema de archivos, su nivel, y la fecha de realización, de forma que su aspecto puede ser similar al siguiente:
anita:~# cat /etc/dumpdates /dev/dsk/c0d0s6 0 Thu Jun 22 05:34:20 CEST 2000 /dev/dsk/c0d0s7 2 Wed Jun 21 02:53:03 CEST 2000 anita:~#
El uso de dump puede ser excesivamente complejo, especialmente en sistemas antiguos donde es incluso necesario especificar la densidad de la cinta en bytes por pulgada o su longitud en pies; no obstante, hoy en día la forma más habitual de invocar a esta orden es `dump [1-9]ucf cinta fs', es decir, una copia de seguridad del sistema de ficheros recibido como argumento, de un determinado nivel y sobre la unidad de cinta especificada. Por ejemplo para realizar una copia de seguridad completa sobre la unidad de cinta /dev/rmt de la partición lógica /dev/dsk/c0d0s7, en Solaris podemos utilizar la orden siguiente (podemos ver que nos muestra mucha información sobre el progreso de nuestra copia de seguridad en cada momento):
anita:~# ufsdump 0cuf /dev/rmt /dev/dsk/c0d0s7 DUMP: Date of this level 0 dump: Thu Jun 22 10:03:28 2000 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/dsk/c0d0s7 (/export/home) to /dev/rmt DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 24523 blocks (118796KB) DUMP: Writing 63 Kilobyte records DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: level 0 dump on Thu Jun 22 10:05:31 CEST 2000 DUMP: 24550 blocks (118927KB) on 1 volume DUMP: DUMP IS DONE anita:~#Para realizar copias remotas, como hemos dicho antes, no tenemos más que anteponer el nombre del sistema donde deseemos realizar el volcado al nombre del dispositivo donde se va a almacenar, separado de éste por el carácter `:'; opcionalmente se puede indicar el nombre de usuario en el sistema remoto, separándolo del nombre de máquina por `@':
anita:~# ufsdump 0cuf toni@luisa:/dev/st0 /dev/dsk/c0d0s7Si estamos utilizando rdump, hemos de tener definido un nombre de máquina denominado
`dumphost' en nuestro archivo /etc/hosts, que será el sistema donde se almacene la copia remota. De cualquier forma (usemos dump, ufsdump o rdump), el host remoto ha de considerarnos como una máquina de confianza (a través de /etc/hosts.equiv o .rhosts), con las consideraciones de seguridad que esto implica.
>Cómo restaurar los backups realizados con dump? Para esta tarea se utiliza la utilidad restore (ufsrestore en Solaris), capaz de extraer ficheros individuales, directorios o sistemas de archivos completos. La sintaxis de esta orden es
restore opciones argumentos archivos
donde `opciones' y `argumentos' tienen una forma similar a
`dump' (es decir, toda la lista de opciones seguida de toda la lista de
argumentos de las mismas, excepto en AIX y Linux, donde la notación es la
habitual), y `archivos' evidentemente representa una
lista de directorios y ficheros para restaurar. En la tabla 7.3
se muestra un resumen de las opciones más utilizadas.
Por ejemplo, imaginemos que deseamos restaurar varios archivos de un backup guardado en el fichero `backup'; en primer lugar podemos consultar el contenido de la cinta con una orden como la siguiente (en Linux):
luisa:~# restore -t -f backup>contenido
Level 0 dump of /home on luisa:/dev/hda3
Label: none
luisa:~# cat contenido|more
Dump date: Fri Jun 23 06:01:26 2000
Dumped from: the epoch
2 .
11 ./lost+found
30761 ./lost+found/#30761
30762 ./lost+found/#30762
30763 ./lost+found/#30763
30764 ./lost+found/#30764
30765 ./lost+found/#30765
30766 ./lost+found/#30766
30767 ./lost+found/#30767
4097 ./ftp
8193 ./ftp/bin
8194 ./ftp/bin/compress
8195 ./ftp/bin/cpio
8196 ./ftp/bin/gzip
8197 ./ftp/bin/ls
8198 ./ftp/bin/sh
8199 ./ftp/bin/tar
8200 ./ftp/bin/zcat
12289 ./ftp/etc
12290 ./ftp/etc/group
Broken pipe
luisa:~#
Una vez que conocemos el contenido de la copia de seguridad - y por tanto el
nombre del archivo o archivos a restaurar - podemos extraer el fichero que nos
interese con una orden comoluisa:~# restore -x -f backup ./ftp/bin/tar You have not read any tapes yet. Unless you know which volume your file(s) are on you should start with the last volume and work towards the first. Specify next volume #: 1 set owner/mode for '.'? [yn] n luisa:~# ls -l ftp/bin/tar ---x--x--x 1 root root 110668 Mar 21 1999 ftp/bin/tar luisa:~#Como podemos ver, la extracción se ha realizado a partir del directorio de trabajo actual; si quisiéramos extraer archivos en su ubicación original deberíamos hacerlo desde el directorio adecuado, o, en algunas versiones de restore, especificar dicho directorio en la línea de órdenes.
Una opción muy interesante ofrecida por restore es la posibilidad de trabajar en modo interactivo, mediante la opción `i'; en este modo, al usuario se le ofrece un prompt desde el cual puede, por ejemplo, listar el contenido de una cinta, cambiar de directorio de trabajo o extraer archivos. El siguiente ejemplo (también sobre Linux) ilustra esta opción:
luisa:~# restore -i -f backup
restore > help
Available commands are:
ls [arg] - list directory
cd arg - change directory
pwd - print current directory
add [arg] - add `arg' to list of files to be extracted
delete [arg] - delete `arg' from list of files to be extracted
extract - extract requested files
setmodes - set modes of requested directories
quit - immediately exit program
what - list dump header information
verbose - toggle verbose flag (useful with ``ls'')
help or `?' - print this list
If no `arg' is supplied, the current directory is used
restore > ls
.:
ftp/ httpd/ httpsd/ lost+found/ samba/ toni/
restore > add httpd
restore > extract
You have not read any tapes yet.
Unless you know which volume your file(s) are on you should start
with the last volume and work towards the first.
Specify next volume #: 1
set owner/mode for '.'? [yn] n
restore > quit
luisa:~#
Como podemos ver, hemos consultado el contenido de la copia de seguridad,
añadido el directorio httpd/ a la lista de ficheros a extraer
(inicialmente vacia), y extraído dicho directorio a partir del actual.
Este uso de restore proporciona una gran comodidad y facilidad de uso, ya
que las órdenes en modo interactivo son muy sencillas.
La orden tar
La utilidad tar (Tape Archiver) es una herramienta de fácil manejo disponible en todas las versiones de Unix que permite volcar ficheros individuales o directorios completos en un único fichero; inicialmente fué diseñada para crear archivos de cinta (esto es, para transferir archivos de un disco a una cinta magnética y viceversa), aunque en la actualidad casi todas sus versiones pueden utilizarse para copiar a cualquier dipositivo o fichero, denominado `contenedor'. Su principal desventaja es que, bajo ciertas condiciones, si falla una porción del medio (por ejemplo, una cinta) se puede perder toda la copia de seguridad; además, tar no es capaz de realizar por sí mismo más que copias de seguridad completas, por lo que hace falta un poco de programación shellscripts para realizar copias progresivas o diferenciales.En la tabla 7.4 se muestran las opciones de tar más habituales; algunas de ellas no están disponibles en todas las versiones de tar, por lo que es recomendable consultar la página del manual de esta orden antes de utilizarla. Si la implementación de tar que existe en nuestro sistema no se ajusta a nuestras necesidades, siempre podemos utilizar la versión de GNU (http://www.gnu.org/), quizás la más completa hoy en día.
|
En primer lugar debemos saber cómo crear contenedores con los archivos deseados; por ejemplo, imaginemos que deseamos volcar todo el directorio /export/home/ a la unidad de cinta /dev/rmt/0. Esto lo conseguimos con la siguiente orden:
anita:~# tar cvf /dev/rmt/0 /export/home/Como podemos ver, estamos especificando juntas las diferentes opciones necesarias para hacer la copia de seguridad de los directorios de usuario; la opción `v' no sería necesaria, pero es útil para ver un listado de lo que estamos almacenando en la cinta. En muchas situaciones también resulta útil comprimir la información guardada (tar no comprime, sólo empaqueta); esto lo conseguiríamos con las opciones `cvzf'.
Si en lugar de (o aparte de) un único directorio con todos sus ficheros y subdirectorios quisiéramos especificar múltiples archivos (o directorios), podemos indicárselos uno a uno a tar en la línea de comandos; así mismo, podemos indicar un nombre de archivo contenedor en lugar de un dispositivo. Por ejemplo, la siguiente orden creará el fichero /tmp/backup.tar, que contendrá /etc/passwd y /etc/hosts*:
anita:~# tar cvf /tmp/backup.tar /etc/passwd /etc/hosts* tar: Removing leading `/' from absolute path names in the archive etc/passwd etc/hosts etc/hosts.allow etc/hosts.deny etc/hosts.equiv anita:~#Una vez creado el contenedor podemos testear su contenido con la opción `t' para comprobar la integridad del archivo, y también para ver qué ficheros se encuentran en su interior:
anita:~# tar tvf /tmp/backup.tar -rw-r--r-- root/other 965 2000-03-11 03:41 etc/passwd -rw-r--r-- root/other 704 2000-03-14 00:56 etc/hosts -rw-r--r-- root/other 449 2000-02-17 01:48 etc/hosts.allow -rw-r--r-- root/other 305 1998-04-18 07:05 etc/hosts.deny -rw-r--r-- root/other 313 1994-03-16 03:30 etc/hosts.equiv -rw-r--r-- root/other 345 1999-10-13 03:31 etc/hosts.lpd anita:~#Si lo que queremos es recuperar ficheros guardados en un contenedor utilizaremos las opciones `xvf' (o `xvzf' si hemos utilizado compresión con gzip a la hora de crearlo). Podemos indicar el archivo o archivos que queremos extraer; si no lo hacemos, se extraerán todos:
anita:~# tar xvf /tmp/backup.tar etc/passwd etc/passwd anita:~# tar xvf /tmp/backup.tar etc/passwd etc/hosts etc/hosts.allow etc/hosts.deny etc/hosts.equiv etc/hosts.lpd anita:~#La restauración se habrá realizado desde el directorio de trabajo, creando en él un subdirectorio etc con los ficheros correspondientes en su interior. Si queremos que los ficheros del contenedor sobreescriban a los que ya existen en el sistema hemos de desempaquetarlo en el directorio adecuado, en este caso el raíz.
La orden cpio
cpio (Copy In/Out) es una utilidad que permite copiar archivos a o desde un contenedor cpio, que no es más que un fichero que almacena otros archivos e información sobre ellos (permisos, nombres, propietario...). Este contenedor puede ser un disco, otro archivo, una cinta o incluso una tubería, mientras que los ficheros a copiar pueden ser archivos normales, pero también dispositivos o sistemas de ficheros completos.En la tabla 7.5 se muestran las opciones de cpio más utilizadas; la sintaxis de esta orden es bastante más confusa que la de tar debido a la interpretación de lo que cpio entiende por `dentro' y `fuera': copiar `fuera' es generar un contenedor en salida estándar (que con toda probabilidad desearemos redireccionar), mientras que copiar `dentro' es lo contrario, es decir, extraer archivos de la entrada estándar (también es seguro que deberemos redireccionarla).
Por ejemplo, si deseamos copiar los archivos de /export/home/ en el fichero contenedor
/tmp/backup.cpio podemos utilizar la siguiente sintaxis:
anita:~# find /export/home/ |cpio -o > /tmp/backup.cpioComo podemos ver, cpio lee la entrada estándar esperando los nombres de ficheros a guardar, por lo que es conveniente utilizarlo tras una tubería pasándole esos nombres de archivo. Además, hemos de redirigir su salida al nombre que queramos asignarle al contenedor, ya que de lo contrario se mostraría el resultado en salida estándar (lo que evidentemente no es muy utilizado para realizar backups). Podemos fijarnos también en que estamos usando la orden `find' en lugar de un simple `ls': esto es debido a que `ls' mostraría sólo el nombre de cada fichero (por ejemplo, `passwd') en lugar de su ruta completa (`/etc/passwd'), por lo que cpio buscaría dichos ficheros a partir del directorio actual.
Una vez creado el fichero contenedor quizás resulte interesante chequear su contenido, con la opción `t'. Por ejemplo, la siguiente orden mostrará en pantalla el contenido de /tmp/backup.cpio:
anita:~# cpio -t < /tmp/backup.cpioIgual que para almacenar ficheros en un contenedor hemos de pasarle a cpio la ruta de los mismos, para extraerlos hemos de hacer lo mismo; si no indicamos lo contrario, cpio -i extraerá todos los archivos de un contenedor, pero si sólo nos interesan algunos de ellos podemos especificar su nombre de la siguiente forma:
anita:~# echo "/export/home/toni/hola.tex" |cpio -i </tmp/backup.cpioPara conocer más profundamente el funcionamiento de cpio, así como opciones propias de cada implementación, es indispensable consultar la página del manual de esta orden en cada clon de Unix donde vayamos a utilizarla.
Backups sobre CD-ROM
Como antes hemos dicho, cada vez es más común que se realicen copias de
seguridad sobre discos compactos; en estos casos no se suelen utilizar las
aplicaciones vistas hasta ahora (tar o cpio), sino que se necesita
un software dedicado: aquí vamos a comentar las nociones
más básicas para poder crear backups sobre este medio.
Para poder grabar una copia de seguridad en un CD-ROM necesitamos en primer
lugar que el núcleo del sistema operativo reconozca nuestra grabadora como
tal; si se trata
de una IDE, y dependiendo del clon de Unix utilizado, quizás sea necesario
modificar el kernel, ya que el acceso que los diferentes programas
realizan al dispositivo se efectua a través de un interfaz SCSI del núcleo.
Es necesario consultar la documentación y la lista de compatibilidad hardware para cada Unix particular.
Si asumimos que el reconocimiento del dispositivo es correcto, lo que necesitamos a continuación es software capaz de grabar un CD-ROM. Por un lado es necesario un programa para crear imágenes ISO, el `molde' de lo que será el futuro CD-ROM; el más conocido es sin duda mkisofs. Además necesitaremos un programa para realizar lo que es la grabación en sí, como cdrecord. De esta forma lo primero que generaremos es una imagen de los ficheros a grabar, imagen que a continuación pasaremos al CD-ROM; por ejemplo, si queremos hacer un backup de /export/home/, en primer lugar utilizaremos mkisofs para crear una imagen con todos los ficheros y subdirectorios de los usuarios:
anita:~# mkisofs -a -R -l -o /mnt/imagen.iso /export/home/Con esta orden hemos creado una imagen ISO denominada /mnt/imagen.iso y que contiene toda la estructura de directorios por debajo de /export/home/; con las diferentes opciones hemos indicado que se almacenen todos los ficheros, que se sigan los enlaces simbólicos y que se registre además información sobre los permisos de cada archivo. Una vez que tenemos esta imagen (que en los Unices con soporte para sistemas de ficheros loop podremos montar como si se tratara de una partición, para añadir, borrar, modificar...ficheros antes de la grabación) hemos de pasarla a un CD-ROM, por ejemplo mediante cdrecord:
anita:~# cdrecord dev=0,1,0 fs=16m /mnt/imagen.isoCon esta orden le hemos indicado al sistema la ubicación de nuestra grabadora, así como un buffer de grabación de 16MB y también la ubicación de la imagen ISO.
Algo muy interesante es la posibilidad de grabar sin necesidad de crear primero imágenes con los ficheros que queremos meter en un CD-ROM; esto nos ahorrará tiempo (y sobre todo, espacio en disco) a la hora de realizar copias de seguridad, además de permitir una mayor automatización del proceso. Para ello, debemos calcular con mkisofs el espacio que ocupan los ficheros a grabar (con la opción `-print-size'), y posteriormente pasarle este valor a cdrecord; podemos hacerlo de forma automática, por ejemplo tal y como muestra el siguiente programa:
anita:~# cat `which graba-cd`
#!/bin/sh
# Vuelca el directorio pasado como parametro, y todos sus descendientes,
# en un CD-ROM
MKISOFS=/usr/local/bin/mkisofs
CDRECORD=/usr/local/bin/cdrecord
if (test $# -lt 1); then
echo "Usage: $0 /files"
exit
fi
size=`$MKISOFS -r -J -l -print-size -f $1 2>&1|tail -1|awk '{print $8}'`
nice --20 $MKISOFS -r -J -l -f $1 | nice --20 $CDRECORD dev=0,1,0 fs=16m\
tsize=$size*2048 -eject -
anita:~#
Como vemos, se asigna el tamaño de los datos a grabar a la variable `size', y después se pasa este número a cdrecord; de esta forma,
para
realizar una copia de seguridad de un directorio como /export/home/toni/,
no tenemos más que ejecutar el shellscript pasándole el nombre de
este directorio como parámetro.
Políticas de copias de seguridad
La forma más elemental de realizar una copia de seguridad consiste simplemente en volcar los archivos a salvaguardar a un dispositivo de backup, con el procedimiento que sea; por ejemplo, si deseamos guardar todo el contenido del directorio /export/home/, podemos empaquetarlo en un archivo, comprimirlo y a continuación almacenarlo en una cinta:anita:~# tar cf backup.tar /export/home/ anita:~# compress backup.tar anita:~# dd if=backup.tar.Z of=/dev/rmt/0Si en lugar de una cinta quisiéramos utilizar otro disco duro, por ejemplo montado en /mnt/, podemos simplemente copiar los ficheros deseados:
anita:~# cp -rp /export/home/ /mnt/Esta forma de realizar backups volcando en el dispositivo de copia los archivos o directorios deseados se denomina copia de seguridad completa o de nivel 0. Unix utiliza el concepto de nivel de copia de seguridad para distinguir diferentes tipos de backups: una copia de cierto nivel almacena los archivos modificados desde el último backup de nivel inferior. Así, las copias completas son, por definición, las de nivel 0; las copias de nivel 1 guardan los archivos modificados desde la última copia de nivel 0 (es decir, desde el último backup completo), mientras que las de nivel 2 guardan los archivos modificados desde la última copia de nivel 1, y así sucesivamente (en realidad, el nivel máximo utilizado en la práctica es el 2).
Como hemos dicho, las copias completas constituyen la política más básica para realizar backups, y como todas las políticas tiene ventajas e inconvenientes; la principal ventaja de las copias completas es su facilidad de realización y, dependiendo del mecanismo utilizado, la facilidad que ofrecen para restaurar ficheros en algunas situaciones: si nos hemos limitado a copiar una serie de directorios a otro disco y necesitamos restaurar cierto archivo, no tenemos más que montar el disco de backup y copiar el fichero solicitado a su ubicación original.
Sin embargo, las copias completas presentan graves inconvenientes; uno de ellos es la dificultad para restaurar ficheros si utilizamos múltiples dispositivos de copia de seguridad (por ejemplo, varias cintas). Otro inconveniente, más importante, de las copias de nivel 0 es la cantidad de recursos que consumen, tanto en tiempo como en hardware; para solucionar el problema de la cantidad de recursos utilizados aparece el concepto de copia de seguridad incremental. Un backup incremental o progresivo consiste en copiar sólamente los archivos que han cambiado desde la realización de otra copia (incremental o total). Por ejemplo, si hace una semana realizamos un backup de nivel 0 en nuestro sistema y deseamos una copia incremental con respecto a él, hemos de guardar los ficheros modificados en los últimos siete días (copia de nivel 1); podemos localizar estos ficheros con la orden find:
anita:~# find /export/home/ -mtime 7 -printSi hace un día ya realizamos una copia incremental y ahora queremos hacer otra copia progresiva con respecto a ella, hemos de almacenar únicamente los archivos modificados en las últimas 24 horas (copia de nivel 2); como antes, podemos utilizar find para localizar los archivos modificados en este intervalo de tiempo:
anita:~# find /export/home/ -mtime 1 -printEsta política de realizar copias de seguridad sobre la última progresiva se denomina de copia de seguridad diferencial.
La principal ventaja de las copias progresivas es que requieren menos tiempo para ser realizadas y menos capacidad de almacenamiento que las completas; sin embargo, como desventajas tenemos que la restauración de ficheros puede ser más compleja que con las copias de nivel 0, y también que un solo fallo en uno de los dispositivos de almacenamiento puede provocar la pérdida de gran cantidad de archivos; para restaurar completamente un sistema, debemos restaurar la copia más reciente de cada nivel, en orden, comenzando por la de nivel 0. De esta forma, parece lógico que la estrategia seguida sea un término medio entre las vistas aquí, una política de copias de seguridad que mezcle el enfoque completo y el progresivo: una estrategia muy habitual, tanto por su simpleza como porque no requiere mucho hardware consiste en realizar periódicamente copias de seguridad de nivel 0, y entre ellas realizar ciertas copias progresivas de nivel 1. Por ejemplo, imaginemos un departamento que decide realizar cada domingo una copia de seguridad completa de sus directorios de usuario y de /etc/, y una progresiva sobre ella, pero sólo de los directorios de usuario, cada día lectivo de la semana. Un shellscript que realize esta tarea puede ser el siguiente:
#!/bin/sh
DIA=`date +%a` # Dia de la semana
DIREC="/tmp/backup/" # Un directorio para hacer el backup
hazback () {
cd $DIREC
tar cf backup.tar $FILES
compress backup.tar
dd if=backup.tar.Z of=/dev/rmt/0
rm -f backup.tar.Z
}
if [ ! -d $DIREC ];
then
# No existe $DIREC
mkdir -p $DIREC
chmod 700 $DIREC # Por seguridad
else
rm -rf $DIREC
mkdir -p $DIREC
chmod 700 $DIREC
fi;
case $DIA in
"Mon")
# Lunes, progresiva
FILES=`find /export/home/ -mtime 1 -print`
hazback
;;
"Tue")
# Martes, progresiva
FILES=`find /export/home/ -mtime 2 -print`
hazback
;;
"Wed")
# Miercoles, progresiva
FILES=`find /export/home/ -mtime 3 -print`
hazback
;;
"Thu")
# Jueves, progresiva
FILES=`find /export/home/ -mtime 4 -print`
hazback
;;
"Fri")
# Viernes, progresiva
FILES=`find /export/home/ -mtime 5 -print`
hazback
;;
"Sat")
# Sabado, descansamos...
;;
"Sun")
# Domingo, copia completa de /export/home y /etc
FILES="/export/home/ /etc/"
hazback
;;
esac
Este programa determina el día de la semana y en función de él realiza
- o no, si es sábado - una copia de los ficheros correspondientes (nótese
el uso de las comillas inversas en la orden find). Podríamos
automatizarlo mediante la facilidad cron de nuestro sistema para que
se ejecute, por ejemplo, cada día a las tres del mediodía (una hora
en la que la actividad del sistema no será muy alta); de esta forma, como
administradores, sólo deberíamos preocuparnos por cambiar las cintas
cada día, y dejar una preparada para el fin de semana. Si decidimos
planificarlo para que se ejecute de madrugada, hemos de tener en cuenta que el
backup de un lunes de madrugada, antes de llegar al trabajo, puede
sobreescribir el completo, realizado el domingo de madrugada, por lo que
habría que modificar el shellscript; también hemos de estar atentos
a situaciones inesperadas, como que no existan archivos a copiar o que nuestro
sistema no disponga del suficiente disco duro para almacenar temporalmente la
copia.
El medio de almacenamiento también es importante a la hora de diseñar una política de copias de seguridad correcta. Si se trata de dispositivos baratos, como los CD-ROMs, no suele haber muchos problemas: para cada volcado (sea del tipo que sea) se utiliza una unidad diferente, unidad que además no se suele volver a utilizar a no ser que se necesite recuperar los datos; el uso de unidades regrabables en este caso es minoritario y poco recomendable, por lo que no vamos a entrar en él. No obstante, algo muy diferente son los medios de almacenamiento más caros, generalmente las cintas magnéticas; al ser ahora el precio algo a tener más en cuenta, lo habitual es reutilizar unidades, sobreescribir las copias de seguridad más antiguas con otras más actualizadas. Esto puede llegar a convertirse en un grave problema si por cualquier motivo reutilizamos cintas de las que necesitamos recuperar información; aparte del desgaste físico del medio, podemos llegar a extremos en los que se pierda toda la información guardada: imaginemos, por ejemplo, que sólo utilizamos una cinta de 8mm. para crear backups del sistema: aunque habitualmente todo funcione correctamente (se cumple de forma estricta la política de copias, se verifican, se almacenan en un lugar seguro...), puede darse el caso de que durante el proceso de copia se produzca un incendio en la sala de operaciones, incendio que destruirá tanto nuestro sistema como la cinta donde guardamos su backup, con lo que habremos perdido toda nuestra información. Aunque este es un ejemplo quizás algo extremo, podemos pensar en lugares donde se utilicen de forma incorrecta varios juegos de copias o en situaciones en las que el sistema se corrompe (no ha de tratarse necesariamente de algo tan poco frecuente como un incendio, sino que se puede tratar de un simple corte de fluido eléctrico que dañe los discos); debemos asegurarnos siempre de que podremos recuperar con una probabilidad alta la última copia de seguridad realizada sobre cada archivo importante de nuestro sistema, especialmente sobre las bases de datos.
Siguiente: Autenticación de usuarios Subir: Seguridad del sistema Anterior: Auditoría del sistema Índice General 2002-07-15
