summaryrefslogtreecommitdiff
path: root/content/Informatique/backup.rst
diff options
context:
space:
mode:
authorSébastien Dailly <sebastien@chimrod.com>2013-04-20 08:28:02 +0200
committerSébastien Dailly <sebastien@chimrod.com>2013-04-20 08:28:02 +0200
commit91149dfb9162ff362c3d40472e68738adc22a75a (patch)
tree4b930c599bed665a9295eb7167c9d16f9295f36e /content/Informatique/backup.rst
parentefcdd3df19abc46a40444a90d5e01398002b139b (diff)
Grammar correction
Diffstat (limited to 'content/Informatique/backup.rst')
-rwxr-xr-xcontent/Informatique/backup.rst30
1 files changed, 15 insertions, 15 deletions
diff --git a/content/Informatique/backup.rst b/content/Informatique/backup.rst
index 8b6fc90..2e71f9e 100755
--- a/content/Informatique/backup.rst
+++ b/content/Informatique/backup.rst
@@ -8,18 +8,18 @@ Un système de backup automatique
: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
+le sais é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 continue… ) ?
+bureau (ne disposant donc pas d'une série de serveur allumés en
+permanences et prêt à recevoir nos sauvegardes en continu…) ?
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
+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
@@ -37,16 +37,16 @@ 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
+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 ).
+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
+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
@@ -63,15 +63,15 @@ en place une entrée pour notre évènement dans la configuration de halevt :
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,
+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…
+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
+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 !