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.
