Mettre en place une sauvegarde chez OVH avec Duplicity

Divulgâchage : Comme il vaut mieux le faire avant qu’il ne soit trop tard, les arsouyes vous montrent comment utiliser duplicity pour sauvegarder vos données dans le cloud d’OVH.

Cet article met à jour et remplace les articles « Backup de données chez OVH avec duplicity » et « Récupération des données sauvegardées chez OVH avec duplicity », obsolètes depuis le passage à la version 3 de l’API Keystone chez OVH le 24 mars 2020.

Que l’on soit un particulier ou une entreprise, la perte des données est quelque chose que l’on craint. Mis à part si vous faites preuve d’optimisme irréaliste, vous avez surement commencé à réfléchir à un moyen pour synchroniser vos données sur un système distant.

Chez les arsouyes, nous craignons nous aussi la perte de nos données. Pour y parer, nos fichiers importants, sont tout d’abord sauvegardés sur notre NAS. Celui-ci est doté de disques durs en RAID, permettant de prévenir les problèmes matériels. Mais cela ne permet pas de parer aux incendies, ni aux cryptolockers. Pour cela, nous les envoyons donc toutes les nuits, de manière incrémentale et chiffrée, sur un serveur chez OVH. Comment nous avons fait ? C’est l’objet de notre article d’aujourd’hui.

Remerciements à Sylvain S. pour sa relecture et la correction de coquilles qui s’étaient glissées dans l’article.

si aucune précaution n’est prise, le risque est élevé. danielschenk @ pixabay

Si vous avez suivi notre précédent article que vous l’avez mis en pratique, vous devriez avoir reçu un mail de la part de OVH vous informant du passage de la version 2 à la version 3 de l’API Keystone le 24 mars 2020. Comme nous sommes en avril, cet ancien article est donc obsolète, voici donc une version revue, améliorée et augmentée de celui-ci.

Côté OVH

Nous avons décidé d’utiliser le Object Storage de OVH. Il s’agit d’un espace de stockage où l’on paie à l’espace utilisé.

Pour information, Object Storage fait partie de la gamme Public Cloud, qui est une offre professionnelle de OVH. Vous ne pourrez pas en commander un et l’obtenir immédiatement, OVH va vous demander une copie d’une pièce d’identité avant de valider l’ouverture de votre service.

Une fois que votre Public Cloud sera ouvert, vous pourrez le retrouver en cliquant sur Public Cloud, dans la barre en haut de l’écran de votre interface de gestion OVH.

barre de navigation

Création d’un conteneur

Afin de pouvoir déposer vos données, vous devez tout d’abord créer un conteneur. Pour cela, cliquez sur Object Storage dans le menu à gauche de l’écran.

Menu

Cliquez ensuite sur Créer un conteneur d’objets.

Creation du conteneur

L’interface vous demandera ensuite de choisir la localisation de votre conteneur. Sélectionnez-en un pas trop loin de chez vous et cliquez sur Suivant.

Localisation du conteneur

Choisissez le type de conteneur privé et cliquez sur Suivant.

Type de conteneur

Enfin, donnez lui un nom (nous l’avons nommé sauvegardes) et cliquez sur Ajouter le conteneur.

Nom du conteneur

Vous pourrez alors retrouver votre conteneur dans la liste, dans le Menu Storage/Object Storage.

Résumé des conteneurs

Création d’un utilisateur

Maintenant que vous avez un conteneur dans lequel déposer vos fichiers, il vous faut un utilisateur pour y accéder.

Dans la section Project Management, cliquez sur Users & Roles.

Certains morceaux du menu sont en anglais, ne me demandez pas pourquoi…

Menu

Cliquez ensuite sur Ajouter un utilisateur.

Ajout d’un utilisateur

Donnez une description à votre utilisateur.

Description

L’écran suivant concernera le rôle de l’utilisateur en train d’être créer. Afin de pouvoir déterminer quel est le rôle adéquate, nous nous reportons à la matrice des rôles fournis par OVH. Nous allons utiliserduplicity avec l’API OpenStack/Swift, du coup, nous devons regarder la ligne concernant swift. Les deux seuls rôle possibles sont administrator et objectStore operator. Comme nous préférons utiliser la politique du moindre privilège, nous nous contenterons donc de ObjectStore operator.

Matrice de rôles

Donnez donc le rôle ObjectStore Operator à votre utilisateur.

rôle

L’interface vous affichera alors un mot de passe qu’il est INDISPENSABLE de noter (il n’est pas possible de récupérer un mot de passe oublié, vous serez alors obligé de le régénérer). Notez également au passage le nom de votre utilisateur.

mot de passe

Dans notre cas, l’utilisateur créé par OVH s’appelle bien exgbvthv53G7. Et pour les petits malins qui se posent la question, l’utilisateur a été créé pour l’exemple… Donc pas la peine de chercher à récupérer mes sauvegardes avec lui…

Récupération d’informations importantes

La technologie utilisée par OVH pour son système de Cloud est OpenStack. En règle général, les constantes nécessaires pour utiliser OpenStack se trouve dans un fichier nommé RC. Il en va de même chez OVH.

Nous allons donc récupérer le fichier RC d’OpenStack correspondant à notre contexte via l’interface d’OVH.

Pour télécharger le fichier, allez dans la liste des utilisateurs Project Management/Users&Roles, cliquez sur les trois petits points à la droite de l’utilisateur que vous venez de créer, puis sur Télécharger le fichier RC d’OpenStack.

Fichier RC

Sélectionnez ensuite le centre de données (datacenter) où se situe votre conteneur et cliquez sur Télécharger.

Region

Notez les données suivantes :

Côté serveur de sauvegarde

Maintenant que l’on a fait tout ce qu’il faut côté OVH, on va s’attaquer à la machine qui va envoyer les sauvegardes chez OVH.

Installation des paquets

La première chose à faire est d’installer duplicity et les différentes dépendances nécessaires.

apt-get update && apt-get install duplicity

Puis d’utiliser pip pour installer les modules python requis par duplicity :

pip install python-swiftclient python-keystoneclient

Génération des clefs

La deuxième étape est de générer les clefs utilisées pour le chiffrement et pour la signature.

ar130405 @ pixabay

Suivant les recommandations du RGS v2.0, annexe B2, nous avons donc créé deux clefs, une pour le chiffrement et une pour la signature .

RègleUsage-1. L’usage d’une clé doit être unique.

Justifications:

  • L’emploi d’une même clé à plus d’un usage, par exemple pour chiffrer avec un mécanisme de confidentialité et assurer l’intégrité avec un mécanisme différent, est source de nombreuses erreurs. Ceci n’interdit cependant pas de dériver deux clés à partir d’une même clé source à condition que le mécanisme de dérivation soit conforme au référentiel, ni de mettre en place un mécanisme de chiffrement authentifié où chiffrement et authentification sont assurés par un unique mécanisme qui a été spécialement conçu pour une telle utilisation et non par deux mécanismes distincts.
  • L’emploi d’une même bi-clé à plus d’un usage, par exemple pour chiffrer et signer, est aussi une grave source d’erreurs.

gpg étant installé par défaut sur les systèmes de type ubuntu et debian, afin de générer les clefs, on utilise deux fois de suite gpg et on se laisse guider par l’outil de création de clefs.

 gpg --full-gen-key

De notre côté, nous avons choisi d’utiliser des clefs de 4096 bits, car c’est recommandé par Ubuntu.

Dans le cas d’une clé RSA, il est aujourd’hui (2016) vivement recommandé d’utiliser une clé d’une longueur minimale de 4096 bits !

Voir « Les clés primaires devraient être des clés DSA-2 ou RSA, de 4096 bits ou plus (de préférence RSA) » ou encore l’interview de Phil Zimmermann [de], l’inventeur de PGP, qui, en 2013, recommandait déjà une longueur minimale de 3072 bits pour les clés RSA.

Vous pouvez ensuite afficher vos clefs avec la commande.

gpg --list-keys

Les scripts

Il s’agit des scripts effectuant la sauvegarde, le listing des fichiers, la récupération d’un ou de tous les fichiers.

Base commune

Tous nos scripts nécessiterons certaines informations communes, telles que les données de connexion au conteneur où les informations relatives aux clefs. Pour simplifier le tout, nous avons choisi de créer des scripts que nous inclurons dans chaque script que nous ferons.

swift.sh

Tous nos scripts commenceront par la même en-tête, contenant les différentes constantes permettant d’accéder à notre conteneur. Nous allons donc créer un fichier swift.sh contenant les informations suivantes :

Le script swift.sh :

export SWIFT_USERNAME=<username>
export SWIFT_PASSWORD=<password>
export SWIFT_AUTHURL="https://auth.cloud.ovh.net/v3"
export SWIFT_AUTHVERSION="3"
export SWIFT_TENANTNAME=<tenantname>
export =<regionname>

Le script swift.sh est destiné à être inclus, il ne commence donc pas par !/bin/sh

gpg.sh

Nous avons besoin de stocker quelque part les clefs utilisées pour le chiffrement et pour la signature, mais également les passphrases correspondantes. En effet, duplicity, en mode incrémental, doit tout d’abord récupérer les données sur le serveur distant avant de pouvoir effectuer la comparaison et de déterminer si les fichiers sont déjà présent sur le stockage cloud ou non. Pour cela, il a besoin de la passphrase de votre clef de chiffrement pour pouvoir déchiffrer les données présentes sur le serveur.

Le fichier gpg.sh reprends toutes les informations nécessaires pour l’utilisation de GPG :

Le script gpg.sh.

export ENCRYPT_KEY=<clef_chiffrement>
export SIGN_KEY=<clef_signature>
export PASSPHRASE=<passphrase de la clef de chiffrement>
export SIGN_PASSPHRASE=<passphrase de la clef de signature>

backup.sh

Ce script permet d’effectuer l’envoi des données que vous souhaitez backuper vers votre conteneur chez OVH.

send.sh

Afin d’envoyer les données sur le serveur distant, duplicity est configuré de manière à utiliser swift, faire des sauvegardes incrémentales et copier les liens symboliques. Pour les plus curieux, voilà le détail complet des options passées à duplicity :

Le script send.sh .

duplicity --full-if-older-than 1M\
                --copy-links \
                --verbosity notice \
                --encrypt-key "$ENCRYPT_KEY" \
                --sign-key "$SIGN_KEY" \
                --num-retries 3 \
                --asynchronous-upload \
                --cf-backend swift \
                --volsize 100 \
                "${1}" "${2}"

remove.sh

Afin de ne pas surcharger le disque et se retrouver avec une énorme quantité de données, remontant à trop longtemps dans le temps, nous utiliserons encore une fois duplicity, en lui disant de supprimer les backup de plus de 2 mois :

Le script remove.sh.

duplicity remove-older-than 2M --force "${1}"

le script

Le script backup.sh devient au final une suite d’inclusion des bons scripts, les uns après les autres, précédé des informations sur l’adresse du conteneur et le répertoire contenant les données à sauvegarder :

#!/bin/bash
src=<source>
dest=<destination>

source swift.sh
source gpg.sh
source send.sh $src $dest
source remove.sh $dest

list.sh

Ce script permet de lister toutes les données que vous avez dans votre conteneur.

list-files.sh

Afin de récupérer la liste des fichiers présents sur le serveur distant, il faut utiliser duplicity avec l’option list-current-files:

duplicity -t 1D  list-current-files --encrypt-key "$ENCRYPT_KEY"  --sign-key "$SIGN_KEY" --cf-backend swift ${1}

le script

Le script de listing revient encore une fois à une liste d’inclusion des bons scripts, précédé de l’adresse du conteneur OVH dont vous souhaitez récupérer la liste des fichiers :

#!/bin/bash
src=<source>

source swift.sh
source gpg.sh 
source list-files.sh $src

recover-all.sh

Ce script permet de récupérer toutes les données contenues dans votre conteneur de sauvegarde. Attention, il peut prendre beaucoup de temps si vous avez beaucoup de fichiers.

recover.sh

Afin de récupérer tous les fichiers présents sur le serveur, il faut encore une fois utiliser duplicity :

duplicity -t 1D --encrypt-key "$ENCRYPT_KEY" --sign-key "$SIGN_KEY" --num-retries 3 --cf-backend swift "${1}" "${2}"

le script

Au final, le script contiendra les informations sur le conteneur, le chemin vers où doivent être récupérer les données, ainsi que l’inclusion de tous les scripts nécessaires :

#!/bin/bash
src=<source>
dest=<dest>

source swift.sh
source gpg.sh 
source recover.sh $src $dest

recover-one.sh

Ce script permet de récupérer un fichier en particulier.

recover-file.sh

duplicity va être utilisé avec l’option file-to-restore:

duplicity -t 1D --file-to-restore ${3} --encrypt-key "$ENCRYPT_KEY" --sign-key "$SIGN_KEY" --cf-backend swift ${1} ${2}

le script

Le dernier script que nous vous proposons contient donc les informations nécessaires pour se connecter au conteneur, l’endroit où vous souhaitez récupérer vos données, le fichier que vous souhaitez récupérer, puis inclus tous les scripts nécessaires

#!/bin/sh
src=<source>
dest=<dest>
file=<file>

source swift.sh
source gpg.sh
source recover-file.sh $src $dest $file

Et après

A partir de maintenant, dès que vous utiliserez ces scripts, vous pourrez envoyer ou récupérer vos données chez OVH. Si vous souhaitez automatiser le tout, n’hésitez pas à utiliser cron.