Sincronización de directorios remotos y locales con Unison

Venga, otro post de estos técnicos que tanto os gustan… muchos de vosotros conoceréis rsync, pero tiene la pega que es unidireccional, pero por suerte existe el unison, tiene una versión de consola y una versión gtk y es multiplataforma.

Ahora mismo nos vamos a centrar en el entorno de consola (¡yo administro servidores sin ratón!), además de que es super simple y sólo cabe comentar un par de cosas.

Lo primero será instalar unison a las máquinas que queramos tener los directorios sincronizados.

# apt-get install unison

En la prueba estamos usando una maquina con Debian Lenny (stable) y otra con Debian Squeeze (testing) y las versiones de unison son distintas. Uno de los requisitos para hacer la sincronización satisfactoriamente es que ambos unison usen la misma versión. (Lenny trabaja con la versión 2.27.57 y Squeeze con la versión 2.32.52).

Para ello dejaremos la versión mas baja.

# cd ~/bin
# wget -c http://ftp.us.debian.org/debian/pool/main/u/unison/unison_2.27.57-1+b1_i386.deb
# dpkg -i unison_2.27.57-1+b1_i386.deb

Una cosa a comentar es que si tienen que ser iguales las versiones, pero no hace falta que la arquitectura sea la misma (estamos con una i386 vs una x86_64).

A continuación para hacer las pruebas hemos usado dos directorios

En el servidor: /home/blackhold/test/
En la maquina replicada: /home/laura/Desktop/test/

Y hemos creado un fichero de texto en el servidor para ver qué pasa.

server# cd /home/blackhold/test/
server# vi hola.txt
hola1

A continuación hacemos la sincronización (yo lo he hecho desde la maquina replicada, aunque podría ser desde el servidor):

replicada# unison ssh://192.168.1.21//home/blackhold/test /home/laura/Desktop/test -auto
Contacting server…
root@192.168.1.21’s password:
Connected [//salnitre//home/laura/Desktop/test -> //vonneuman//home/blackhold/test]
Looking for changes
Warning: No archive files were found for these roots, whose canonical names are:
//vonneuman//home/blackhold/test
/home/laura/Desktop/test
This can happen either
because this is the first time you have synchronized these roots,
or because you have upgraded Unison to a new version with a different
archive format.

Update detection may take a while on this run if the replicas are
large.

Unison will assume that the ‘last synchronized state’ of both replicas
was completely empty.  This means that any files that are different
will be reported as conflicts, and any files that exist only on one
replica will be judged as new and propagated to the other replica.
If the two replicas are identical, then no changes will be reported.

If you see this message repeatedly, it may be because one of your machines
is getting its address from DHCP, which is causing its host name to change
between synchronizations.  See the documentation for the UNISONLOCALHOSTNAME
environment variable for advice on how to correct this.

Donations to the Unison project are gratefully accepted:
http://www.cis.upenn.edu/~bcpierce/unison

Press return to continue.[<spc>]   Waiting for changes from server
Reconciling changes

vonneuman      local
file     —->            hola.txt

Proceed with propagating updates? [] y
Propagating updates

UNISON 2.27.57 started propagating changes at 21:13:38 on 30 Mar 2010
[BGN] Copying hola.txt from //vonneuman//home/blackhold/test to /home/laura/Desktop/test
[END] Copying hola.txt
UNISON 2.27.57 finished propagating changes at 21:13:38 on 30 Mar 2010

Saving synchronizer state
Synchronization complete  (1 item transferred, 0 skipped, 0 failures)

Vale, chorro de texto, para que no ocurra esto la proxima vez vamos a usar el modo -batch que suelta menos mierda ;)

Esto lo que ha hecho ha sido actualizar ambos directorios comprobando las fechas de cada uno de ellos y salvando los ficheros mas nuevos.

Venga, mas, ahora modifico el fichero de la replica y a ver qué pasa:

salnitre:/home/laura/Desktop/test# unison ssh://192.168.1.21//home/blackhold/test /home/laura/Desktop/test -auto -batch
Contacting server…
root@192.168.1.21’s password:
Connected [//salnitre//home/laura/Desktop/test -> //vonneuman//home/blackhold/test]
Looking for changes
Waiting for changes from server
Reconciling changes
<—- changed    hola.txt
Propagating updates
UNISON 2.27.57 started propagating changes at 21:14:13 on 30 Mar 2010
[BGN] Updating file hola.txt from /home/laura/Desktop/test to //vonneuman//home/blackhold/test
[END] Updating file hola.txt
UNISON 2.27.57 finished propagating changes at 21:14:13 on 30 Mar 2010
Saving synchronizer state
Synchronization complete  (1 item transferred, 0 skipped, 0 failures)

Si modificamos el del server y ejecutamos el comando otra vez, se copiará el fichero mas nuevo sobre el fichero mas antiguo.

Pero ¿que pasa si dos ficheros se modifican desde ambos lados entre sincronización y sincronización?

salnitre:/home/laura/Desktop/test# unison ssh://192.168.1.21//home/blackhold/test /home/laura/Desktop/test -auto -batch
Contacting server…
root@192.168.1.21’s password:
Connected [//salnitre//home/laura/Desktop/test -> //vonneuman//home/blackhold/test]
Looking for changes
Waiting for changes from server
Reconciling changes
changed  <-?-> changed    hola.txt
vonneuman    : changed file       modified on 2010-03-30 at 21:14:26  size 18        rw-r–r–
local        : changed file       modified on 2010-03-30 at 21:14:40  size 21        rw-r–r–
No updates to propagate

Unison tiene como una especie de registro de los ultimos ficheros sincronizados, si ocurre esto nos avisa y mediante un poco de bash scripting podemos localizar estos ficheros modificados por ambos lados.

Si queremos indicarle al unison que no replique en ambas direcciones podemos usar la opción -backup.

Mas información sobre unison en man unison o en su página web.

Nota: para mantener la poca integridad mental que pueda quedar, no hacer las pruebas con los ficheros definitivos, además de que es altamente recomendable hacer un backup de los datos antes de nada.