Next: Autenticación de
usuarios Up: Seguridad del sistema Previous:
Auditoría del sistema Índice General
Subsecciones
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).
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.
Tabla 7.1: Comparación de diferentes medios
de almacenamiento secundario.
| Dispositivo |
Fiabilidad |
Capacidad |
Coste/MB |
| Diskette |
Baja |
Baja |
Alto |
| CD-ROM |
Media |
Media |
Bajo |
| Disco duro |
Alta |
Media/Alta |
Medio. |
| Cinta 8mm. |
Media |
Alta |
Medio. |
| Cinta DAT |
Alta |
Alta |
Medio. |
|
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.
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:~#
Tabla 7.2: Opciones de la orden dump
| Opción |
Acción realizada |
Argumento |
| 0-9 |
Nivel de la copia de seguridad |
NO |
| u |
Actualiza /etc/dumpdates al finalizar
el backup |
NO |
| f |
Indica una cinta diferente de la usada por defecto |
SÍ |
| b |
Tamaño de bloque |
SÍ |
| c |
Indica que la cinta destino es un cartucho |
NO |
| W |
Ignora todas las opciones excepto el nivel del
backup |
NO |
|
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/c0d0s7
Si 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.
Tabla 7.3: Opciones de la orden restore
| Opción |
Acción realizada |
Argumento |
| r |
Restaura la cinta completa |
NO |
| f |
Indica el dispositivo o archivo donde está
el backup |
SÍ |
| i |
Modo interactivo |
NO |
| x |
Extrae los archivos y directorios desde el directorio
actual |
NO |
| t |
Imprime los nombres de los archivos de la cinta |
NO |
|
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 como
luisa:~# 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 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.
Tabla 7.4: Opciones de la orden tar
| Opción |
Acción realizada |
| c |
Crea un contenedor |
| x |
Extrae archivos de un contenedor |
| t |
Testea los archivos almacenados en un contenedor |
| r |
Añade archivos al final de un contenedor |
| v |
Modo verbose |
| f |
Especifica el nombre del contenedor |
| Z |
Comprime o descomprime mediante compress/uncompress |
| z |
Comprime o descomprime mediante gzip |
| p |
Conserva los permisos de los ficheros |
|
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.
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).
Tabla 7.5: Opciones de la orden cpio.
| Opción |
Acción realizada |
| o |
Copiar 'fuera' ( out) |
| i |
Copiar 'dentro' ( in) |
| m |
Conserva fecha y hora de los ficheros |
| t |
Crea tabla de contenidos |
| A |
Añade ficheros a un contenedor existente |
| v |
Modo verbose |
|
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.cpio
Como 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.cpio
Igual 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.cpio
Para 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.iso
Con 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.
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/0
Si 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 -print
Si 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 -print
Esta 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.
Notas al pie
- ... operativo8.1
- HP-UX, IRIX, SunOS, Linux...en Solaris se llama ufsdump y en AIX
backup.
Next: Autenticación de
usuarios Up: Seguridad del sistema Previous:
Auditoría del sistema Índice General