initial commit

1 files changed, 77 insertions, 0 deletions

diff --git a/content/Informatique/backup.rst b/content/Informatique/backup.rst
new file mode 100755
index 0000000..8b6fc90
--- /dev/null
+++ b/content/Informatique/backup.rst
@@ -0,0 +1,77 @@
+.. -*- mode: rst -*-
+.. -*- coding: utf-8 -*-
+
+Un système de backup automatique
+################################
+
+:date: 2009-10-18
+:tags: Libre
+
+On le sait tous, il faut faire des sauvegardes de manière régulière. On
+le sais également, pour que celles-ci se fasse sur le long terme, il
+faut que celles-ci se fassent de manière automatique, et sur un autre
+support que le PC que l'on souhaite sauvegarder. Le problème qui se pose
+est le suivant : comment concilier ces deux conditions sur un PC de
+bureau ( ne disposant donc pas d'une série de serveur allumés en
+permanences et prêt à recevoir nos sauvegardes en continue… ) ? 
+
+Pour répondre à tout cela, nous allons mettre en place un système de backup sur
+disque dur externe, qui se lancera à chaque fois que notre disque sera monté. À
+chaque fois que le disque dur sera allumé, la sauvegarde s'enclenchera. Cela ne
+garantie pas, bien sûr que les sauvegardes se feront à un intervalle régulier,
+mais cela garantie au moins que nous n'aurons pas à nous en soucier. Pour cela
+nous allons utiliser les outils qui sont disponibles sous un environnement
+Linux : rsync et hal.  Cet article nous présente une base pour faire notre
+sauvegarde `Une sauvegarde améliorée avec rsync
+<http://informatique-et-liberte.tuxfamily.org/2009/05/10/une-sauvegarde-amelioree-avec-rsync/>`_.
+Nous allons juste devoir le modifier un petit peu pour répondre à un problème
+qui arrive souvent avec les périphériques USB : selon que d'autres
+périphériques sont déjà montés ou non, nous ne savons pas dans quel répertoire
+nous allons nous trouve. Il va donc falloir mettre en place une ligne pour
+récupérer le répertoire dans lequel nous sommes. Il ne nous reste plus qu'à
+trouver le moyen de l'éxécuter automatiquement pour cela nous allons utiliser
+halevt. Le script est disponible `ici
+<http://chimrod.com/downloads/backup.sh>`_ 
+
+Comme son nom l'indique, halevt est un gestionnaire d'évènements pour hal. Hal
+est un gestionnaire d'évènement matériel sous Linux; il envoie des informations
+à chaque fois que des informations sont envoyées depuis les composants.  Cela
+permet de détecter le branchement d'un périphérique USB et de le monter sur le
+bureau ( et qui nous simplifie grandement la vie aujourd'hui !!!). Halevt est
+un démon à l'écoute des informations qui nous sont envoyées par hal, et
+d'activer des actions en conséquence : par exemple pour lancer l'antivirus sur
+la clef usb, reconfigurer le mappage du clavier en fonction de la marque que
+l'on branche etc. Pour notre part, nous allons nous contenter de lancer un
+script (celui du backup mentionné plus haut ). 
+
+Pour commencer nous allons devoir identifier le lecteur à mettre sous
+surveillance : inutile de se baser sur les noms de montage habituels ( /dev/sda
+par exemple ) en effet en fonction des périphériques déjà branchés nous
+n'allons pas obtenir la même configuration. Nous allons utiliser les point de
+montage défini dans /dev/disk/by-uuid qui permet d'obtenir l'identifiant
+de notre disque (et qui sera repris par la suite dans la configuration de hal
+).  Une fois que nous avons relevé quel est le disque concerné, il faut mettre
+en place une entrée pour notre évènement dans la configuration de halevt :
+
+::
+
+    <halevt:Device match="hal.block.device &amp; hal.block.is_volume = true &amp; hal.volume.uuid = fd20536f-7b80-4a80-8c3d-b5bebe8fb484">
+    <halevt:Property name="hal.volume.is_mounted">
+    <halevt:Action value="true" exec="bash $hal.volume.mount_point$/chemin/script/backup-ssh.sh"/>
+    </halevt:Property>
+    </halevt:Device>
+
+Cela si halevt est exécuté avec les droits de l'utilisateur lançant le
+backup. Si on le fait tourner en démon, il faut trouver une autre
+solution ( sur mon poste j'ai utilisé sudo, mais on peut très bien se
+baser sur le sticky bit pour donner les droits au script ). De même,
+dans la configuration mise en place, le script se trouve sur le disque
+de stockage ( de manière à pouvoir le lancer à la main si le démon n'est
+pas disponible ), cela peut être adapté en fonction de chacun… 
+
+Dans le cas d'une configuration multi-utilisateur, je pense qu'il est
+nécessaire de passer par un script qui lance les différentes sauvegardes sous
+le bon groupe de l'utilisateur à chaque fois. ( Ce qui en plus permet d'éviter
+le problème du sudo ) mais je n'ai pas eu besoin d'aller jusque là pour
+l'instant ! À vous d'adapter ce que je vous propose en fonction de votre
+configuration !