Sincronización de archivos

• Opciones avanzadas
• Sincronización con rsync
• Automatizando la sincronización

Una ley básica de la informática es que tu disco duro cascará. Puede que más tarde, puede que más temprano. Pero cascará. Y luego es cuando pensamos eso de "¿Por qué no habré hecho una copia de seguridad?" entre amargos llantos y lamentos.

Así que dado que tenemos dos ordenadores interconectados, ¿por qué no usar el disco duro de uno para albergar la copia de seguridad del disco duro del otro? Lógicamente, las copias de seguridad ocupan espacio, por lo que ambos discos estarán más llenos de lo normal. Y si uno de ellos es más pequeño que el otro, pues no todos los contenidos del disco duro grande podrán tener su copia de seguridad en el disco duro pequeño (aunque, por otra parte, no todos los contenidos del disco duro tienen por qué necesitar copia de seguridad).

Seguramente sea preferible tener un disco duro dedicado para hacer las copias de seguridad de cada ordenador (si encima ya es un RAID mejor que mejor). Pero si nuestros recursos son limitados, que cada ordenador albergue las copias de seguridad del otro puede ser una opción perfectamente válida. ¿Cómo conseguirlo? Acompáñame en las siguientes secciones para averiguarlo.

(Aunque es parte del mismo manual, no es necesario implementar el acceso al disco duro remoto para hacer copias de seguridad. Sin embargo, sí es necesario poder ejecutar aplicaciones remotas)

Opciones avanzadas

Cuando empecé a investigar cómo sincronizar archivos entre ordenadores estaba crecido. Lo quería todo.

Quería que los archivos se sincronizasen en tiempo real. Que en lugar de cada X tiempo hacer la copia de seguridad, que el sistema automáticamente copiase los archivos al ordenador remoto en cuanto se modificasen.

Pero también quería que un ordenador pudiese estar apagado. Porque claro, como ya expuse, uno de los ordenadores estará casi siempre encendido mientras que el otro lo estará con menos frecuencia. Por tanto la sincronización debía ocurrir... sólo si desde un ordenador se podía acceder al otro, y sino, llevar a cabo la sincronización de todo lo que se modificó mientras estaba innaccesible tan pronto como se volviese a encender.

Y también quería que las copias de seguridad no estuviesen en un directorio especial, sino que se replicase tal cuál la estructura de directorios de un ordenador en el otro. Vamos, que ambos ordenadores contuviesen los mismos archivos como si fuesen un único disco duro (con la excepción de los contenidos que no hacen falta guardar del disco duro grande).

Y puestos a pedir, quería que fuese fácil de usar.

Y quería un LEGO Mindstorm, pero creo que eso es de otra lista de peticiones.

Así a simple vista puede parecer que debe ser imposible cumplir todos esos requisitos. Pero estaba seguro que algo tendría que haber, ya que los clústeres y los superordenadores tienen que tener algo parecido a lo que yo quería. Y a fin de cuentas, GNU/Linux está presente en la mayoría de los clústeres y superordenadores del mundo.

Y me encontré con varios sistemas de archivos que se usan precisamente para esas cosas. Como OpenAFS. Aunque éste concretamente no me servía porque sólo parece permitir replicación de sólo lectura, sin escritura.

Entonces encontré Coda, que en ese sentido parecía estar mucho mejor. Pero tenía ciertas limitaciones que no me convencían. No creo que llegase a tener rutas de 1024 caracteres, pero fíate y no corras. No obstante, dichas limitaciones puede que ya no estén vigentes del mismo modo que antes no se podían usar clientes y servidores en la misma máquina (invalidándolo para el uso que le quiero dar) y ahora en teoría sí.

DRBD parece usar un enfoque similar a Coda aunque no igual, pero conforme leía documentación empecé a darme cuenta que todo esto era demasiado complejo y un poco excesivo.

Entonces descubrí ChironFS, que era casi casi lo que estaba buscando: RAID-1 por red. Simplemente faltaba poder excluir archivos o directorios de la copia (dado que uno de los discos duros es más grande que el otro). Sin embargo, no está empaquetado para Mandriva y no parece haber mucho desarrollo. Pero el verdadero problema es algo de lo que no me había dado cuenta hasta ahora: es horriblemente lento.

Al replicar los contenidos del disco duro por red en tiempo real cuando se guarda un archivo tiene que escribirse en el disco duro local, enviarlo por la red, y escribirlo en el disco duro remoto. Así que el tiempo que tarde la operación dependerá del eslabón más lento de la cadena. Si nuestra red es Ethernet a 100Mbps, seguramente el cuello de botella sea la red. Pero si es Gigabit Ethernet, ¡nuestro nuevo y flamante ordenador tardará tanto en guardar los datos como tarde el disco duro de nuestro ordenador viejo!

MogileFS parece ofrecer mayor granularidad que ChironFS (te permite indicar, por ejemplo, que los archivos JPEG deben estar replicados en al menos N servidores, pero que los thumbnails sólo en 1) que era lo que le faltaba, pero no es POSIX sino que se necesita acceder a dicho sistema de archivos con una biblioteca concreta, por lo que las aplicaciones corrientes no pueden usarlo. Están haciendo un módulo para FUSE que sortea ese problema, pero aún no está listo. Pero, al igual que ChironFS, sigue siendo horriblemente lento. Y así será posiblemente cualquier RAID-1 en red.

Así que me dije "vale, se me fue la mano con mis exigencias". En lugar de buscar sincronización en tiempo real, bajé el listón y pasé a investigar las opciones en el mundo de la sincronización de archivos sin más y la copias de seguridad.

Y me encontré con sistemas de backup como Bacula, Amanda, backupninja o BackupPC y sincronizadores como Unison.

Y me di cuenta de que estaba matando moscas a cañonazos. No intentaba encontrar el sistema que necesitaba, sino el que creía que necesitaba.

Al final, no hay nada como el principio KISS ("Keep it simple, stupid" = "manténlo simple, estúpido" en inglés, nada que ver con pintarse la cara de blanco y negro y vestir de cuero). Puede que haya sistemas de backup y de sincronización avanzadísimos que hagan maravillas. Pero a mí, con que cada X tiempo copie el contenido de los directorios que le diga en el disco duro del otro ordenador, me vale. Realmente no necesito ni poder acceder a los archivos tal y como estaban en cierta fecha del pasado ni que la copia sea en tiempo real ni nada.

¿Y cómo hacer la sincronización pues? Juntas rsync con un trabajo cron y listo.

Vale, vamos a explicarlo un poco más :P

Sincronización con rsync

Empecemos por rsync. Rsync es una aplicación de consola que permite copiar archivos de un lugar a otro minimizando la transferencia de datos. Como la orden cp, pero a lo bestia. Y cuando digo de un lugar a otro me refiero dentro del mismo ordenador, o en un ordenador remoto mediante SSH.

A rsync puede pasársele la lista de archivos a copiar y su destino de forma similar a cp. Además de nombres concretos, también se le pueden pasar reglas que hacen que ciertos archivos se tengan en cuenta y otros se ignoren. Por ejemplo, la regla + unDirectorioCualquiera/*** selecciona el directorio llamado unDirectorioCualquiera, sus archivos y sus subdirectorios de forma recursiva (es decir, que de los subdirectorios también se seleccionarán sus archivos y sus subdirectorios, y de estos sus archivos y sus subdirectorios, y de estos...). Pero si antes de esa regla aparece - unDirectorioCualquiera/algunSubdirectorio/***, el subdirectorio algunDirectorio de unDirectorioCualquiera se ignorará, así como sus contenidos.

Dicho de otra manera, a rsync se le pasa una lista de archivos que va comprobando y aplica la primera regla que encuentre que encaje con cada nombre del archivo/directorio. Rsync puede ampliar la lista de archivos a considerar automáticamente si, por ejemplo, le decimos que compruebe recursivamente en todos los subdirectorios de los directorios que se le indican. Así pues, si le decimos que mire recursivamente en el directorio personal del usuario, las reglas se aplicarán a todos y cada uno de los archivos y subdirectorios del directorio personal.

La lista de reglas puede pasársele explícitamente a rsync, o estar escrita en un archivo leído por rsync. Lo más práctico para el sistema de sincronización que vamos a utilizar es escribirla en un archivo. He aquí un ejemplo de archivo .backupconf (el nombre puede ser el que queramos, pero éste parece bastante descriptivo para sus objetivos ;) ):

#Similar al argumento --cvs-exclude de rsync (ignora directorios de CVS, SVN...)
#Sin embargo, hay que establecerlo aquí en lugar de llamar a rsync con él porque
#dicho argumento añade las reglas al final de la lista, por lo que no tienen el
#efecto deseado.
-C
#Ignora los directorios y archivos ocultos en el directorio base del usuario,
#pero no en otros lugares de la jerarquía de directorios. Es decir,
#/home/dani/.archivoOculto se ignora, pero no /home/dani/Fotos/.archivoOculto
- /.*
#Seleccionaría todos los archivos y directorios de forma recursiva en el
#directorio base del usuario. Y digo seleccionaría porque el primer caracter es
#una almohadilla, por lo que la línea está comentada y no tiene efecto.
#+ /***
#Selecciona el directorio Documentos y todos sus archivos y subdirectorios de
#forma recursiva. Si descomentásemos la regla anterior ésta sería superflua, ya
#que el directorio Documentos y todos sus subdirectorios estarían ya
#seleccionados
+ Documentos/***
#Ignora los archivos y subdirectorios que están en el directorio
#Fotos/Cumpleaños de Pepito (nótese que no hay que poner nada especial para los
#espacios)
- Fotos/Cumpleaños de Pepito/***
#Ignora los archivos y subdirectorios que están en el directorio Fotos/Premios,
#salvo los que están en Fotos/Premios/Yo y Fotos/Premios/Archienemigo/Ridículo
+ Fotos/Premios/Yo/***
+ Fotos/Premios/Archienemigo/Ridículo/***
- Fotos/Premios/***
#Selecciona cualquier otro archivo y subdirectorio del directorio Fotos que no
#haya sido ignorado previamente
+ Fotos/***
#Ignorar cualquier otra cosa que no haya sido ya seleccionada
- *

Bueno, ya sabemos que rsync puede copiar las cosas a otro ordenador por SSH, que puede hacerlo minimizando la transferencia de datos y que podemos pasarle una serie de reglas para que filtre qué copiar y qué ignorar. Hay que añadir además que cuando el destino de la copia contiene archivos (por ejemplo, de una sincronización previa), rsync copia los nuevos archivos y modifica los ya existentes que coincidan por nombre.

Pero, por defecto, si en el destino hay archivos que no están en el origen los deja estar. No obstante, entre los múltiples argumentos que tiene rsync tenemos uno que elimina cualquier archivo que no se encuentre entre el grupo de archivos a copiar (vamos, para que el directorio destino sea una copia idéntica del directorio origen una vez aplicadas las reglas de filtrado).

Y ahora que sabemos todo esto veamos qué orden necesitamos ejecutar para que rsync haga una copia del directorio personal del usuario en un ordenador remoto:

rsync -az --delete --filter=". $HOME/.backupconf" ~/ dani@HAL9003:~/.backup/

El argumento -a activa el "modo archivo", que activa el recorrido recursivo del directorio personal, trata los enlaces blandos como enlaces blandos, preserva permisos... Vamos, opciones interesantes para copiar un directorio completo en otro lugar.

El argumento -z activa la compresión de los datos durante la transferencia, que es independiente de la característica intrínseca de rsync de minimizar los datos transferidos. Rsync sólo copia aquello que no haya cambiado, por lo que minimiza la transferencia. Y además, con este argumento, los datos que se transmiten van comprimidos (lo que nos interesa al enviarlos por la red, aunque sea local).

El argumento --delete borra del directorio destino aquellos archivos y directorios que no estén en el origen.

El argumento --filter=". $HOME/.backupconf" hace que se lea el archivo .backupconf del directorio personal del usuario en busca de reglas a utilizar. El . al principio del filtro le indica que mezcle las reglas que utiliza rsync por defecto con las que se incluyen en el archivo indicado.

El argumento ~/ es el directorio que copiar, que es el directorio personal del usuario.

Y finalmente, el argumento dani@HAL9003:~/.backup/ es el directorio destino. Los archivos del directorio origen que pasasen el filtro se copiarán en el directorio .backup del directorio personal del usuario dani en el ordenador HAL9003. Al indicar el directorio destino de esa manera, con nombre de usuario y máquina, rsync utiliza SSH para hacer el copiado.

Nótese que los ~ se reemplazan automáticamente por el home del usuario remoto y el home del usuario local, aunque sean distintos. Curiosamente, no se puede usar en el argumento --filter, sino que hay que usar la variable de entorno (y si se usa la variable de entorno en el remoto, utilizará la del local, pudiendo fallar sin son usuarios distintos).

Un buen manual en español de rsync, y en el que se basa lo aquí expuesto, puede encontrarse en Lo hice y lo entendí | Backups con rsync.

Automatizando la sincronización

Ya vimos qué orden podemos ejecutar en una consola para hacer la copia de seguridad de nuestro directorio local en un ordenador remoto. Pero si existe algo tan seguro como que el disco duro cascará, ese algo es que si las copias de seguridad deben hacerse a mano al final dejarán de hacerse. "Mmm... ya lo haré luego" es el mantra del desastre.

Aquí es donde entra en juego cron. Cron es un demonio que se encarga de ejecutar tareas de forma periódica (cada minuto, cada hora, cada día, cada jueves a las 8:42...).

Antaño existía un asistente de Mandriva para configurar cron, pero creo que pasó a mejor vida. No obstante, KDE tiene el suyo propio (el Planificador de tareas del centro de configuración de KDE), e imagino que GNOME tenga algo parecido aunque no lo sé. No obstante, la configuración de cron es bastante sencilla incluso editando a mano su archivo de configuración.

Además, cuando la tarea a ejecutarse debe hacerse en un periodo de tiempo de los disponibles por defecto (cada hora, cada día, cada semana, cada mes, cada año) puede añadirse un script, o hacer un enlace a un script, en los directorios de scripts por defecto de cron (/etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, /etc/cron.monthly/ y /etc/cron.yearly/, respectivamente). Todos los scripts de cada directorio se ejecutan cada intervalo de tiempo indicado.

Ahora bien, los scripts sólo pueden ser añadidos por root y son ejecutados utilizando el usuario root. La programación de tareas por parte de usuarios debe hacerse mediante el planificador de KDE de forma gráfica, o bien mediante crontab. Para más información sobre crontab y su formato véase el enlace previo sobre la configuración manual de cron.

Es importante notar que si el ordenador está apagado cuando toca ejecutar una tarea de cron, cron no la ejecutará automáticamente la próxima vez que se arranque el ordenador. Por ejemplo, las tareas que están programadas para ejecución diaria por defecto se lanzan a las 4:02 de la mañana. Si los ordenadores no suelen estar ambos encendidos a la hora a la que cron va a lanzar la sincronización, tenemos un problema.

Afortunadamente, anacron está pensado justo para esta situación. La función de anacron es ejecutar aquellas tareas de cron que no hayan sido ejecutadas por estar el ordenador apagado (bueno, no es exactamente así como funciona, pero en la práctica viene a ser eso). Con instalar el paquete cronie-anacron (o anacron en Mandriva 2009.1 y anteriores), problema solucionado.

Con todo esto, podemos añadir una tarea de cron en cada usuario que necesite una copia de seguridad que ejecute la orden de rsync mostrada en el apartado anterior. Otra opción, a mi juicio más cómoda, es hacer un script que haga las copias de seguridad de todos los usuarios. Además, al ser un script tiene la ventaja de que podremos invocarlo cuando queramos, y no sólo cuando toque la tarea programada de cron.

Antes de ver el script, analicemos un poco el entorno en el que se ejecutará.

Un detalle sobre rsync que no se comentó aún pero que es importante es qué ocurre si intenta copiar algo en un ordenador remoto y éste no está disponible, deja de estar disponible de repente (por ejemplo, porque se apague el ordenador al que está copiando los datos), o el propio rsync se interrumpe de repente (por ejemplo, porque se apague el ordenador en el que se está ejecutando). He aquí una buena noticia: no pasa nada malo.

Si no está disponible, se queda intentando conectar un tiempo hasta que se rinde y muestra un mensaje de error. Si deja de estar disponible de repente, lo mismo. Y si rsync se interrumpe el envío se interrumpe sin más. Lo que llegó a copiarse, copiado está. Cuando se vuelva a ejecutar rsync copiará lo que le faltaba, y si algo de lo copiado cambió lo actualizará. Exactamente igual que si la copia anterior hubiese sido exitosa y no interrumpida.

Con todo esto, podemos planificar una tarea en el ordenador nuevo que haga copias de seguridad en el viejo, y una tarea en el viejo que haga copias de seguridad en el nuevo. Si el ordenador al que se va a copiar no está disponible o alguno de los dos se apaga durante la transferencia no ocurriría nada malo. Al menos en principio.

Pero en el entorno en el que me encuentro, con el ordenador nuevo casi siempre encendido y el viejo encendido con menos frecuencia si el ordenador nuevo planificase una sincronización de sus archivos al ordenador viejo seguramente dicha sincronización se ejecutase en el mismo momento en que estaba planificada. Pero el ordenador viejo es muy posible que estuviese apagado en ese momento.

Entonces, aunque no ocurriría nada malo (rsync intentaría conectar y desistiría al rato), el problema está en que tampoco se copiaría nada. Dado que las posibilidades de que el ordenador viejo estuviese encendido en el momento de lanzar la sincronización en el ordenador nuevo son muy reducidas, la copias de seguridad estarían tremendamente desactualizadas (y eso si llegasen a copiarse los datos alguna vez).

La sincronización lanzada desde el ordenador viejo, en cambio, no tendría mayores problemas. Gracias a anacron, si la hora estipulada de hacer la copia de seguridad hubiese pasado cuando estaba apagado, al encenderse se copiarían los archivos al ordenador nuevo. En este caso las posibilidades de que el ordenador nuevo estuviese inaccesible serían muchísimo menores, y por tanto casi siempre se copiarían los datos.

Así pues, la mejor opción es que el ordenador viejo sea quien se encargue tanto de hacer la copia de seguridad tanto hacia como desde el ordenador nuevo.

Cada usuario que realice copias de seguridad tendrá un archivo .backupconf en su directorio personal con las reglas de filtrado de archivos desde ese ordenador al otro. Por tanto, habrá un .backupconf la carpeta personal del usuario en cada ordenador. Por ejemplo, en mi sistema el archivo .backupconf del ordenador viejo hace que se copie todo el directorio personal en el ordenador nuevo. En cambio, el archivo .backupconf del ordenador nuevo ignora directorios con programas compilados y cosas así que ocupan mucho espacio y pueden regenerarse fácilmente por lo que no necesitan copia de seguridad.

Una vez sentadas las bases, vamos con el script en cuestión.

Contenido del script /usr/local/bin/backup.sh (HAL9003 y HAL9004 son los nombres de mi ordenador viejo y nuevo, respectivamente. Modifíquese como sea oportuno. Lo mismo con los usuarios indicados en users):

#!/bin/bash

users="dani greg"
for user in $users
do
    su - $user -c "ssh HAL9004 'rsync -az --delete --filter=._/home/$user/.backupconf ~/ $user@HAL9003:~/.backup/'"
    su - $user -c              "rsync -az --delete --filter=._/home/$user/.backupconf ~/ $user@HAL9004:~/.backup/"
done

En el script se incluye el nombre de los usuarios para los que debe hacerse la copia de seguridad. Para cada uno de los usuarios indicados, entra por SSH al ordenador nuevo y desde él hace una copia de seguridad de sus contenidos en el ordenador viejo. Luego, hace una copia de los contenidos del ordenador viejo en el ordenador nuevo.

El script debe ejecutarse como root para que pueda convertirse en cada uno de los usuarios para hacer la copia de seguridad. ¿Y por qué convertirse en cada uno de los usuarios y no hacer la copia como root? Pues para poder realizar las conexiones por SSH sin contraseña, ya que cada usuario puede entrar en el ordenador remoto de esa manera, y root necesitaría introducir una contraseña por cada operación de SSH (sea entrar en el ordenador nuevo, o enviar por SSH los contenidos del disco duro al ordenador nuevo).

El _ en los filtros representa un espacio en blanco. No se puede poner un espacio en blanco normal porque para ello habría que poner . /home/$user/.backupconf entre comillas, pero esos comillas anularían a las que engloban la orden ejecutada por su.

El lector atento habrá observado que aquí no se utiliza la variable de entorno $HOME en --filter. La variable de entorno no puede usarse si haces un su - usuario -c "blabla" desde root, porque sólo se ejecuta la orden, sin shell ninguno por lo que las variables no se inicializan (sino que se usan las de root).

No obstante, el anterior script tiene un problemilla, y es que hará lo que dice que va a hacer. Sí, eso puede ser un problemilla. Cuando estamos escribiendo los archivos de reglas .backupconf puede que no estemos muy seguros de qué va a copiar y qué no (al menos yo al principio no lo estaba), y sería más práctico ver qué es lo que va a hacer rsync en lugar de que lo haga realmente. Para eso está el siguiente script.

Contenido del script /usr/local/bin/checkbackup.sh:

#!/bin/bash

users="dani greg"
for user in $users
do
    su - $user -c "ssh HAL9004 'rsync -az --delete -v --dry-run --filter=._/home/$user/.backupconf ~/ $user@HAL9003:~/.backup/'"
    su - $user -c              "rsync -az --delete -v --dry-run --filter=._/home/$user/.backupconf ~/ $user@HAL9004:~/.backup/"
done

Lo único que cambia entre este script y el anterior es el uso de los argumentos -v y --dry-run de rsync. El primero muestra lo que está haciendo en lugar de hacerlo de manera silenciosa, mientras que el segundo sirve para simular las acciones, pero sin llevarlas a cabo realmente. De este modo, podemos ver qué es lo que hará el backup sin que se modifique nada.

Finalmente, una vez que ya tenemos el script listo, simplemente nos queda decirle a cron que lo ejecute periódicamente. En mi caso, considero que una vez al día es suficiente, así que enlazo al script en el directorio de tareas diarias, como root:

cd /etc/cron.daily/
ln -s /usr/local/bin/backup.sh

Para otro intervalo de tiempo consultar el ya mencionado manual sobre la configuración de cron. En cualquier caso, recuerda que debe ejecutarse como root, por lo que debe editarse el cron del sistema, no el de un usuario.

Y si todo esto te pareció muy bien, pero si no te sirve con tener una copia del disco duro y lo que necesitas es una copia de seguridad real, que guarde versiones previas del estado del disco duro en determinados momentos y demás, puede que te interese echar un vistazo a Easy Automated Snapshot-Style Backups with Linux and Rsync, o, posiblemente más fácil, al asistente de Mandriva drakbackup.