Ces deux applications sont très similaires et proposent, entre autre, un espace de stockage en ligne de 2 Go, dans une version de base gratuite, ainsi que des options payantes permettant d’étendre la capacité à 50 Go ou plus. A ce jour, il faut compter un peu moins de 10 € par mois pour 50 Go. Dropbox propose un système de parrainage qui vous fera gagner 250 Mo supplémentaires chaque fois que vous parrainez une nouvel inscrit (dans la limite de 8Go).

Les fichiers sont accessibles depuis n’importe quel ordinateur connecté à Internet via une interface web. Ceci n’est pas pour déplaire à Mamie,  qui se voit rassurée de pouvoir sauvegarder ses précieuses recettes de cuisine à l’abri d’un incendie ou de je ne sais quelle autre catastrophe domestique.

L’installation d’un logiciel client sur un ou plusieurs postes va permettre de synchroniser un répertoire local avec l’espace de stockage en ligne. Ainsi, un fichier ajouté dans ce dossier sera automatiquement ajouté par synchronisation dans l’espace en ligne.  Ce dernier se synchronisera à son tour avec les autres machines sur lequel le client est installé. C’est très pratique pour Mamie, qui peut taper sa recette de cookies au chocolats sur l’ordinateur de son bureau et l’emporter à son club de cuisine sur son Ipad automatiquement synchronisé – Qu’elle frimeuse cette mamie –   Pour cela, je dois préciser qu’elle a une préférence pour DropBox, porté sur de nombreux systèmes, contrairement à Ubuntu One, qui reste encore limité à un environnement Ubuntu.

Image : Dropbox.com

Enfin, parmi les multiples utilisations possibles, nous trouvons bien entendu la possibilité de partager des fichiers ou des dossiers avec d’autres utilisateurs. Très pratique pour Mamie, qui peut diffuser, à toute la famille, les photos de ses pâtisseries qu’elle prend en 10 MégaPixel grâce à son réflex numérique.

Outre la capacité limitée dans les versions gratuites, le fait que les fichiers soient stockés en clair, on ne sais où, peut-être perturbant. Il est bien sûr possible de chiffrer les données avant leur stockage, mais il faut bien avouer que ce n’est pas très pratique.

Sachant que des outils libres, tels qu’ unison, on largement fait leurs preuves en matière de synchronisation, l’idée de construire ma propre architecture « JopaOne » m’a traversé l’esprit. C’est alors que je suis tombé sur le tuto de KIK-IT : UbuntuOne VS MyOne, décrivant exactement ce que je souhaitais faire : Un espace de stockage sur un de mes serveurs et des répertoires locaux sur mes différentes machines, le tout synchronisé grâce à unision,  de préférence à travers ssh…

Pour conclure et je pense que Mamie sera d’accord avec moi, ma préférence va vers DropBox pour le partage de fichiers non sensibles avec les amis. Ce dernier est plus abouti qu’Ubuntu One et bien plus rapide pour  les synchronisation. La disponibilité du client sous de multiples plateforme est un de ses atouts majeurs… Mamie nous fait remarquer que le client « Androïd » est très sympathique pour ajouter son Smartphone

Pour la synchronisation de documents entre mes machines, j’ai préféré une solution basée sur Unison et ssh… Il n’y a pas a dire, on est bien plus tranquille quand les fichiers sont sur un serveur bien à nous…

Liens :

• Ubuntu One
• DropBox
• MyOne (KIK-IT)

D’un point de vu système, Mir:ror est directement reconnu sous Linux et accessible via le handler de périphérique /dev/hidrawX (où X est le numéro de périphérique, normalement « 0″ si c’est le premier appareil du genre connecté).

La petite application « discover-device« , fournie avec Mirware, permet de le détecter automatiquement :

Attention tout de même aux droits, le périphérique n’est par défaut accessible que par root, il faudra lui changer les droits ou utiliser le script « installer.sh » pour le faire, avant de pouvoir l’exploiter avec un utilisateur standard.

Commençons par voir ce qu’il se passe avec un simple « cat » du fichier :

Des hiéroglyphes s’affichent lorsque nous approchons ou retirons un tag… C’est plutôt bon signe, et visiblement c’est binaire ! Nous devrions y voir plus clair avec un affichage en hexadécimal.  Hexdump est idéal pour ça !

La première ligne (0000 0000 0000 0000 0000 0000 0000 0000 *) nous indique que tant qu’il ne se passe rien, on lit des zéros… Où…Qu’on lit des zéros tant qu’il ne se passe rien ! (c’est plutôt normal).
Les deux lignes suivantes (0102 0000 d008 1a02 5303 4202 00d2 0000 – 0000 0000 0000 0000 0000 0000 0000 0000) s’affichent lorsqu’un tag est approché, les deux dernières ( 0202 0000 d008 1a02 5303 4202 00d2 0000 – 0000 0000 0000 0000 0000 0000 0000 0000 ) lorsqu’on éloigne le tag.

Après plusieurs tests, j’en déduis assez facilement que les deux premiers octets (0102 ou 0202) codent l’évènement. J’en ai repéré 4 types :

• 0×0102 : Tag rfid détecté,
• 0×0202 : Tag rfid retiré,
• 0×0501 : Le mir:ror est mis à l’envert,
• 0×0401 : Le mir:ror est remis à l’endroit.

Les 12 octets suivants semblent identifier la puce RFID.

A titre de test, écrivons rapidement un petit bout de code C, prenant le device en paramètre et affichant les évènements et le tag associé :

// Jopa - Petit test du Mir:ror : test_mirror.c
#include <stdio.h>
#include <stdlib.h>
 
int main(int argc, char *argv[]) {
  FILE *mirror;
  short unsigned int block;
  short unsigned int event;
  char tag[25];
  int i;
 
  //Vérification du paramètre (device)
  if (argc!=2) {
        printf ("Usage : %s mirror_device \n\n",argv[0]);
        exit(-1);
  }
 
  // Ouverture du fichier device
  mirror = fopen(argv[1],"rb");
  if (!mirror) {
        printf("Accès à  %s impossible !\n",argv[1]);
        exit(-1);
  }
 
  // Boucle en lecture
  while (1) {
     fread(&event,2,1,mirror);
     if (event!=0) {
        // Evenement detecté, lecture de l'ID
        for (i=0;i<6;i++) {
            fread(&block,2,1,mirror);
            sprintf(&tag[i*4],"%04X",block);
        }
 
 //Affichage en fonction de l'événement
        switch (event) {
            // Tag On
            case 0x102 :
                printf("%s : ON\n",tag);
                break;
 
             //Tag Off
             case 0x202 :
                 printf("%s : OFF\n",tag);
                 break;
 
             //Mirror envers
             case 0x501 :
                 printf("MIR:ROR ENVERS\n");
                 break;
 
             //Mirror endroit
             case 0x401 :
                   printf("MIR:ROR ENDROIT\n");
                    break;
 
             //Default
             default :
                   printf("Evénement inconnu\n");
        } //switch
      } //if (event
   } //while (1)
} // main()

En quelques lignes, nous ouvrons le périphérique dont le handler est passé en paramètre et bouclons sur sa lecture, 2 octets par 2 octets.
Quand autre chose que « 0″ est détecté, c’est forcément un changement d’état. Nous lisons ensuite l’identifiant de la puce RFID.
La dernière partie affiche un message en fonction de l’évènement détecté.

Il ne reste plus qu’à le compiler et le tester :
$ gcc test_mirror.c -o test_mirror
$ ./test_mirror

Pour compléter l’exemple, nous pouvons rajouter l’exécution d’un script associé au tag et à son approche ou son éloignement. Les scripts pourraient être stockés dans le répertoire de l’utilisateur et porter l’<id>-on.sh ou l’<id>-off.sh comme nom. Pour l’exemple :

• 0000D0081A025303420200D2-on.sh : Lancement de Firefox sur le blog de Jopa

#!/bin/sh
firefox http://www.jopa.fr

• 0000D0081A025303420200D2-off.sh : Lancement de Thunderbird

#!/bin/sh
thunderbird

$ chmod +x ~/0000D0081A025303420200D2-*.sh

Adaptons un peu le code en ajoutant une variable pour le nom du script et une commande « system » dans le « switch/case ».

   // Jopa - Test Mir:ror
 
#include <stdio.h>
#include <stdlib.h>
 
int main(int argc, char *argv[]) {
  FILE *mirror;
  short unsigned int block;
  short unsigned int event;
  char tag[25];
  // Ajout d'un variable script
  char script[256];
  int i;
 
  //Vérification du paramètre (device)
  if (argc!=2) {
        printf ("Usage : %s mirror_device \n\n",argv[0]);
        exit(-1);
  }
 
  // Ouverture du fichier device
  mirror = fopen(argv[1],"rb");
  if (!mirror) {
        printf("Accès à  %s impossible !\n",argv[1]);
        exit(-1);
  }
 
  // Boucle en lecture
  while (1) {
     fread(&event,2,1,mirror);
     if (event!=0) {
        // Evenement detecté, lecture de l'ID
        for (i=0;i<6;i++) {
            fread(&block,2,1,mirror);
            sprintf(&tag[i*4],"%04X",block);
        }
 
 //Affichage en fonction de l'événement
        switch (event) {
            // Tag On
            case 0x102 :
                printf("%s : ON\n",tag);
                //Construction du nom de script et exécution
                sprintf(script,"./%s-on.sh",tag);
                system(script);
                break;
 
             //Tag Off
             case 0x202 :
                 printf("%s : OFF\n",tag);
                 //Construction du nom de script et exécution
                 sprintf(script,"./%s-off.sh",tag);
                 system(script);
                 break;
 
             //Mirror envers
             case 0x501 :
                 printf("MIR:ROR ENVERS\n");
                 break;
 
             //Mirror endroit
             case 0x401 :
                   printf("MIR:ROR ENDROIT\n");
                    break;
 
             //Default
             default :
                   printf("Evénement inconnu");
        } //switch
      } //if (event
   } //while (1)
} // main()

Ceci n’est bien entendu qu’un exemple, écrit rapidement et pas forcément très propre. Mais il permet de mettre en évidence la simplicité avec laquelle il est possible d’accéder à des informations RFID et ouvre la porte sur des développements qui peuvent être rapidement prometteurs.

Je m’empresse de télécharger une mise à jour que j’installe très simplement via l’interface web.  C’est simple, mais qu’est-ce que c’est long !!!

Donc… une vingtaine de minutes plus tard, me voici avec la version 2.1.0.1 du Firmware… Et là, on peut dire que ça change !!!

Au niveau de l’USB, nous avons la possibilité d’activer des périphériques de stockages bien sûr, mais aussi de gérer des webcams, des scanners et des imprimantes.

Les partitions montées peuvent ensuite être partagés via samba (partage pour les réseaux windows) et/ou via un serveur ftp intégré.

Je farfouille un peu dans mes tiroirs… Je dois bien avoir une webcam quelque part !

C’est plutôt sympa, j’ai la possibilité d’enregistrer des snapshots ( il faut pour cela q’un périphérique disque usb soit connecté)  ou de visionner le flux vidéo via le navigateur.

Bouh…Je fais peur là non ? On dirait bien que ce petit joujou promet de bonnes heures de bidouilles…

Dans un premier temps, nous aurons besoin d’un liveCD, peut importe la distribution, l’essentiel est d’obtenir un shell.

Une fois la machine bootée sur le CD, il nous faut préparer le chroot en montant la partition, /proc contenant les informations du noyau et  /dev pour l’accès au périphériques.

Dans mon cas, la partition racine est sda1

mount /dev/sda1 /mnt
mount -t proc none /mnt/proc
mount -o bind /dev /mnt/dev

Ceci fait, nous pouvons entrer dans le chroot et lancer les scripts d’installation de grub.

chroot /mnt
grub-install --recheck
grub-install /dev/sda

Boursicoteur à mes heures perdues, je m’intéresse surtout aux méthodes d’analyse graphique et aux traitements statistiques. J’utilise pour cela une base de données que j’alimente régulièrement avec les dernières cotations boursières.

Le site ABCBourse fournit gratuitement ces valeurs sous forme d’un fichier csv, téléchargeable par l’intermédiaire d’un formulaire. Ce dernier permet de spécifier la période et les catégories de valeurs souhaitées : http://download.abcbourse.com/historiques.aspx?f=ex

Pour corser un peu l’énoncé, le site n’autorise pas le téléchargement de l’intégralité des valeurs en une seule fois, si la période dépasse la journée. L’objectif de cet article, vous l’aurez compris, est de montrer comment automatiser la récupération de ces valeurs au jour le jour, en vue de leur intégration dans une base mysql.

Lynx, le navigateur en mode texte bien connu de tout geek qui se respecte, dispose d’une option très intéressante : il permet l’enregistrement de toutes les touches pressées lors de la navigation. Le fichier ainsi obtenu pourra ensuite être rejoué, un peu comme une macro.

En remplaçant dans ce fichier les dates saisies pour le formulaire par les dates souhaitées, le tour est joué…

Allez… Zou !!!

Etape 1 : Ca tourne !

$ lynx  -accept_all_cookies -cmd_log=abc.log 

http://download.abcbourse.com/historiques.aspx?f=ex

Complétons le formulaire en prenant soin de bien saisir la date de début, la date de fin et de cocher les catégories de valeurs souhaitées. Un ou deux essais peuvent s’avérer nécessaires quand on n’est pas familiarisé avec ce type de navigateur…

Un « pseudo clic » sur le bouton « Submit » (marqué [Télécharger.gif]-Submit), la liste des actions et leurs cours apparaît.

La touche « p » permet d’accéder au menu d’impression. Ce menu permet également d’enregistrer la page dans un fichier. Le nom du fichier par défaut est de la forme Cotations[aaaammjj].txt; Très bien ça !

Nous pouvons quitter Lynx, c’est dans la boîte ! La séquence de touches est enregistrée dans le fichier abc.log .

Pour vérifier son enregistrement, nous pouvons directement rejouer la « scène » :

lynx  -accept_all_cookies -cmd_script=abc.log 

http://download.abcbourse.com/historiques.aspx?f=ex

Etape 2 : Le montage

Editons maintenant le fichier abc.log. L’exercice va consister à repérer les dates et à remplacer leurs chiffres par des balises qui seront exploitables par un script. Je choisis arbitrairement :

• XXJ1 XXJ2 pour les deux chiffres du jour
• XXM1 XXM2 pour les deux chiffres du mois
• XXA1 XXA2 XXA3 XXA4 pour les quatre chiffres de l’année

$ vi abc.log

# Command logfile created by Lynx 2.8.5rel.1 (04 Feb 2004)
# Arg0 = lynx
# Arg1 = -accept_all_cookies
# Arg2 = -cmd_log=abc.log
# Arg3 = http://download.abcbourse.com/historiques.aspx?f=ex
key <Down Arrow>
key <Down Arrow>
key <Down Arrow>
...
key <delete>
key <delete>
key <delete>
# Ici le jour de début
# key 2
# key 3
key XXJ1
key XXJ2
key /
# Ici le mois de début
# key 0
# key 9
key XXM1
key XXM2
key /
# Ici l'année de début
# key 2
# key 0
# key 0
# key 8
key XXA1
key XXA2
key XXA3
key XXA4
key <Right Arrow>
key <delete>
key <delete>
key <delete>
...
# Ici le jour de fin
# key 2
# key 3
key XXJ1
key XXJ2
key /
# Ici le mois de fin
# key 0
# key 9
key XXM1
key XXM2
key /
# Ici l'année de fin
# key 2
# key 0
# key 0
# key 8
key XXA1
key XXA2
key XXA3
key XXA4
key <Down Arrow>
key <Down Arrow>
...
key <Left Arrow>
key <Left Arrow>
key /
key t
key m
key p
key /
key ^J
key o
key q
key o

Etape 3 : Le script

Il ne reste plus qu’à réaliser un script bash qui remplacera les balises XXJ1 à XXA4 par les chiffres de la date du jour, exécutera lynx avec sa nouvelle séquence de commandes et finalement, déclenchera l’importation dans la base de données.

#!/bin/bash
 
# Récupération de la date du jour
JOUR=`date "+%d/%m/%Y"`
 
# "Explode" de la date en chiffres
J1=${JOUR:0:1}
J2=${JOUR:1:1}
 
M1=${JOUR:3:1}
M2=${JOUR:4:1}
 
A1=${JOUR:6:1}
A2=${JOUR:7:1}
A3=${JOUR:8:1}
A4=${JOUR:9:1}
 
# Construction du nouveau fichier de commande
# La variable PART sert à construire le nom de la Balise (XX$PART)
# Et de "pointeur" vers les variables $J1, $J2, etc... ($$PART)
 
CMD="cat abc.log"
for PART in J1 J2 M1 M2 A1 A2 A3 A4; do
    eval CHIFFRE=$$PART
    CMD="$CMD|sed 's/XX$PART/$CHIFFRE/g'"
done
CMD="$CMD > /tmp/abc.cmd"
eval $CMD
 
# Exécution de Lynx
 
lynx  -accept_all_cookies -cmd_script=/tmp/abc.cmd http://download.abcbourse.com/historiques.aspx?f=ex 2>> /var/log/cotationabc.log
 
# Appel du script d'import dans la base
FICHIER="Cotations$A1$A2$A3$A4$M1$M2$J1$J2.txt"
if [ -e /tmp/$FICHIER ]; then
    php import_batch.php /tmp/$FICHIER >> /var/log/cotationabc.log
    tail -n 1 /var/log/cotationabc.log
    mv /tmp/$FICHIER /var/cotations
else
    echo "!!! Erreur de traitement du fichier $FICHIER !!!"
fi

Le lancement du script sera planifié dans un crontab afin de parfaire l’automatisation.

A titre d’exemple, voici le script import_batch.php qui se charge d’importer les valeurs dans la base de données. Il est très réduit car il utilise une classe fcours « maison » possédant les attributs nécessaires à l’enregistrement de cotations boursières et une méthode d’import à partir d’un fichier. L’intérêt de l’article ne résident pas dans cette partie, je ne vais pas la détailler.

#!/usr/bin/php -q
<?php
include_once "include/class_file_cours_inc.php";
   if ($argc != 2 || in_array($argv[1], array('--help', '-help', '-h', '-?'))) {
?>
Script d'import de données dans la base bourse...
 
  Usage:
    <?php echo $argv[0]; ?> <nomdefichier>
 
     <nomdefichier>  Nom du fichier CSV issu d'ABCBourse au format Excel / ISIN
 
<?php
          } else {
   echo "Traitement du fichier $argv[1]n";
   $import = new amdr_fcours($argv[1],0);
   $import->import();
}
?>

Tous les administrateurs systèmes connaissent bien la commande tail qui permet de lister dynamiquement les dernières lignes d’un fichier. C’est un outil incontournable pour la surveillance de journaux systèmes en temps réel.

« Multitail » réalise la même chose, mais en mieux ! Son principal intérêt réside dans la possibilité de traiter plusieurs fichiers en même temps, la console étant tout simplement divisé par le nombre de fichiers ouverts. La coloration syntaxique, la possibilité de marquer des lignes ou encore d’effectuer des recherches sont des petits plus qui deviennent vite incontournables.

Adopter Multitail, c’est finir de jongler entre les consoles et épargner les pauvres touches  [Alt], [F1], [F2], [F3],… du clavier.

Je stocke une quantité inimaginable de scripts, de bouts de codes, de documents, de photos et de projets en tout genre sur mon serveur de fichiers. Quelques Go qui représentent des années de ma vie « numérique ». Le temps passe, le volume des données augmente et il devient urgent de trouver un moyen de sauvegarde plus rapide, plus efficace et surtout moins fastidieux que la gravure sur DVD. - Vous remarquerez au passage la photo prise en exclusivité pour l’illustration de cet article et sa superbe mise en scène réalisée sur le plan de travail de ma cuisine -
La sauvegarde sur DAT ou DLT étant bien trop onéreuse et surtout trop lente, j’ai opté pour le montage d’un serveur de sauvegardes « maison ».

Mise en place :

* Côté matériel, un petit Céléron 900Mhz de récupération fera très bien l’affaire. Je le gonfle un peu en montant la ram à 384Mo et attribue le gros du budget au stockage en lui offrant deux beaux disques dur IDE de 320Go - Ca ! C’est classe ! -

* Côté logiciel, une distribution Debian et un petit script qui combine rsync pour optimiser les transferts réseaux et des liens durs pour garder un historique en limitant l’espace disque utilisé.

Pour simplifier les choses, nous allons appeler le serveur de fichiers « serv_file » et le serveur de sauvegardes « serv_nas« .

Les présentations étant faites, commençons par générer un bi-clés pour ssh sur serv_nas et faire une copie de la clef publique sur serv_file, pour que mon premier puisse parler à mon second, via ssh et sans avoir à fournir de mot de passe. C’est quand même bien plus pratique pour automatiser le bazar !

Concrètement, comment fait-on ?
Sur serv_nas :

srv_nas:~# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/root/.ssh/id_rsa already exists.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
2d:40:c4:09:67:06:...b:bf:06 root@srv_nas

srv_nas:~# ssh-copy-id root@srv_file
root@srv_file's password :

Tout c’est bien passé ? L’ouverture d’une session ssh de serv_nas vers serv_file devrait se faire sans mot de passe. Essayons…

srv_nas:~# ssh srv_file
Last login: Mon Mar 17 18:10:25 2008 from 192.168.7.102
Linux srv_file 2.6.18-6-686 #1 SMP Sun Feb 10 22:11:31 UTC 2008 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

srv_file:~#
srv_file:~# exit

srv_nas~#

Si ce n’est pas déjà fait, il faut maintenant installer rsync sur les deux machines :

srv_nas:~# aptitude install rsync
srv_nas:~# ssh srv_file aptitude install rsync

Le script – Initialisation

Allez ! Fini la rigolade, passons au script…
La première chose à faire est de déclarer quelques variables…C’est quand bien plus propre et ça facilite la modification du script par la suite.

• le nom serveur à sauvegarder ($SERVER),
• le répetoire local de stockage des sauvegardes ($DST),
• le fichier de log ($LOG),
• et une date formatée qui va être utilisée pour « horodater » la sauvegarde ($DATE).

#!/bin/bash
#------Début du fichier /usr/local/scripts/snapshot.sh
 
SERVEUR="srv_file"
DST="/srv/sauvegardes"
LOG="/var/log/snapshot-$SERVEUR.log"
DATE=`date +%y%m%d-%H%M`

Le script – rsync :

L’étape suivante, va consister à boucler sur les répertoires à sauvegarder (etc, home, root, data, srv et var dans l’exemple) pour en faire un miroir dans un dossier local nommé « current » (/srv/sauvegardes/current). Ce dernier contiendra toujours la dernière image des fichiers sauvegardés.
La commande rsync avec les options suivantes est la plus à même de réaliser ce travail :

• -r (récursif) pour inclure les sous répertoires,
• -a (archive) pour conserver les propriétés et les droits du fichier original,
• –delete pour supprimer du répertoire destination tout fichier qui ne serait plus présent dans le répertoire source. Cette option est impérative pour la suite des opérations.

# SYNCHRONISATION
 
echo "Début de la sauvegarde le `date +%D` à `date +%H:%M` " >> $LOG
for REP in etc home root data srv var ;  do
    echo "    *    Sauvegarde de  $REP" >> $LOG
    rsync -ra --delete $SERVEUR:/$REP $DST/current 2>> $LOG
done;

Le grand intérêt dans l’utilisation de la commande rsync réside dans le fait que, contrairement à scp, elle ne va copier que les fichiers différents ou inexistants dans le répertoire destination et donc procurer un immense gain de bande passante et de temps.

Le script – Les liens durs :

La dernière étape va créer une image datée du répertoire « current », avant que la prochaine synchronisation ne vienne en altérer le contenu, en optimisant l’espace disque utilisé.

Pour cette opération, la puissante des liens durs va nous être très utile.

Les liens durs associent deux ou plusieurs fichiers à un même espace sur le disque. Les deux fichiers restent indépendants, tout en partageant le même espace disque et donc le même inode . Toute modification de l’un, modifie l’autre, mais la suppression de l’un, casse le lien et ne supprime pas physiquement l’autre.

Dans notre cas, nous allons créer un lien dur de notre dossier « current » et de son contenu vers un dossier portant la valeur de notre variable $DATE (la date et l’heure du début de la sauvegarde).
Il suffit pour cela d’utiliser la commande « cp » avec les options :

• -l (lien) pour la copie par lien dur,
• -a (archive) pour conserver les propriétés et droits des fichiers.

# SNAPSHOT
 
cp -al $DST/current $DST/$DATE 2>> $LOG
 
echo "Fin de la sauvegarde le `date +%D` à `date +%H:%M` " >> $LOG
echo "========================================" >> $LOG
 
#------Fin du fichier /usr/local/scripts/snapshot.sh

En résumé :

Juste après l’exécution du script, le répertoire current et le répertoire « daté » sont identiques. Comme le second est créé par « liens durs », aucun espace disque supplémentaire n’est consommé.

Lors de la sauvegarde suivante, la commande rsync va modifier le répertoire « current » :

• En effaçant les fichiers supprimés sur le serveur depuis la dernière sauvegarde – les liens durs pour ces fichiers seront cassés,

• En ajoutant les fichiers créés sur le serveur – pas d’action sur les liens,

• En recopiant tout fichier modifié sur le serveur, ce qui revient à supprimer l’ancienne version et créer la nouvelle – les liens portant sur les anciens fichiers seront cassés.

En résumé, cette mécanique va permettre de garder un historique des fichiers du serveur, jour après jour, en ne consommant que l’espace utilisé par les ajouts ou modifications de fichiers.

La notion de lien est complètement transparente pour l’utilisateur et sous chaque répertoire, nous retrouvons l’ensemble des fichiers, tels qu’ils étaient sur le serveur à la date correspondante; d’où le nom de « snapshot » donné à cette technique (et à mon script !)

Pour finir, voici le petit script en un seul morceau :

#!/bin/bash
#------Début du fichier /usr/local/scripts/snapshot.sh
 
# PARAMETRE
SERVEUR="srv_file"
DST="/srv/sauvegardes"
LOG="/var/log/snapshot-$SERVEUR.log"
DATE=`date +%y%m%d-%H%M`
 
# SYNCHRONISATION
echo "Début de la sauvegarde le `date +%D` à `date +%H:%M` " >> $LOG
for REP in etc home root data srv var ;  do
    echo "    *    Sauvegarde de  $REP" >> $LOG
    rsync -ra --delete $SERVEUR:/$REP $DST/current 2>> $LOG
done;
 
# SNAPSHOT
cp -al $DST/current $DST/$DATE 2>> $LOG
echo "Fin de la sauvegarde le `date +%D` à `date +%H:%M` " >> $LOG
echo "========================================" >> $LOG
 
#------Fin du fichier /usr/local/scripts/snapshot.sh