Gsync est un moteur modulaire de notification (basé sur inotify) et de synchronisation des modifications d'un système de fichiers.
La configuration de la synchronisation des données tient en un seul fichier: /etc/gandi/gsync.conf qui respecte la syntaxe YAML (cf. http://www.yaml.org/spec/1.2/spec.html).
La configuration de Gsync consiste en la configuration d'un ou plusieurs "repositories" ou dépôts (stockages centralisés et organisés de données).
Prenons un exemple basique de configuration d'un dépôt local.
Nous définissons un ensemble de dépôt de la manière suivante :
repositories:
homes:
type: versioning
path: /srv/disk2/backups/
monitor:
- /home/
websites:
type: versioning
path: /srv/disk3/backups/
monitor:
- /var/www/site1/
- /var/www/site2/
Ici, nous créons un dépôt nommé 'homes' pour lequel les modifications dans le répertoire /home/ sont répercutées en local dans le répertoire /backups/ du disque disk2 ainsi qu'un dépôt 'websites' pour lequel les modifications dans les répertoires /var/www/site1/ et /var/www/site2/ sont répercutées en local dans le répertoire /backups/ du disque disk3.
(Attention, la syntaxe YAML est "sensible" aux caractères d'indentation; Un ou plusieurs espaces, jamais de tabulations...) monitor spécifie donc la liste des répertoires à synchroniser et path le chemin de destination.
La façon dont les modifications survenant dans les répertoires monitorés sont répercutées dans l'espace de stockage dépend du type de plugin associé au dépôt (défini par le champ type de la configuration du dépôt).
A l'heure actuelle, trois plugins sont disponibles : versioning, remote et simulator (utile pour les tests et le debuggage).
Le premier permet la synchronisation d'un ou plusieurs répertoires en local, le deuxième la synchronisation d'un ou plusieurs répertoires sur une machine distante.
Ce plugin permet d'organiser des sauvegardes dans un répertoire de stockage local sur la base de hard links (alias). Typiquement l'organisation du dépôt de type versioning sera configurée via les sections interval et filters.
La section interval permet de spécifier le nombre de versions maximales conservées (count) et l'intervalle de temps entre 2 sauvegardes (delay).
Exemple:
repositories:
homes:
type: versioning
path: /srv/disk2/backups/
monitor:
- /home/
intervals:
snap:
count: 30
delay: 86400
Dans cet exemple, nous définissons une configuration de sauvegarde des données nommée 'snap'. Le répertoire /home/ est alors sauvegardé tous les jours (toutes les 86400 secondes) 30 fois maximum avant que le système n'efface la sauvegarde la plus ancienne et n'en crée une nouvelle. Cette configuration correspond, en fait, à une sauvegarde journalière avec une rotation mensuelle des sauvegardes.
Autre exemple, un peu plus complexe:
intervals:
recent:
delay: 3600
count: 2
3hours:
delay: 10800
count: 3
1day:
delay: 86400
count: 3
1month:
delay: 2592000
count: 1
Comme le montre le détail du contenu du répertoire de destination, ci-dessous, le répertoire /home/ est synchronisé dans le répertoire /srv/disk2/backups/current/ et les synchronisations sont sauvegardées toutes les heures (dans les répertoires recent.1 et recent.2), toutes les trois heures (dans les répertoires 3hours.1, 3hours.2 et 3hours.3), quotidiennement (dans les répertoires 1day.1, 1day.2 et 1day.3) et mensuellement (dans le futur répertoire 1month.1 ).
$ ls -al /srv/disk2/backups/
drwxr-xr-x 3 root root 4096 Oct 15 09:40 018
drwxr-xr-x 3 root root 4096 Oct 17 19:10 075
drwxr-xr-x 3 root root 4096 Oct 20 19:10 147
drwxr-xr-x 3 root root 4096 Oct 21 04:10 156
drwxr-xr-x 3 root root 4096 Oct 21 10:10 162
drwxr-xr-x 3 root root 4096 Oct 21 19:10 171
drwxr-xr-x 3 root root 4096 Oct 21 20:10 172
lrwxrwxrwx 1 root root 23 Oct 21 04:10 1day.1 -> /srv/disk2/backups/132/
lrwxrwxrwx 1 root root 23 Oct 19 19:10 1day.2 -> /srv/disk2/backups/075/
lrwxrwxrwx 1 root root 23 Oct 20 19:10 1day.3 -> /srv/disk2/backups/075/
lrwxrwxrwx 1 root root 23 Oct 21 16:10 3hours.1 -> /srv/disk2/backups/162/
lrwxrwxrwx 1 root root 23 Oct 21 16:10 3hours.2 -> /srv/disk2/backups/156/
lrwxrwxrwx 1 root root 23 Oct 21 16:10 3hours.3 -> /srv/disk2/backups/147/
lrwxrwxrwx 1 root root 23 Oct 21 20:10 current -> /srv/disk2/backups/172/
lrwxrwxrwx 1 root root 23 Oct 21 20:10 recent.1 -> /srv/disk2/backups/171/
lrwxrwxrwx 1 root root 23 Oct 15 11:45 recent.2 -> /srv/disk2/backups/018/
La section filters d'un dépôt permet de spécifier de façon plus précise le type de répertoire ou fichier qui doit être synchronisé via un filtrage basé sur des expressions régulières. Le champ default de la section filters définit la stratégie de filtrage par défaut. Si default a pour valeur True : tous les fichiers sont synchronisés par défaut sauf les fichiers ou répertoires dont les chemins correspondent aux expressions régulières fixées à False.
Exemple:
filters:
default: True
'\.log$': False
'/home/stephanie/': False
Ici tous les fichiers se terminant par .log et tous les répertoires ou fichiers dont le chemin contient /home/stephanie/ seront exclus de la liste des données à synchroniser.
Au contraire, si default a pour valeur False : aucun fichier n'est synchronisé par défaut sauf les fichiers ou répertoires dont les chemins correspondent aux expressions régulières fixées à True.
filters:
default: False
'/home/stephanie/': True
'^/home/pascal/': True
Ici seuls les fichiers et répertoires dont le chemin contient /home/stephanie/ ou commence par /home/pascal/ feront parti de la liste des données à synchroniser.
Ce plugin permet de synchroniser les données dans un espace de stockage distant. (Attention! : ce plugin est en version Beta... Use at your own risk...) Dans cette configuration, deux instances de gsync doivent tourner sur deux machines distinctes. La première est configurée pour envoyer les données sur la machine distante via une API REST; la deuxième pour recevoir ces données via un serveur HTTP. Ces deux instances doivent être configurées de manière cohérente. (cf. schéma ci-dessous)
Exemple de configuration d'une première instance de gsync:
repositories:
myfirstrepo:
type: remote
path: http://toto:totopassword@1.2.3.4:5001/homes/
monitor:
- /home/
filters:
default: True
'\.log$': False
'/home/stephanie/': False
Nous définissons ici la liste des répertoires à monitorer (monitor) et un chemin de destination (path) de la forme:
http://<user>:<password>@<adresseIP>:<port>/<nom_du _dépôt>
Exemple de configuration d'une deuxième instance:
webserver:
port: 5001
repositories:
homes:
type: versioning
path: /srv/disk2/backups/
export:
login: toto
password: password
intervals:
snap:
count: 30
delay: 86400
Nous définissons ici, dans la section webserver, le port d'écoute du serveur HTTP et dans la section export du dépôt, les paires login/mot de passe protégeant l'accès au dépôt; La machine cible utilise le plugin versioning pour organiser les sauvegardes des synchronisations dans le répertoire /srv/disk2/backups/.
Si vous installez Gsync sur un serveur Gandi Expert, pour une distribution Debian/Ubuntu, il vous suffit de taper (sous root):
$ apt-get update
$ apt-get install gsync
Sous Fedora et OpenSUSE :
yum install gsync
Sous Mandriva :
urpmi.update -a
urpmi gsync
Editer et modifier le fichier de configuration /etc/gandi/gsync.conf, puis démarrer le démon:
$ /etc/init.d/gsync start
Si vous désirez installer Gsync sur un serveur Gandi AI, rendez-vous sur http://wiki.gandi.net/fr/hosting/manage-disk/gsync pour un tutoriel détaillé sur la procédure d'installation.
Le tarball est disponible sur la Homepage de Gsync (http://open.gandi.net/projects/gsync/)
$ wget http://open.gandi.net/download/gsync.tar.bz2
$ tar xjvf gsync.tar.bz2
$ cd gsync
$ sudo make install
Editer et modifier le fichier de configuration /etc/gandi/gsync.conf, puis démarrer le démon:
$ sudo /etc/init.d/gsync start
La section webserver permet de faire tourner un serveur HTTP non seulement pour le transfert des données, mais aussi pour l'accès aux dépôts via un navigateur.
Pour lancer le serveur au démarrage de Gsync, ajouter à la racine de votre fichier de configuration une section webserver comme suit:
webserver:
port: <port>
et rendez-vous à l'url suivante :
http://<adresseIP>:<port>
pour visualiser la liste de vos dépôts.
L'accès à chaque dépôt est protégé par le login/mot de passe défini dans la section export de votre dépôt (cf. schéma 1).
Pour sécuriser votre serveur HTTP, spécifier une section secure, comme suit :
webserver:
port: <port>
secure:
ssl_certificate: /path/to/your/ssl/certificate
ssl_private_key: /path/to/your/ssl/key
et rendez-vous à l'url suivante:
https://<adresseIP>:<port>
Le loglevel vous permet de spécifier les types d'informations reportées dans le fichier de logs (/var/log/syslog).
Le loglevel peut prendre quatre valeurs parmi les suivantes :
Pour fixer ce dernier, ajouter à la racine de votre fichier de configuration un champ loglevel comme suit:
loglevel: <mode>
Pour une restauration des données en local, voici une des procédures possibles.
Choisissez le répertoire de backup contenant les données que vous souhaitez restaurer (1day.1 dans cette exemple); Créez une archive du répertoire:
$ tar -C /srv/disk2/backups/1day.1/ -cf 1day.1.tar .
Puis décompresser l'archive:
$ tar -C / -xf 1day.1.tar
Si vous souhaitez restaurer une partie des fichiers, il vous est toujours possible de passer en argument de la commande la liste des fichiers ou répertoire que vous désirez extraire de l'archive:
$ tar -C / -xf 1day.1.tar ./var/www/site1/
L'equivalent en une ligne de commande:
$ tar -C /srv/disk2/backups/1day.1/ -cf - . | tar -C / -xvf -
Pour une restauration sur une machine distante, vous pouvez procéder de la façon suivante; créez une archive:
$ tar -C /srv/disk2/backups/1day.1/ -cf 1day.1.tar.gz .
$ scp 1day.1.tar.gz me@myserver:/tmp
Puis décompresser l'archive sur la machine distante:
$ ssh me@myserver
$ tar -C / -xzf /tmp/1day.1.tar.gz
[TODO]