Réécriture de mon script de sauvegarde

Je dois bien réécrire mon script de sauvegarde tous les deux ans. Le premier s’était inspiré d’un article d’artisan Linux et je l’ai publié quelque part mais j’ai oublié où… C’était en 2008, avant je n’avais pas de sauvegarde. Puis, j’ai apporté quelques améliorations qui devaient faire l’objet d’un article en 2010. J’ai encore le brouillon de l’article dans ce blog. Au final, ce billet ne sortira jamais car j’ai écrit une nouvelle version.

Précédemment, mes scripts étaient en bash et basés sur rsync. Comme je n’aime pas réinventer la roue, j’ai cherché des solutions toute faite. Mais je n’ai jamais trouvé chaussure à mon pied. Soit ça ne remplissait pas les critères, soit c’était d’une façon ou d’une autre une usine à gaz. Je garde notamment un mauvais souvenir de rsync-backup dont l’utilisation CPU m’a effrayé.

Rsync est un outil puissant et robuste. J’ai choisi de continuer à l’utiliser. Par contre, le « wrapper » n’est plus un script shell. En effet, la maintenance est vraiment casse-pied car ça devient toujours plus ou moins illisible au coup d’oeil et je n’aimais pas le manque de modularité du code. J’avais plusieurs versions modifiées du même code sur mes divers machines pour tenir compte de telle ou telle spécificité, et ça ce n’est pas une bonne pratique.

Comme j’aime de plus en plus python, j’ai franchi le pas de réécrire le tout. C’est facile à écrire, mais toujours long à mettre en production car je considère ce bout de code comme critique. Cependant, l’étape est sur le point d’être franchie ; il ne me reste que quelques améliorations à faire et les tests sont concluants pour le moment. Voici les spécifications de départ :

Sauvegarde locale ou distante (disque dur externe ou serveur ssh)
Incrémentale ou non
Les incréments sont compressés
Log propres
Réglage de la fréquence (sous la forme du temps minimal pouvant séparer deux sauvegardes)
Réglage du nombre minimal d’archives incrémentales à conserver ET de l’ancienneté de ces archives.
Faible consommation CPU/IO
Minimum de sécurisation : empêcher les doubles processus, gérer au mieux les signaux.

Le code se présente sous la forme d’une bibliothèque qui pourra être utilisée par divers scripts. Chez moi, mes scripts sont sur un git privé et j’ai entre autre home_sauvegarde.py, labo_sauvegarde.py… chacun étant utilisé sur une machine donnée. Ainsi, aucune duplication de code.

L’idée est que le script est lancé fréquemment par une tâche cron. C’est le script qui gère si une sauvegarde doit être réalisée ou non. Selon la source visée, j’ai des besoins différents. En effet, je ne sauvegarde pas de la même façon mes courriels qui bougent sans cesse et mes documents administratifs par ex. Dans le premier cas, je dois copier souvent mais pas garder longtemps car il est très probable que je remarque une corruption rapidement. Pour le second cas, je n’ouvre pas ces documents souvent ; une fausse manipulation peut être détectée des semaines plus tard.

Notez que la suppression des archives se fait sur deux critères. Dans mes premières versions, j’utilisais tmpwatch pour supprimer X jours après création. Le hic survient lorsqu’on part en vacances 15 jours et que X vaut 10 jours. On se retrouve sans historique. Ceci explique la conservation d’un minimum d’archives.

Par la suite, il faut que je dépose une couche de brebis là dessus. Par ailleurs, je dois me pencher sur la question de l’auto-hébergement, à savoir s’il y a des choses intelligentes à ajouter (dump de base de données…)

Si ça peut donner des idées, mon code est déposé ici sous le nom de Vitalus. Oui, les sauvegardes, c’est vital