Planet Ubuntu Francophone - Sauvegarde

Sauvegarde cryptée sous Ubuntu

Cedynamix — Mon, 09 Jun 2008 14:38:52 +0200

Voici la traduction d’un très bon tuto en italien du Blog Haumako que j’ai suivi pour faire ma procédure de sauvegarde.

Ce constat n’est pas nouveaux, mais une sauvegarde périodique de notre travail est essentielle pour prévenir une possible perte de données liée à une défaillance de de disque dur, un vol ou encore un effacement accidentel. De plus et dans la plupart des cas, les données que nous voulons sauvegarder contiennent des informations privées, des projets en cours de réalisation ou bien encore des documents confidentiels venant de notre société. Voilà donc pourquoi crypter ses sauvegardes, est quelque chose d’important. Nous verrons dans cet article comment créer une procédure de sauvegarde simple et automatique sous Ubuntu (et Linux en général) avec les outils d’archivage (tar) et de cryptographie (gpg).

Avant de procéder à la réalisation de ce script, il me paraît intéressant de présenter dans les grandes lignes le fonctionnement et la manière dont on va utiliser tar et gpg. Pour ceux qui sont déjà des familiers de ces 2 outils, vous pouvez passer directement à la partie réalisation de la procédure de sauvegarde.

Tar

Tar est un des premiers outils qu’un utilisateur de système Linux apprend à connaître. Une de ses caractéristiques tient dans la possibilité d’archiver de manière séquentielle les fichiers dans une archive unique. Nous utiliserons cet outil pour créer un fichier temporaire contenant tous les fichiers que l’on souhaite sauvegarder, de façon à rendre le cryptage plus facile avec gpg.

Gpg

Gpg est la version open-source du célèbre pgp. Il permet une cryptographie asymétrique de données grâce à un couple de clés, une clé publique et une clé privée. Grâce à la clé publique il est possible de crypter des informations, sans mot de passe. Par contre, avec la clé privée et une fois entré le mot de passe, il est possible décrypter ces mêmes données.

Cette caractéristique est employée par beaucoup de personnes pour sécuriser l’échange d’informations privées (courriel, messagerie instantanée, etc.). Pour que nos correspondants puissent nous envoyer des données cryptées, il nous suffit de leurs fournir notre clé publique (appelée clé esclave) qui sert uniquement à crypter les données. Une fois reçues les informations cryptées , nous utiliserons notre clé privée, qui, couplée avec le mot de passe, nous permettra d’en décrypter le contenu.

Nous utiliserons la clé publique gpg pour crypter nos archives comme cela, nous ne serons pas obligés d’insérer à chaque sauvegarde le mot de passe ou, pire encore, nous ne serons pas obligés de le mémoriser en clair dans le script. Pour conclure, vu que rien ne sera demandé à chaque exécution du script, il pourra être exécuté en arrière plan et c’est ce que je veux !

Création d’une clés gpg

Pour ceux qui possède déjà un couple de clés ( je m’adresse entre autre au Ubunteros possédant un compte Launchpad), je vous conseille quand même d’en créer une nouvelle de façon à la réserver uniquement pour la procédure de sauvegarde.

Il existe divers moyens graphique pour la création d’un couple de clés, mais j’utiliserai la ligne de commande parce que c’est la méthode la plus rapide.

Nous ouvrons un terminal et exécutons la commande suivante :

gpg --gen-key

gpg vous demandera les options pour la création de la clé, vous pouvez très bien laisser celles par défaut. Pour le mot de passe, je vous conseille d’en créer un assez compliqué.

Réalisation du script

Voyons maintenant le script qui s’occupera de créer le fichier de sauvegarde crypté dans le répertoire de notre choix. Mettez la commande suivante dans un fichier :

#! /bin/sh tar -cf /emplacement/fichier/backup.tar -X /emplacement/fichier/exclude.txt /emplacement/asauvegarder gpg –yes -e -r “nom_clé” backup.tar

Explication

La première commande s’occupe de créer l’archive tar contenant tous les fichiers que l’on tient à sauvegarder. Le fichier exclude.txt avec l’option -X permet de ne pas inclure dans l’archive tous les dossiers et fichiers qu’il contient (ceux dont vous ne voulez pas) et que vous aurez rempli au préalable. Ils devront être écrit ligne par ligne, avec le chemin relatif au dossier ou fichier que vous voulez exclure de votre sauvegarde.

Par exemple, supposons que l’on veuille effectuer une sauvegarde du dossiers “documents” avec l’arborescence suivante :

Et que nous voulons exclure tous les fichiers et dossiers temporaires, on devra écrire dans le fichier exclude.txt :

~*
.*
temp
projet/projet-temp

La seconde commande crypte l’archive temporaire tar précédemment créée avec la clé indiquée (votre clé) après l’option -r. L’option –yes sert à répondre oui par défaut à toutes les questions pendant le processus de cryptage. Elle est nécessaire, car dans le cas ou un ancien fichier crypté existerait déjà, gpg nous demandera si il faut ou non écraser ce fichier. Notre but étant d’avoir une procédure de sauvegarde totalement transparente, nous réglons donc ce problème pour que gpg puisse toujours écraser un ancien fichier présent, si il existe.

Gpg compresse automatiquement le fichier de sortie avec gzip, nous n’avons donc pas à nous préoccuper de compresser le fichier de sauvegarde après l’opération de cryptage!

Pour éviter de taper à chaque sauvegarde ces commandes, nous les sauvegardons dans un fichier de test, en lui octroyant les permissions d’exécution.

Automatisation du script avec crontab

Nous pouvons automatiser cette sauvegarde en incluant une ligne dans contab qui lancera du fichier que nous venons juste de créer. Pour effectuer cette opération accédons à crontab par cette commande :

crontab -e

et nous tapons :

*/20 * * * * /emplacement/fichier/backup-script.sh

*/20 indique à crontab d’exécuter le script toutes les 20 minutes. Vous pouvez changer cette option comme bon vous semble si cela ne vous convient pas (consultez le manuel de crontab pour savoir comment modifier les données de démarrage du script).

Script de sauvegarde avancé

La méthode décrite jusqu’à présent est basée sur un script simple mais très efficace. Nous allons voir maintenant comme le faire évoluer pour exécuter la sauvegarde sur un média externe (Clé Usb, SDCard ou encore disque dur externe).

Pour rendre cette procédure intelligente, nous voulons que le script soit exécuté seulement quand le média externe est connecté et monté. Pour faire cela, on va tester à l’intérieur du script la présence de ce média externe. Dans le script qui suit, vous verrez cependant qu’il vient tester l’existence d’un répertoire sur le média externe pour éviter que le sauvegarde se fasse sur un autre périphérique monté avec le même nom.

Le script final sera le suivant :

#! /bin/sh BACKUP_SCRIPT_PATH=/emplacement/fichier/script BACKUP_DIR=/emplacement/dossier/backup EXTERNAL_DRIVE=/emplacement/média/externe/ if [ -d $EXTERNAL_DRIVE/backups ]; then tar -cf $BACKUP_DIR/nomarchive.tar -X $BACKUP_SCRIPT_PATH/exclude.txt \ /emplacement/dossier/backup/1 \ /emplacement/dossier/backup/2 \ … 1> /dev/null 2> $BACKUP_SCRIPT_PATH/errors.log # redirection du fichier de log en cas d’erreur gpg –yes -e -r “nom_clè” $BACKUP_DIR/nomarchive.tar rm $BACKUP_DIR/nomarchive.tar cp $BACKUP_DIR/nomarchive.tar.gpg $EXTERNAL_DRIVE/backups fi

Dans ce script on teste la présence du répertoire backups sur la média externe (à créer bien sûr), on créé l’archive temporaire, on crypte cette même archive temporaire, on supprime l’archive temporaire et pour terminer on copie l’archive cryptée dans le répertoire backups sur le média externe.

Rappelez-vous que l’archive temporaire sert uniquement à faciliter le cryptage, qui s’effectuera de cette manière, sur un seul et unique fichier. Gpg créera un fichier de type nomarchive.tar.gpg qui sera copié dans le répertoire backup.

On pourrait accélérer la création du tar en faisant une mise-à-jour de l’archive plutôt que de la créer de nouveau à chaque run (dans ce cas elle ne devra évidemment pas être éliminée après le cryptage). Cette possibilité est réalisable en substituant l’option -c avec -u dans la commande tar (qui deviendra donc tar -uf).

Sauvegardes extensives

Administrateur — Sat, 08 Dec 2007 16:35:00 +0100

Effraie.org héberge pas mal de sites, et la question des sauvegardes est devenue cruciale.
Bien sur, je pourrais renvoyer les utilisateur-ices à leur responsabilités, et leur demander de faire leurs propres sauvegardes. Cela dit, rien ne dit qu'elles/ils les fassent régulièrement, ni qu'ils sachent comment sauvegarder une base de données.

Je me suis donc penché sur la question, et j'ai amélioré mon rsync quotidien pour obtenir un système qui me convient mieux,

Pour assurer que les données seront à l'abri en cas de crash des disques durs internes, mon répertoire backups/ est situé sur un disque usb externe. Prochainement, je cherche également à automatiser une sauvegarde de ce répertoire sur un serveur distant

Sauvegardes des bases de données

J'utilise, suivant les conseils avisé d'un copain, le script autoMYSQLBackup.sh qu'on trouve ici. Après configuration de quelques variables, le script est opérationnel, et il ne vous reste qu'a le lier dans /etc/cron.daily/ pour obtenir une sauvegarde automatisée de chacune de vos bases. Le script conserve les backups des derniers 7 jours, une par semaine pendant un mois, et une par mois indéfiniment.
Au final, cela me permet de conserver une trace des données sur le long terme, sans pour autant user une espace disque démesuré, dans backups/sql.

Sauvegardes des données:

Pendant longtemps, je me suis contenté d'utiliser rsync pour sauvegarder les données du serveur. Cependant, je souhaitais bénéficier, comme pour les bases de données, de la possibilité de restaurer une sauvegarde plus ancienne. Pour cela, j'ai utilisé des outils standards, rsync, cp, rm, date, find et crontab.

Le fonctionnement est simple:

sauvegarde principale:

Chaque nuit, à 2h30, je sauvegarde l'ensemble des données que je veux pouvoir restaurer dans un répertoire backups/main, avec le "mini script" suivant, qui synchronise la racine du serveur avec ma sauvegarde:


#!/bin/sh
rsync -azh  --exclude=/pattern/à/ne/pas/sauver --exclude=/dev --exclude=/proc --exclude=/tmp --exclude=/sys   --delete-after --delete-excluded --stats / /chemin/vers/backups/main

et cette ligne dans la crontab de root:

30 02  *  *  * /chemin/vers/le/script/main_backup 2>&1 | mail votre@email.tld -s "[Rsync] rapport du `date +%A\ %d\ %B\ %Y`"

Je reçois ainsi chaque jour un rapport statistique sur la synchronisation, de cette forme:


Number of files: 208552
Number of files transferred: 1038
Total file size: 8.23G bytes
Total transferred file size: 354.84M bytes
Literal data: 354.86M bytes
Matched data: 0 bytes
File list size: 6230145
File list generation time: 98.647 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 70.71M
Total bytes received: 24.00K

sent 70.71M bytes  received 24.00K bytes  344.18K bytes/sec
total size is 8.23G  speedup is 116.42

En cas de problème, le mail contient la sortie d'erreur de la commande.

Journalisation des sauvegardes

Pour pouvoir restaurer des sauvegardes plus anciennes, ou des fichiers effacés il y a plusieurs jours sur le serveur (et donc absent de backups/main), j'utilise trois petits scripts simplistes, qui, associés à une ligne adéquate dans la crontab de root, me permettent de conserver l'ensemble des sauvegardes des 7 derniers jours, une sauvegarde par semaine pendant un mois, et une sauvegarde par mois pendant 6 mois.

Voici les scripts et les entrées dans la crontab qui vont avec:

daily_backup

le script:

#!/bin/sh
find /chemin/vers/backups/timed/daily/* -ctime +7 -exec rm -rf {} \;
cp -al /chemin/vers/backups/main /chemin/vers/backups/timed/daily/`date +%F` 2> /dev/null;

L'entrée dans la crontab:

30 03  *  *  * /home/effraie/scripts/daily_backup

weekly_backup

le script:

#!/bin/sh
find /chemin/vers/backups/timed/weekly/* -ctime +33 -exec rm -rf {} \;
cp -al /chemin/vers/backups/main /chemin/vers/backups/timed/weekly/`date +%U_%F` 2> /dev/null;

L'entrée dans la crontab:

40 03  *  *  0 /home/effraie/scripts/weekly_backup

monthly_backup

Le script:

#!/bin/sh
find /chemin/vers/backups/timed/monthly/* -ctime +183 -exec rm -rf {} \;
cp -al /chemin/vers/backups/main /mnt/usb-data/backups/timed/monthly/`date +%m-%Y` 2> /dev/null;

L'entrée dans la crontab:

50 03  1  *  * /home/effraie/scripts/monthly_backup

Avec ça, je pense être habillé pour l'hiver! Cela dit, toute suggestion d'amélioration est la bienvenue.

Sauvegardes extensives

effraie — Sat, 08 Dec 2007 15:35:00 +0100

Sauvegardes des bases de données

Sauvegardes des données:

sauvegarde principale:

#!/bin/sh
rsync -azh  --exclude=/pattern/à/ne/pas/sauver --exclude=/dev --exclude=/proc --exclude=/tmp --exclude=/sys   --delete-after --delete-excluded --stats / /chemin/vers/backups/main

et cette ligne dans la crontab de root:

30 02  *  *  * /chemin/vers/le/script/main_backup 2>&1 | mail votre@email.tld -s "[Rsync] rapport du `date +%A\ %d\ %B\ %Y`"

Je reçois ainsi chaque jour un rapport statistique sur la synchronisation, de cette forme:


Number of files: 208552
Number of files transferred: 1038
Total file size: 8.23G bytes
Total transferred file size: 354.84M bytes
Literal data: 354.86M bytes
Matched data: 0 bytes
File list size: 6230145
File list generation time: 98.647 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 70.71M
Total bytes received: 24.00K

sent 70.71M bytes  received 24.00K bytes  344.18K bytes/sec
total size is 8.23G  speedup is 116.42

En cas de problème, le mail contient la sortie d'erreur de la commande.

Journalisation des sauvegardes

Note ajoutée à la suite de quiproquo dans les commentaires
Le systéme de journalisation/rotation des backups utilise l'option -l de cp, pour créer des hardlinks au lieu de recopier les fichiers, dans tt les cas ou le fichier n'a pas été modifié. C'est le moyen de n'utiliser que l'espace disque minimum requis. Compresser les données dans une archive ferait perdre cet avantage, et utiliserait, finalement, plus d'espace disque.

Voici les scripts et les entrées dans la crontab qui vont avec:

daily_backup

le script:

#!/bin/sh
find /chemin/vers/backups/timed/daily/* -ctime +7 -exec rm -rf {} \;
cp -al /chemin/vers/backups/main /chemin/vers/backups/timed/daily/`date +%F` 2> /dev/null;

L'entrée dans la crontab:

30 03  *  *  * /home/effraie/scripts/daily_backup

weekly_backup

le script:

#!/bin/sh
find /chemin/vers/backups/timed/weekly/* -ctime +33 -exec rm -rf {} \;
cp -al /chemin/vers/backups/main /chemin/vers/backups/timed/weekly/`date +%U_%F` 2> /dev/null;

L'entrée dans la crontab:

40 03  *  *  0 /home/effraie/scripts/weekly_backup

monthly_backup

Le script:

#!/bin/sh
find /chemin/vers/backups/timed/monthly/* -ctime +183 -exec rm -rf {} \;
cp -al /chemin/vers/backups/main /mnt/usb-data/backups/timed/monthly/`date +%m-%Y` 2> /dev/null;

L'entrée dans la crontab:

50 03  1  *  * /home/effraie/scripts/monthly_backup

Avec ça, je pense être habillé pour l'hiver! Cela dit, toute suggestion d'amélioration est la bienvenue.