Dans un de mes précédents billets, j’avais détaillé une méthode possible pour utiliser l’espace de stockage Hubic (proposé par OVH à un tarif défiant toute concurrence) pour y stocker à moindre frais ses backups Duplicity.

La méthode, proposée au départ par Gu1, consistait à patcher la librairie python-cloudfiles, en utilisant une librairie modifiée par Gu1 (et très légèrement corrigée par mes soins) pour s’adapter à la phase d’authentification de Hubic et supporter l’OAuth.

Or la librairie python-cloudfiles a depuis été dépréciée par Rackspace au profit de Pyrax (Rackspace Cloud Files Python Api). C’est d’ailleurs pour supprimer le warning indiquant que python-cloudfiles était dépréciée que j’avais corrigé le patch proposé par Gu1.
 

Changement introduit dans Duplicity 0.6.23 : support de Pyrax et dépréciation de python-cloudfiles

A la suite de mon billet détaillant la méthode pour utiliser cette solution un peu “workaround”, certains lecteurs m’ont fait remonter que depuis la version 0.6.23 de Duplicity, c’est Pyrax qui est utilisé à la place du backend cloudfiles, ce que l’on voit d’ailleurs dans le détail des modifications apportées à Duplicity :
Changed to default to pyrax backend rather than cloudfiles backend. To revert to the cloudfiles backend use '--cf-backend=cloudfiles'

Le problème est que l’option cf-backend n’est apparemment plus supportée malgré le fait qu’elle est toujours mentionnée dans le man de Duplicity, produisant ainsi une erreur du type : duplicity: error: no such option: --cf-backend.

Inlassablement, on se retrouvait donc avec un joli message d’erreur : BackendException: This backend requires the pyrax library available from Rackspace.

Une fois ce problème identifié il restait deux solutions : downgrader Duplicity (sur une version < 0.6.23) pour conserver un fonctionnement correct avec la librairie python-cloudfiles corrigée par mes soins ou trouver un moyen d’implémenter le support de l’authentification OAtuh Hubic dans Pyrax.

C’est sur ce dernier point que Gu1 nous sauve une nouvelle fois la mise, en ayant réalisé un module d’authentification Pyrax pour Hubic, qu’il ne restait qu’à intégrer dans les backends gérés par Duplicity, ce qui est le cas depuis une révision récente de Duplicity.
 

Etape 1 : Installer une version de Duplicity prenant en charge le module d’authentification Pyrax pour Hubic

Comme je l’indiquais plus haut, le module d’authentification Pyrax pour Hubic réalisé par Gu1 a été intégré dans une révision récente de Duplicity, et n’est donc pas à ce jour encore disponible dans les gestionnaires de type apt-get ou aptitude.

Nous allons donc devoir procéder à une installation “manuelle” de Duplicity.

La première chose à faire pour éviter tout conflit, si vous utilisez une version ancienne de Duplicity, est de la désinstaller. Si vous l’avez installée avec apt-get faites ainsi dans votre console :

apt-get purge duplicity

et validez.

Pour procéder à l’installation de la nouvelle version, nous allons commencer par préparer notre machine en installant les outils nécessaires et toutes les dépendances :

apt-get update
apt-get upgrade
apt-get install python-setuptools 
apt-get install git
apt-get install python-pip python-dev build-essential
apt-get install librsync1
apt-get install ncftp
apt-get install lftp
apt-get install librsync-dev
apt-get install openstack-dashboard

Le développement de Duplicity étant réalisé sur Bazaar, nous allons également installer l’outil correspondant :

apt-get install bzr

Nous procédons ensuite à l’installation de Pyrax avec pip, puis faisons un petit update des outils liés :

pip install pyrax
pip install --upgrade pyrax

Nous allons maintenant utiliser bzr pour pouvoir récupérer directement depuis le dépôt la version de Duplicity qui nous intéresse

cd ~
bzr branch lp:duplicity

Et maintenant, il ne reste qu’à lancer l’installation de Duplicity à proprement parler :

cd duplicity
./setup.py install
cd ~
rm -R ~/duplicity

Si vous n’avez aucune erreur, vous pouvez passer à la suite …
 

Etape 2 : Créer le fichier ~/.hubic_credentials contenant les données d’authentification pour Hubic

Pour se connecter à Hubic, comme l’indique le man de Duplicity, il va nous falloir créer à la racine du répertoire home de l’utilisateur concerné (ici root) un fichier ~/.hubic_credentials qui contiendra les données permettant d’utiliser l’OAuth.

Ce fichier sera du type :

[hubic] 
email = your_email 
password = your_password 
client_id = api_client_id 
client_secret = api_secret_key 
redirect_uri = http://localhost/

Si vous n’avez pas les informations nécessaires, reportez-vous à l’étape 2 de mon billet précédent sur Hubic et Duplicity.

Pensez à limiter les droits d’accès à ce fichier, car il contient tout de même les données de connexion à votre espace Hubic :

chmod 700 ~/.hubic_credentials

Etape 3 : Tester Duplicity avec ce nouveau support pyrax pour HubiC

Pour réaliser un premier petit test, vous pouvez lancer un backup du répertoire home de l’utilisateur root :

# Lançons une première sauvegarde de test du home folder de root
duplicity /root cf+hubic://default
# Observons l'état
duplicity collection-status cf+hubic://default
# Listons les fichiers distants 
duplicity list-current-files cf+hubic://default
# Testons la restauration d'un fichier (changez les noms !!!)
duplicity --file-to-restore /etc/ cf+hubic://default /tmp/bash_alias_recup

Pour réaliser le backup, il vous sera demandé d’entrer une passphrase (utilisée pour le chiffrement). Vous pouvez en générer une ici en créant un mot de passe de 50 caractères par exemple.

Pour vérifier que tout fonctionne, vérifiez en ligne avec votre navigateur favori sur votre espace HubiC que les volumes de backup ont été uploadés.

Vous devriez trouver là toute une liste de fichiers commençant pas « duplicity-****** ».
Sélectionnez-les tous et supprimez-les puisqu’il ne s’agit que d’un upload réalisé pour nos tests :

Ensuite nous allons faire un peu de ménage en local pour supprimer aussi les traces de ce test dans le cache de Duplicity :

duplicity cleanup cf+hubic://default

Comme l’explique David Mercereau sur son blog, il ne e semble pas possible d’écrire dans un sous-répertoire. Si vous souhaitez isoler les fichiers de backup, il est possible d’écrire dans un autre “container” sur HubiC (autre que « default »), par exemple en faisant votre backup ainsi :

duplicity /root cf+hubic://backup

Vous ne verrez pas en ligne les fichiers sans modifier manuellement l’URL ainsi https://hubic.com/home/browser/#backup/ (n’oubliez pas ‘/’ à la fin) :

Etape 4 : mettre en place les scripts de backup de Duplicity

Comme je l’avais indiqué dans mon premier billet sur Duplicity, nous allons installer ces script dans le répertoire /usr/local/sbin :

# On récupère les scripts
wget -O /usr/local/sbin/master-backup-cleanup.sh --no-check-certificate https://raw.github.com/yvangodard/Scripts-Utiles/master/duplicityscripts/scripts/master-backup-cleanup.sh
wget -O /usr/local/sbin/master-backup-listing.sh --no-check-certificate https://raw.github.com/yvangodard/Scripts-Utiles/master/duplicityscripts/scripts/master-backup-listing.sh
wget -O /usr/local/sbin/master-backup-restore.sh --no-check-certificate https://raw.github.com/yvangodard/Scripts-Utiles/master/duplicityscripts/scripts/master-backup-restore.sh
wget -O /usr/local/sbin/master-backup-status.sh --no-check-certificate https://raw.github.com/yvangodard/Scripts-Utiles/master/duplicityscripts/scripts/master-backup-status.sh
wget -O /usr/local/sbin/master-backup-verify.sh --no-check-certificate https://raw.github.com/yvangodard/Scripts-Utiles/master/duplicityscripts/scripts/master-backup-verify.sh
wget -O /usr/local/sbin/master-backup.sh --no-check-certificate https://raw.github.com/yvangodard/Scripts-Utiles/master/duplicityscripts/scripts/master-backup.sh
 
# On les rends exécutables
sudo chmod +x /usr/local/sbin/master-backup*

Je vous invite ensuite à vous reporter à mon premier billet sur Duplicity pour voir comment utiliser ces scripts et les paramètres de Duplicity qui y sont associés. Il vous faudra notamment éditer le fichier de configuration (par exemple /etc/master-backup.conf) et y entrer les variables nécessaires, notamment celle définissant l’emplacement de stockage du backup et le backend utilisé.
Avec la configuration que nous venons de mettre en place nous devrons indiquer URL=cf+hubic://default (ou tout autre containter, comme indiqué à l’étape 3).

A vous de jouer !