summaryrefslogtreecommitdiff
path: root/content/Informatique/2009-10-18-backup.rst
blob: 291f18710dede7b8c4e34e74283490e8c24d6859 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
.. -*- mode: rst -*-
.. -*- coding: utf-8 -*-

Un système de backup automatique
################################

:date: 2009-10-18
:tags: Libre, Administration
:summary: |summary|

.. |summary| replace::
    On le sait tous, il faut faire des sauvegardes de manière régulière. On le
    sait également, pour que celles-ci se fassent 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 continu…) ?

|summary|

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
garantit pas, bien sûr que les sauvegardes se feront à un intervalle régulier,
mais cela garantit 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_.

.. _ici: {filename}/resources/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 !