Suite à une énième migration, je recherchais une solution durable pour mes backups en ligne. J’ai choisi hubic d’OVH pour ses tarifs extrêmement bas : 10 To de stockage pour 50€ TTC / an (ou 5 € / mois). Les [débits](#debits) via leur API ne sont pas au rendez-vous, mais à ce tarif là, je suis prêt à faire quelques concessions. EDIT: Les débits ont été améliorés.
L’avantage du stockage dans le cloud, est que généralement les données sont répliquées 3 fois, dans plusieurs datacenters différents. Donc beaucoup plus robuste qu’un stockage sur un simple disque dur. Aussi, en optant pour le cloud, j’évite tous les inconvénients liés à la maintenance d’un serveur dédié.
Concernant la privacy, je ne fais confiance à personne, pas plus à OVH qu’à Google ou Amazon. C’est pourquoi les données que j’upload dans le cloud sont systématiquement chiffrées. Je vous recommande de faire de même.
Je me sers surtout du cloud pour répliquer mes backups, ce n’est pas mon espace de sauvegarde principal.
En local j’ai le setup suivant :
- une cubox (board ARM) avec 2x4To qui me sert de serveur de stockage / seedbox / media server / partage de fichiers.
- backup incrémental quotidien du laptop vers le cubox en utilisant duplicity.
- backup des photos depuis les smartphones via l’application Sweet Home (classement auto des photos, par date/mois, vraiment très pratique).
Je suis fan de duplicity car il s’agit d’un logiciel de sauvegarde simple d’utilisation, complet (backup incrémental, supporte des tonnes de backend, S3, swift, dropbox …), mais surtout, qui chiffre automatiquement les données.
L’API hubic
Les problèmes commencent ici. Hubic utilise openstack swift comme infrastructure de stockage. Mais bien entendu l’API mis à disposition n’implémente pas l’authentification de base swift, ce qui rend hubic inutilisable avec tous les tools qui supportent swift.
Heureusement on peut facilement contourner ce problème en installant Hubic to OpenStack Swift Gateway et profiter pleinement de l’API swift. Il s’agit d’un simple script PHP que je vous recommande d’installer sur un site avec un certificat SSL valide (le certif valide vous évitera des soucis d’incompatibilité avec certains tools). Après avoir généré votre API KEY sur hubic et configuré le script, l’API hubic est maintenant totalement compatible.
Swift client
Swift-client n’est pas forcément utile pour les backups, mais vous allez pouvoir vous en servir pour vérifier que tout fonctionne bien au niveau de l’API.
# Lister vos containers
swift -U login -K password -A https://hugic2swiftgate.local/auth/v1.0/ list --lh
6532 119G 2015-08-20 10:56:46 backups:laptop
25 24G 2015-08-28 12:15:28 backups:laptop-old
342 7.3G 2015-08-17 19:00:36 backups:photos
2 1.3G 2015-08-17 10:11:12 default
6.7K 152G
# Uploader un fichier
swift -U hubic -K password -A https://hugic2swiftgate.local/auth/v1.0/ upload container-distant fichier-local
# Télécharger un fichier
swift -U hubic -K password -A https://hugic2swiftgate.local/auth/v1.0/ download container-distant fichier-distant
Aussi, pour booster les débits vers hubic en multipliant les connexions parallèle, vous pouvez regarder du côté des options suivantes :
-S SEGMENT_SIZE, --segment-size=SEGMENT_SIZE
Will upload files in segments no larger than <size>
and then create a "manifest" file that will download
all the segments as if it were the original file.
-C SEGMENT_CONTAINER, --segment-container=SEGMENT_CONTAINER
Will upload the segments into the specified
container.If not specified, the segments will be
uploaded to <container>_segments container so as to
not pollute the main <container> listings.
--leave-segments Indicates that you want the older segments of manifest
objects left alone (in the case of overwrites)
--object-threads=OBJECT_THREADS
Number of threads to use for uploading full objects
--segment-threads=SEGMENT_THREADS
Number of threads to use for uploading object segments
Duplicity
Duplicity supporte swift par défaut, il suffit d’exporter les informations d’identification dans des variables d’environnement et de spécifier le backend swift :
export SWIFT_AUTHURL='https://hugic2swiftgate.local/auth/v1.0/'
export SWIFT_USERNAME='hubic'
export SWIFT_PASSWORD='password'
# backup avec duplicity vers hubic
duplicity /backup-local/photos/ swift://container-distant
Remarque importante: dans le stockage swift openstack il y a une notion de container. Un container est un répertoire spécial de premier niveau. Un container peut contenir des répertoires et des sous répertoires. Cependant, duplicity ne peut effectuer un backup que vers un container, pas vers un sous répertoire. Autrement dit exécuter la commande suivante est impossible :
# will fail, impossible de synchroniser les backups dans un répertoire
duplicity /backup-local/photos/ swift://container-distant/sous-répertoire
Rclone
On ne peut pas utiliser le vrai rsync avec hubic, à moins de faire un mount mais à mon avis les débits seront vraiment horribles (avec ça par exemple). Non en réalité il y a une chouette alternative qui s’appelle rclone et qui supporte pas mal de backend : S3, Google Drive, Dropbox, … et bien évidemment, swift.
Rclone se configure automatiquement ou via un petit fichier de configuration ~/.rclone.conf. Le fichier est divisé en section, chaque section correspond à un espace de stockage dans le cloud. Voici par exemple pour hubic qui utilise swift :
[hubic]
type = swift
user = hubic
key = password
auth = https://hugic2swiftgate.local/auth/v1.0/
tenant =
region =
À partir de là on peut copier, synchroniser, uploader, effacer, etc. avec rclone.
Dans mon cas, j’utilise rclone pour synchroniser les backups du laptop qui sont déjà chiffrés vers le cloud.
Une option intéressante pour booster les débits vers hubic :
--transfers=16 Number of file transfers to run in parallel.
<h2 id=debits>Débits</h2>
EDIT: 22/09/2015 Suite à une maintenance sur hubic, les débits sont maintenant au rendez-vous. J’ai à peu près les mêmes débits via l’API ou via le web uploader et je max quasiment mes 250MBit/sec de bande passante.
