Sauvegarde vers Backblaze B2 avec duplicity

Étant donné les difficultés rencontrées lors de la dernière restauration de mon serveur à partir des données sauvegardées dans hubic, mais également lors de la tentative de restauration précédente, je suis parti à la recherche d’un second lieu de sauvegarde. Après quelques recherches, je me suis décidé à essayer le service fournit par la société Backblaze, en particulier avec sa solution B2 Cloud Storage.

Parmi les points qui m’ont orienté ma décision, on notera :

  • la compatibilité avec duplicity, outil que j’utilise actuellement pour réaliser mes sauvegardes.
  • 10 GB de stockage gratuit
  • Pas de nécessité de saisir des informations de paiement pour pouvoir tester.
  • Un coût de stockage de 0,005$ par GB et par mois.

Du côté tarification, nous sommes proches de ce qu’on retrouve du côté d’Amazon Glacier qui propose une tarification à 0,004$ par Go/mois pour le choix des régions de stockage les moins chers. Si les offres Amazon peuvent également être intéressantes, mais l’utilisation avec duplicity n’est pas disponible en l’état. De plus, il semble que la difficulté se situe au minimum du côté de l’option verify qu’il faudrait désactiver car comptant comme une demande de restauration. Une autre difficulté se situe du côté de la restauration des fichiers à proprement parlé, étant donné le temps nécessaire à Glacier pour rendre les fichiers disponibles après leur sauvegarde. Bref, à tester, mais dans un autre contexte.

Passons à la configuration de duplicity pour B2. Une version de duplicity v0.7.12 ou plus récente est nécessaire. La vérification s’effectue avec :

duplicity --version

La version installée sur mes serveurs depuis les dépôts de Debian était trop ancienne, j’ai donc compilé le programme à partir des sources du projet disponible sur le site du projet. Après récupération du dossier compressé des sources, petit tour dans le README pour prendre connaissance des pré-requis et des instructions de compilation. On procède donc à l’installation des dépendances demandées :

sudo aptitude install python-dev librsync-dev intltool python-fastener

Passage ensuite à l’étape de compilation, après décompression des sources :

python setup.py build

Puis désinstallation de la version en provenance du gestionnaire de paquet et installation de la version compilée à l’instant.

sudo aptitude remove duplicity
sudo python setup.py install

Enfin, vérification de la version de duplicity installée et vérification de l’emplacement de l’exécutable.

duplicity --version
which duplicity

Après mon premier test de sauvegarde, j’ai noté que les composants suivants sont également nécessaires au bon fonctionnement de duplicity avec B2 :

pip install b2
pip install backports.functools_lru_cache

À ce stade, on peut passer à un premier test de sauvegarde vers la solution de stockage de Backblaze. La commande duplicity reste des plus classiques et prends la forme suivante :

duplicity ~ b2://[applicationKeyId]:[application key]@[B2 bucket name]

Attention, la clé d’application doit être sauvegardée dans un endroit sûr, au hasard, dans son gestionnaire de mot de passe préféré. En effet, une fois la fenêtre contenant la clé fermée, il n’est plus possible d’afficher la clé et une nouvelle clé devra être générée en cas de perte de la première.

Autre point, la documentation Backblaze est en partie erronée dans la structure de la commande duplicity proposée, puisque y est fait mention d’un paramètre account_id en lieu et place du paramètre applicationKeyId ci-dessus. C’est bien ce dernier paramètre qu’il faut choisir, car utiliser l’account_id ne conduira qu’à des erreurs d’autorisation et à de la frustration

Quelques lignes encore pour terminer cet article. Je dispose désormais d’une double sauvegarde de mes serveurs vers hubic et maintenant B2. Le volume de données sauvegardées n’excède pas, pour l’instant, la tranche gratuite du service. Par la suite, j’envisage de tester d’autres outils de sauvegarde en particulier Restic et Borg. En outre le coût relativement faible du stockage m’encourage à envisager la sauvegarde externe de données froides comme mes photos numériques et ma bibliothèque de musique. La réflexion suit son cours.

Citation [9] – Patricia Briggs

Il était plus petit que la moyenne, et paraissait dix ans de moins que son âge réel. Il s’habillait modestement et observait plus qu’il parlait. Phöran l’avait tout d’abord considéré comme un homme impassible, aussi vrai que l’acier, certes, mais qui devait beaucoup réfléchir avant d’agir. C’était le cas, sauf qu’il réfléchissait très vite.

Corbeau – Patricia Briggs

Il avait toujours su qu’elle l’aimait, lui, autant qu’elle aimait leurs enfants. Mais il savait aussi également que depuis l’enfance, on l’avait entraînée à maîtriser ses émotions; et que l’intensité des sentiments qu’elle éprouvait la perturbait beaucoup. C’est justement parce qu’il la connaissait si bien, et qu’il la comprenait, qu’il ne l’avait jamais poussée à lui avouer ce qu’il savait déjà.

Corbeau – Patricia Briggs

Le problème, c’est qu’elle ne savait pas quoi dire. Il lui arrivait rarement d’être maladroite, pourtant. Mais c’était devenu une habitude ces derniers temps, lorsqu’il était à côté d’elle. Elle n’était pas bavarde comme Tiër et se plaisait dans ses silences. Ou, du moins, était-ce ce qu’elle avait cru. A présent, elle avait envie de parler à Jës, mais ne savait pas quoi dire, ni comment le dire. Elle préféra donc se taire.

Corbeau – Patricia Briggs

Formatage de code avec husky et prettier

Petit point rapide pour la mise en place d’un formatage automatique des portions de code modifiées au moment du commit (en environnement JS : Angular/Node).

Installation des dépendances :

npm install --save-dev husky prettier precise-commits

Configuration à ajouter dans package.json :

"husky": {
  "hooks": {
    "pre-commit": "precise-commits"
  }
},

À noter que prettier n’arrive pas toujours à formater un extrait de fichier JSON, l’intérêt de precise-commits peut s’en voir grandement diminuer si le projet contient de nombreux fichiers JSON régulièrement modifiés.

Modification des informations d’auteur d’un commit

Après avoir récupéré l’ensemble de mes dépôts git avec repo, je souhaitais effectuer un peu de « nettoyage » dans mes informations d’auteur de commit afin de les harmoniser. Bien entendu, cette opération n’est pas du tout neutre puisqu’elle implique une réécriture de l’historique, et dans le cas d’un changement d’email, cela concerne chaque SHA-1 des commits de l’historique (car un commit contient le SHA-1 de son parent).

Intéressons-nous à la commande de changement des informations d’auteur à proprement parler. Celle-ci est extraite de la documentation de github (si besoin, en cas d’opération successive, ajouter l’option -f avant –env-filter):

$ git filter-branch --env-filter '

OLD_EMAIL="your-old-email@example.com"
CORRECT_NAME="Your Correct Name"
CORRECT_EMAIL="your-correct-email@example.com"

if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
then
    export GIT_COMMITTER_NAME="$CORRECT_NAME"
    export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
then
    export GIT_AUTHOR_NAME="$CORRECT_NAME"
    export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags

Avant d’être en mesure de réécrire les commits, on commence par déterminer les informations existantes à l’aide de la commande suivante (que l’on pourra par ailleurs exécuter sur tous les dépôts avec repo forall -c <commande>) :

git log | grep Author: | sort | uniq

Une fois les changements terminés, on pousse ces derniers vers le serveur:

git push --force --tags origin 'refs/heads/*'

En cas de message du type :

erreur fatale: 'origin' does not appear to be a git repository

Il convient de vérifier le remote configuré avec git remote -v, soit dans mon cas :

github  ssh://git@github.com/vvision/eslint-config (fetch)
github  ssh://git@github.com/vvision/eslint-config (push)

On remplace alors origin par github dans la commande git push et le tour est joué (configuration héritée de repo).

De cette manière, l’ensemble de mes dépôts dispose désormais des informations de contact nettoyées.

Gestion des dépôts git

Au fil des années, j’ai accumulé pas loin de 70 dépôts git, certains presque vides, d’autres contenant des instructions de déploiement de service, ou encore, mes divers essais successifs pour me familiariser avec l’une ou l’autre technologie. Lors de la panne récente de mon serveur auto-hébergé, j’ai craint un moment d’avoir perdu une partie du code produit ces dernières années. Heureusement, cela ne fut pas le cas.

Bien sûr, une partie des dépôts est toujours présente dans un coin de mon disque dur, bien que n’ayant pas été l’objet de modification récente, et m’assure ainsi une sauvegarde locale de ces derniers: une n-ième duplication. Continuant le chemin du côté de ma résilience numérique, je me suis donc intéressé au moyen de conserver facilement l’ensemble de mes dépôts git en local. Pour arriver un résultat satisfaisant, je me suis donc tourné vers repo, programme écrit par Google pour gérer les dépôts Android et que j’avais eu l’occasion de découvrir durant mes études d’ingénieur.

J’ai donc ajouté un nouveau dépôt à ma liste, contenant un readme et un fichier default.xml. Le fichier default.xml suit les règles de syntaxe des fichiers manifest de repo et liste désormais l’ensemble de mes dépôts git. En voici une version simplifiée :

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <remote name="github" fetch="ssh://git@github.com/vvision" />
  <default revision="master" remote="github" sync-j="4" />

  <project name="eslint-config" />
  <project name="manifest" path="manifest/manifest" />
  <project name="prettier-config"/>
</manifest>

Quelques commentaires. Je commence par définir un remote, endroit où récupérer mes dépôts, lui donne un nom et précise l’url utilisée pour la récupération d’un dépôt. Je définis ensuite les paramètres par défaut en précisant ici que je souhaite récupérer la branche master, en utilisant la configuration du remote nommée github et en autorisant 4 jobs concurrents pour les opérations de synchronisation. Reste ensuite à définir les dépôts à récupérer, le paramètre minimum étant le nom du dépôt sur le serveur distant. À noter également la présence du paramètre path qui permet de choisir l’emplacement final du contenu du dépôt, ce qui se révèle d’une grande utilité pour grouper ses dépôts dans différents répertoires.

Une fois le fichier manifest complété et pousser dans son dépôt distant, on peut commencer la récupération de la liste de dépôts en utilisant successivement les commandes :

repo init -u git@github.com:vvision/manifest.git

Puis :

repo sync

À l’issue de l’exécution de cette deuxième commande, on dispose désormais de l’ensemble des dépôts définis dans le manifest sur le disque local et cela de manière totalement automatique. On notera en particulier la présence de l’instruction status permettant d’avoir un aperçu de l’état des dépôts et l’instruction forall permettant d’exécuter une commande sur l’ensemble des dépôts.

Sources :