Cloud, sauvegarder ses données……. et le faire soi-même

Décidément, 2 articles le même jour, c’est la fête.
Je m’étais fendu il y a quelques temps d’un test de OwnCloud. Déçu déçu déçu, un outil pas utilisable à l’époque de la version 4, car l’agent était plus que mauvais et la synchro disait OK alors même qu’une palanquée de fichiers pouvait être envoyée et occuper sur le serveur…. 0 octet. Ca et d’autres bugs faisaient qu’on ne pouvait pas compter dessus, ce n’est pas fiable.
Les choses auront peut-être évolué depuis, mais quand bien même, une synchro immédiate, finalement ça ne me plait pas. Car on synchronise immédiatement les erreurs avec.
Bref. Pour sauvegarder mes données cryptées (par truecrypt) que je traîne d’un PC à l’autre, il me fallait une solution maison.
J’utilisais bien un peu Unison en mode graphique, mais c’est une plaie (lourd, foireux sur Windows etc). Finalement, j’ai réglé le problème en utilisant Unison – qui reste un superbe outil – mais en mode texte. Et là, bonheur.

Principe

Le principe est classique : ça fait de la synchro dans les 2 sens (détection des modifs / ajouts / suppressions et des conflits de chaque côté), entre 2 répertoires, l’un pouvant être situé par exemple sur un serveur distant, accessible en SSH (avec authentification par clefs histoire de ne pas demander un mot de passe tout le temps).
Partant de là, on peut synchroniser des données (une arborescende) entre 2 machines, le PC de travail et le serveur. Et puis finalement, on peut aussi synchroniser un 2è (3è, 4è…) PC avec le même contenu sur le serveur. Il suffira simplement de synchroniser régulièrement les données quand on les touche sur un PC (n’importe lequel) et le serveur sera à jour et à même de redescendre l’info aux autres PC.

Il ne manquerait qu’une interface web à la OwnCloud pour accéder à ses données, mais un simple UserDir dans Apache suffit grandement dans bien des cas (avec une protection de la page tout de même).

A noter que unison construit une base de données interne, sur chaque machine, pour conserver l’état connu de chaque fichier. C’est ainsi qu’il détecte que ça a changé d’un côté ou de l’autre (ou des deux).
(Si vous avez besoin de casser une base de données, pour faire des tests, ce sont les fichiers ar* sur le PC et le serveur, situés dans ~/.unison ; par contre il n’est pas évident de savoir qui est qui une fois qu’on synchronise plusieurs ensembles de répertoires).

Installation

Bon ben voilà, le principe est là, il suffit de le mettre en place.
Pour les Linux, il suffit d’installer le paquet unison. Pour les Windows, le paquet existe sous Cygwin et fait très bien le job. Seul détail, il n’y a pas encore les dernières versions, c’est la 2.32.52 à ce jour et donc, sur le serveur et les autres postes (linux ou windows), il faut installer la même, le protocole n’étant pas compatible d’une version à l’autre.
Par exemple sur Debian Wheezy, il suffit d’installer le paquet « unison2.32.52 » au lieu du paquet « unison » qui descend une 2.40.x de mémoire.

Configuration

Ensuite on configure un PC client, par exemple sous Cygwin (sous linux c’est pareil, sans /cygdrive/x) :
Créer un fichier ~/.unison/commun.prf à base de :

# Helps out a lot on Windows
fastcheck = true
# place new files at the top of the list
sortnewfirst = true
# turn on ssh compression
rshargs = -C
#ignore = Name Thumbs.db
#ignore = Name *.tmp

Et d’inclure cette base dans les autres fichiers de « profil » d’unison – un fichier de profil par couple de répertoire à synchroniser, exemple :

cat ~/.unison/mes_photos.prf
include commun

root = /cygdrive/k/photos
root = ssh://user@host.com//home/user/ma_synchro_unison/photos

J’insiste sur les « / » manquants en fin de répertoire.

Premier lancement, quelques cas d’école

Je vous recommande d’essayer sur un petit répertoire d’abord en maîtrisant bien ce qu’il y a dedans et de jouer un peu à modifier/créer/supprimer d’un côté ou de l’autre (ou des deux pour faire un conflit) avant de balancer ça sur toutes vos données et de tout perdre par mégarde.
Je peux lancer la commande magique : unison mes_photos # pour l instant sans parametre supplementaire
Au premier lancement, ça sort un message particulier pour indiquer qu’il doit d’abord faire une analyse de chaque côté :

Contacting server...
Connected [//mon_pc//cygdrive/k/photos -> //serveur.com//home/user/ma_synchro_unison/photos]
Looking for changes
Warning: No archive files were found for these roots, whose canonical names are:
        /cygdrive/k/photos
        //serveur.com//home/user/ma_synchro_unison/photos
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.[]

On fait « Entrée » et ensuite on doit prendre les décisions.
Ca se passe avec une interface texte minimaliste (et je rassure, ça s’automatise à mort pour pouvoir scripter ensuite).

Si l’un des répertoires est vide (la future destination), il proposera logiquement de tout balancer vers le côté vide.
Si les 2 sont identiques (en timestamp aussi), il ne fera rien mais aura construit sa base de données pour la prochaine synchro.
S’il y a des différences ou des conflits, et bien il faut analyser.
Quelques exemples :

Conflit

J’ai un fichier toto.txt de chaque côté, mais contenu et dates différents, ça donne :

$ unison mes_photos
Contacting server...
Connected [//mon_pc//cygdrive/k/mes_photos -> //serveur.com//home/user/ma_synchro_unison/mes_photos]
Looking for changes
  Waiting for changes from server
Reconciling changes

local          serveur.c...
new file <-?-> new file   toto.txt  [] ?
Commands:
  f                     follow unison's recommendation (if any)
  I                     ignore this path permanently
  E                     permanently ignore files with this extension
  N                     permanently ignore paths ending with this name
  m                     merge the versions
  d                     show differences
  x                     show details
  L                     list all suggested changes tersely
  l                     list all suggested changes with details
  p or b                go back to previous item
  g                     proceed immediately to propagating changes
  q                     exit unison without propagating any changes
  /                     skip
  > or .                propagate from from local to serveur.com
  < or ,                propagate from from serveur.com to local
new file <-?-> new file   toto.txt  []

J’ai demandé avec « ? » la liste des options, unison ne sachant que faire vu qu’il y a conflit.
Je décide que celui en local est le bon. C’est celui de « gauche », donc je tape « > » pour dire qu’il aille à droite.

Nouveau fichier d’un coté

Ensuite, j’ai un nouveau fichier d’un côté (à « droite », donc sur le serveur) :

         <---- new file   toto2.txt  [f]

Unison propose de ramener ce fichier (à priori il manque). C'est ce qu'il fera si je laisse le choix [f] (follow recommandation) ou si je le force en mettant "<" (de droite à gauche). Là on voit qu'unison peut décider tout seul.

Enfin...

A la fin, j'ai analysé tous mes conflits, je peux les relire (je peux passer sous silence là où il n'y pas de conflit - option L) etc. Et enfin, j'envoie la synchro :

Proceed with propagating updates? [] y
UNISON 2.32.52 started propagating changes at 10:34:34 on 27 May 2013
[BGN] Updating file toto.txt from /cygdrive/k/mes_photos to //serveur.com//home/user/ma_synchro_unison/mes_photos
[BGN] Copying toto2.txt from //serveur.com//home/user/ma_synchro_unison/mes_photos to /cygdrive/k/mes_photos
[END] Copying toto2.txt
[END] Updating file toto.txt
UNISON 2.32.52 finished propagating changes at 10:34:36 on 27 May 2013


Saving synchronizer state
Synchronization complete at 10:34:38  (2 items transferred, 0 skipped, 0 failed)

Automatisation : explication des paramètres auto, batch et terse

Maintenant vous me direz qu'il faut automatiser tout ça.
Le paramètre "-auto" a pour effet de confirmer automatiquement les décisions d'unison lorsqu'il en a (tout le temps sauf conflit). Il estimera alors suivant l'état précédent ce qu'il convient de faire ; et vous pouvez toujours changer d'avis.
Si vous ajoutez "-batch", alors il considère que les choix par défaut sont les bons et valide directement. C'est donc totalement automatique, donc scriptable, mais dangereux si vous maîtrisez mal certains changements.
A noter que les conflits sont laissés tels quels, en mode batch.
Enfin, le mode "-terse" permettra aux scripteurs de n'être pollué à l'affichage que par les changements effectivement faits : tel fichier copié dans tel sens, point.

Divers

Propagation des "propriétés" (props)

Si unison vous parle de synchroniser les "props", ce sont des aspects dans le genre permissions / date-heure etc qui sont différents entre 2 fichiers et qu'il convient d'aligner sur un coté ou l'autre afin de ne plus être embêté. Ca n'arrive en général qu'au début, lors d'une synchro initiale de 2 répertoires qui ne sont pas vides ; exemple le jour où vous passez d'un ancien système de synchro vers unison.

Inversion du sens de réplication

Imaginez : vous venez d'effacer un fichier d'un côté, par erreur. Vous lancez unison sans aucun paramètre d'automatisation. A l'analyse dudit fichier, il vous proposer logiquement de répercuter l'effacement d'un côté vers l'autre. Vous inversez le sens, ça sous-entend alors que vous recopier le fichier vers celui effacé, bref que vous récupérez le fichier. Pigé ?

Bilan

Et voilà, un bien bel outil, une pauvre ligne de commande et de grands services rendus.
Enfin, une commande simple quand vous savez ce que vous faites et que vous synchronisez plusieurs "profils" :

for i in profil1 profil2 profilx
do
    echo ____________ LANCEMENT DE UNISON SUR $i _____________
    unison -auto -batch -terse $i

Mais attention à l'automatisation, il faut savoir comment vous utilisez vos réplicats avant de faire n'importe quoi... et de perdre des données.