(modifié le 26 mai 2015 à 23:10)

Déporter des données dans le nuage comporte de nombreux avantages : coûts, sécurité (vol, incendie,etc) mais il ne faut pas se jeter sur cette solution sans réfléchir.

backup-encrypt-hubic

Que vous utilisiez Dropbox, Box, hubiC, Google Drive, Amazon S3 (pour ne citer qu'eux) il est déconseillé d'y stocker des données importantes sans les chiffrer. Voici une procédure pour y parvenir avec un NAS Synology.

Pourquoi chiffrer

Les raisons du chiffrement sont nombreuses :

  • Sensibilité et/ou confidentialité des données (mots de passes, données bancaires, etc)
  • Interception ou écoute (malware) rendue caduque, le contenu des fichiers n'étant pas lisible
  • Intégrité des données grâce au hash de chaque fichier archivé (facultatif)

Je vous expliquerai dans un futur billet comment je sauvegarde le contenu de BM de façon entièrement automatisée très prochainement, en libérant le code source pour que vous puissiez en profiter.

Une fois cette sauvegarde réalisée en locale sur un NAS Synology je la duplique dans le cloud chez hubiC. J'ai opté pour ce fournisseur car ses serveurs ne sont pas aux états-unis. Après l'épisode PJL cela peut vous faire sourire, mais jusqu'à il y a peu de temps cela avait un sens.

Avec Synology

Mon NAS Synology est en charge de pousser la sauvegarde chez hubiC, grâce au paquet Cloud Sync. Depuis la version 5.2 DSM intègre une fonctionnalité de chiffrement native, pour en profiter il faut supprimer votre liaison existante puis la recréer. Si vous n'avez pas envie de le faire, alors la suite de ce tutoriel est fait pour vous.

cloudsync-dossier

Comme je vous l'ai dit on part du principe que je dispose d'un répertoire sur le NAS contenant :

  • archive-data.gz (contenu du FTP)
  • archive-mysql.gz (contenu de la base de données)
  • backup.log : trace du backup de création des deux fichiers GZ

Le chiffrement n'était pas intégré au moment où j'ai souhaité copier mes backup chez hubiC, j'ai écrit un script qui réalise l'opération.

Mon script va donc :

  • crée une archive 7z chiffrée (ainsi que le nom des fichiers)
  • y ajouter les 2 fichiers GZ et le fichier LOG
  • nomme cette archive sous la forme YYYY.MM.JJ_secure.7z
  • déplacer cette archive dans le répertoire synchronisé puis Cloud Sync l'envoie chez hubiC de façon transparente

Voici le script qui permet de produire une archive chiffrée :

Quelques explications sur les arguments 7z :

  • a : mode archive
  • -t7z : type de l'archive (7z)
  • -mx0 : compression niveau 0 (aucune)
  • -aoa : écrase si destination existe dans l'archive,
  • -mhe=on : chiffre le nom des fichiers

Je vous laisse changer le mot de passe en gardant un minimum de 15 caractères, si on chiffre autant le faire correctement.

Concernant les chemins :

  • localpath = ce répertoire contient la dernière sauvegarde de Blogmotion (2 GZ et un LOG)
  • hubicpath = chemin vers le répertoire "toHubic" dont le contenu est synchronisé avec hubiC. Le dossier "BM" est là pour éviter de mettre tous les backups à la racine, à la fois pour des question d'organisation mais également pour pas synchroniser des choses inutiles en cas de synchro bidirectionnelle.

Vous pouvez aussi configurer Cloud Sync pour empêcher ça :

cloudsync-filter

Attention à bien préciser le poids maximal par fichier, dans mon cas le backup complet de BM ne pèse que 280 mo... je suis large.

Conclusion

Et oui, c'est très simple. Cloud Sync nous facilitant grandement la tâche en prenant la synchronisation à sa charge. Le gros avantage de cette solution c'est que vous pouvez récupérer et extraire votre backup depuis n'importe à partir du moment où vous avez le mot de passe. Alors qu'avec Cloud Sync il faut passer obligatoirement par lui pour le faire.

Si vous n'avez pas de NAS Synology vous pouvez utiliser ce bout de script sur un serveur GNU/Linux quelconque car les clients pour le cloud sont nombreux, on trouve par exemple un client hubiC pour Linux.

Auteur : Mr Xhark

Fondateur du blog et passionné par les nouvelles techno, suivez-moi sur twitter