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 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.
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.
Cliquez ensuite sur Créer un conteneur d’objets.
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.
Choisissez le type de conteneur privé et cliquez sur Suivant.
Enfin, donnez lui un nom (nous l’avons nommé sauvegardes) et cliquez sur Ajouter le conteneur.
Vous pourrez alors retrouver votre conteneur dans la liste, dans le Menu Storage/Object Storage.
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…
Cliquez ensuite sur Ajouter un utilisateur.
Donnez une description à votre utilisateur.
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.
Donnez donc le rôle ObjectStore Operator à votre utilisateur.
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.
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.
Sélectionnez ensuite le centre de données (datacenter) où se situe votre conteneur et cliquez sur Télécharger.
Notez les données suivantes :
OS_USERNAME
: le nom de l’utilisateur (doit correspondre à celui que vous avez créé),OS_TENANT_NAME
: Il s’agit du numéro du projet, vous pouvez le retrouver dans l’interface Horizon (interface de gestion spécifique OVH Cloud),OS_REGION_NAME
: le datacenter où se situe votre conteneur.
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 :
python-keystoneclient
pour l’authentification OpenStackpython-swiftclient
pour le stockage
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.
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 :
SWIFT_USERNAME
, le nom de l’utilisateur swift. Il s’agit de l’utilisateur que vous avez créé tout à l’heure, et dont vous pouvez retrouver le nom sousOS_USERNAME
dans le fichier RC que vous avez téléchargé,SWIFT_PASSWORD
est le mot de passe de votre utilisateur que vous avez noté lors de la création de celui-ci,SWIFT_AUTHURL
est l’url pour se connecter à votre conteneur via Swift. Depuis le 24 mars 2020, celle ci est https://auth.cloud.ovh.net/v3,SWIFT_AUTH_VERSION
est la version de swift utilisée, idem, depuis le 24 mars, c’est la version 3,SWIFT_TENANTNAME
est le numéro du projet swift. Vous ne pouvez pas l’inventer, mais vous le retrouverez sous la valeurOS_TENANT_NAME
dans le fichier RC,SWIFT_REGIONNAME
est la région. Il s’agit du datacenter que vous avez choisi, mais vous pouvez aussi retrouver la valeur dansOS_REGION_NAME
du fichier RC.
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 :
ENCRYPT_KEY
, l’identifiant de votre clef de chiffrement. Il s’agit des 64 derniers bits de l’exposant public de la clef. Pour le trouver, il vous suffit de prendre les 8 derniers caractères de l’exposant de votre clef,SIGN_KEY
, même chose pour la clef de signature,PASSPHRASE
, la passephrase de votre clef de chiffrement,SIGN_PASSPHRASE
, celle de votre clef de signature.
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
:
--full-if-older-than 1M
: faire une sauvegarde complète si la dernière a plus d’un mois,--copy-links
: copier les fichiers pointés par les liens symboliques,--encrypt-key
: la clef de chiffrement,--sign-key
: la clef de signature,--num-retries 3
: réessayer 3 fois si erreur,--asynchronous-upload
: prépare l’envoi suivant pendant l’envoi du fichier en cours,--cf-backend swift
: utilisation de swift,--volsize 100
: réduit la taille des paquets envoyés par duplicity.${1}
: récupère le premier argument passé dans la ligne de commande, qui devra contenir le chemin du répertoire contenant les données à sauvegarder,${2}
: récupère le second argument de la ligne de commande, qui doit contenir l’adresse de votre conteneur OVH.
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 :
remove-older-than 2M
supprime les fichiers plus vieux que 2 mois--force
force la commande a être effectuée${1}
: récupère le premier argument de la ligne de commande, celui-ci devra contenir l’adresse du conteneur swift.
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 :
source
est le répertoire contenant les données que vous souhaitez backuper,destination
est l’adresse de conteneurswift
. Prenez le nom de votre conteneur que vous avez créé précédemment (dans notre exemple, nous l’avions appelé sauvegardes) et préfixez par swift:// (dans notre cas, ce sera swift://sauvegardes).
#!/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
:
-t 1D
: récupère la sauvegarde d’il y a un jour. A modifier si vous avez besoin de retrouver des sauvegardes plus vieilles,list-current-files
: demande àduplicity
de lister les fichiers stockés sur le serveur distant,--encrypt-key
: la clef de chiffrement,--sign-key
: la clef de signature,--cf-backend swift
: utilisation deswift
,${1}
: récupère le premier argument passé dans la ligne de commande, soit contenir l’adresse du conteneur OVH.
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 :
<source>
est l’adresse de conteneur swift (pour le retrouver, c.f. script sur le backup),
#!/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
:
-t 1D
: récupère la sauvegarde d’il y a un jour. A modifier si vous avez besoin de retrouver des sauvegardes plus vieilles,--encrypt-key
: la clef de chiffrement,--sign-key
: la clef de signature,--cf-backend swift
: utilisation deswift
,${1}
: récupère le premier argument passé dans la ligne de commande, qui devra contenir l’adresse du conteneur OVH.${2}
: récupère le second argument passé en ligne de commande, qui contiendra le chemin vers le répertoire où vous souhaitez récupérer les données
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 :
<source>
est l’adresse de conteneur swift,<dest>
est le répertoire dans le lequel vous souhaitez récupérer vos fichiers
#!/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
:
--file-to-restore
: demande de récupérer un fichier ou un répertoire,-t 1D
: récupère la sauvegarde d’il y a un jour. A modifier si vous avez besoin de retrouver des sauvegardes plus vieilles,--encrypt-key
: la clef de chiffrement,--sign-key
: la clef de signature,--cf-backend swift
: utilisation deswift
,${1}
: récupère le premier argument passé dans la ligne de commande, qui devra contenir l’adresse du conteneur OVH.${2}
: récupère le deuxième argument passé en ligne de commande, qui contiendra le chemin vers le répertoire où vous souhaitez récupérer les données${3}
: récupère le troisième argument passé en ligne de commande, qui contiendra le nom du fichier ou du répertoire à récupérer.
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
<source>
est l’adresse de conteneur swift (pour le retrouver, c.f. script sur le backup),<dest>
est le répertoire ou le fichier dans le lequel vous souhaitez récupérer votre répertoire ou votre fichier<file>
est le chemin dans le conteneur vers le fichier (ou le répertoire le cas échéant) que vous souhaitez récupérer.
#!/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.