Elles sont pourtant facile d’accès mais on ne les regarde que peu, ces fameuses photographies numériques. On se dit qu’on les regardera un jour, l’important est qu’elles soient là sous la main. On ne les regarde jamais et pourtant ce serait le drame si elles disparaissaient !
Pour ma part, elles sont stockées sur un NAS en raid 1, en clair, en redondance sur deux disques durs. Si l’un crame, il me reste l’autre. C’est une première garantie, certes mais qui ne protège pas d’un sinistre.
C’est pour parer à cette triste éventualité que j’ai procédé à la mise en place d’une synchronisation avec mon hébergeur extérieur.
Partant du principe que le seul moment où j’aurais besoin de ces fichiers ainsi sauvegardés serait un moment difficile, je voulais un résultat simple. Aucun cryptage, ni d’usage de silos de données (entendre un pool de fichiers compressés avec une indexation).
Cette installation à base de rsync est aussi propre que possible et mérite bien une petite mise en lumière ici.
Nadia Wicker @ Lense Party #13
Préambule
Le contexte à la maison est une raspbian avec un NAS dont les répertoires idoines sont montés. Et, mon hébergeur extérieur me permet d’avoir les accès directs en ssh sur le cluster. C’est pourquoi j’ai choisi rsync comme solution.
Pour cette installation, le rsync
ne sera pas utilisé en démon, mais en lancement ponctuel quotidien. Je suis donc parti du principe que je ne serais pas dans le cas d’une configuration du démon, mais dans un usage particulier de ce service. C’est pourquoi j’ai décidé de créer un profil dédié avec tout le nécessaire dans le home de ce profil.
Pour son nom, j’aurais pu choisir backup, export, photo, ou autre, mais après réflexions, je suis parti du principe que je pourrais avoir d’autres usages de rsync. C’est pourquoi le compte et l’infrastructure seront sous le nom rsync
, alors que l’usage sera sous le nom backup
.
Création du compte de service
La première étape est la création de ce compte rsync
, avec home et sans possibilité de se connecter. Cette dernière clause relève de la sécurité et présentera des inconvénients d’installation que je contournerai lors de la planification.
sudo useradd -m -s /bin/false rsync
Préparation de l’infrastructure
Elle se limite à la création des répertoires de logs et de run.
sudo mkdir /var/log/rsync
sudo chown rsync:rsync /var/log/rsync
sudo mkdir /run/rsync
sudo chown rsync:rsync /run/rsync
Ce dernier répertoire servira pour le fichier pid qui portera le nom de la liste en cours de synchronisation (par défaut backup
).
Scripts et compagnie
Le gros de la mise en place est celle du script que je vous propose directement, avec le fichier de configuration et le fichier de liste qu’il faudra ajouter.
En clair, il vaut mieux récupérer le script que je propose : backup by oloc .
Directement à partir du Raspberry :
cd /home/rsync
sudo wget http://olivierlocard.com/share/scripts/backup
sudo chmod 750 /home/rsync/backup
sudo chown rsync:rsync /home/rsync/backup
Auquel il faut ajouter les deux autres qui seront si je prends pour exemple la racine photos les deux fichiers photos.conf
et photos.lst
.
Le fichier de liste (en .lst) doit comporter les répertoires à sauvegarder à raison d’un par ligne. Dans le cas des photos stockées sur le NAS ce seront des /mnt/gugus/photos
(un bien bel exemple).
Celui nommé backup.lst (tiré du nom du script utilisé) sera celui par défaut et sera pris en compte si aucune liste n’est spécifiée lors du lancement de la commande.
Le fichier de configuration doit contenir :
L’hébergeur et la clef SSH
Pour celles et ceux qui auraient lu le script ou qui aurait procédé à un petit test, ils auront vu qu’il faut mettre en place une clef SSH.
Chez mon hébergeur le mot de passe SSH est celui du FTP. Les paramètres de connexions sont ceux que l’on a remplis dans le fichier de configuration. On vérifie tout ça par :
ssh olivier@cluster123.hebergeur.com
Une fois connecté on crée le répertoire .ssh s’il n’existe :
mkdir .ssh
chmod 700 .ssh
Sur notre framboise (à adapter avec le nom du raspberry), on crée la clef ssh et on l’envoie :
sudo ssh-keygen -t rsa -b 2048 -f /home/rsync/.ssh/rsync-key -C rsync@framboise
sudo scp /home/rsync/.ssh/rsync-key.pub olivier@cluster123.hebergeur.com:.ssh
Enfin sur l’hébergement :
cd .ssh
cat rsync-key.pub >> authorized_keys
chmod 600 authorized_keys
Planification
Afin de mettre à jour régulièrement, j’utilise la crontab du profil dédié. Etant donné qu’on ne peut se connecter avec ce profil (pour cause de /bin/false), je contourne par :
sudo –u rsync crontab -e
Vous trouverez de la documentation détaillée sur le sujet, et pour l’instant je fournis les paramètres pour lancer la synchronisation avec la liste backup.lst (par défaut) puis avec une liste voyages.lst à 01:00 tous les jours :
00 01 * * * /home/rsync/backup
00 01 * * * /home/rsync/backup voyages
Merci Olivier ça va bien m’aider ! Juste une critique néanmoins, le RAID1 n’est en rien une solution de sauvegarde mais simplement de la haute disponibilité. Il ne faut pas lui faire confiance 🙂
Au lieu de garder les logs un certain temps, je préfère en garder un certain nombre, la méthode est universelle pour les quotidiens, hebdomadaires, mensuelles, etc.
Mise à jour du script pour supprimer toutes les logs « supplémentaires » au-delà de 7. En d’autres termes ne garder que les 6 dernières.
Cette constante est en ligne 12 et appelée MoreThan, à charge à chacun de la valoriser selon le besoin.
MoreThan=7
Ajout en ligne 90 :
# Remove of the extra logs
_echo « Remove of the extra logs (more than ${MoreThan}) in progress… »
ls -1t ${LogDir}/* | tail -n +${MoreThan} | xargs rm -r | tee -a ${LogFile}
_echo « Remove of the extra logs (more than ${MoreThan}) done. »