La sauvegarde distante pour les nuls

La sauvegarde distante pour les nuls

Il est des billets qui ne servent pas à grand si ce n’est juste de bloc-note à mon intention. L’autre jour, déçu du mode de facturation des snapshots sur les VPS OVH, je me suis mis à la recherche d’outils plus radicaux qui me permettraient de redémarrer mon serveur Debian depuis n’importe quelle machine. J’ai fini par tomber sur le couple duplicity/backupninja dont la simplicité de mise en oeuvre est telle que ce billet devrait vous paraitre inutile.

Quand on tape les mots clefs « Debian Backup Tool », on tombe classiquement sur cette page : qui est « relativement » à jour et donne un aperçu de divers outils de sauvegarde. Elle permet surtout de se rendre compte qu’en matière de sauvegarde, les outils sont nombreux et spécialisés à l’image du besoin. Donc, une première étape fondamentale consiste à bien identifier son besoin.

Identification du besoin

Utilisons une bonne vieille démarche QQCOQP.

Pourquoi, dans quel but sauvegarder le serveur ? J’y ai déjà plus ou moins répondu plus haut. L’objectif c’est d’avoir le matériel nécessaire et suffisant à la reprise d’un serveur depuis une installation fraiche de Debian (éventuellement sur une autre machine).

Ensuite, répondons à la question : « Sauvegarder quoi ? ». Dans mon cas, je cherchais à sauvegarder un serveur que j’utilise essentiellement pour :

  • héberger des plates-formes trac
  • héberger mon serveur d’agendas et de cartes de visite (Davical + CardDavMate) qui utilise postgresql
  • déboguer mes développements PHP avec Xcode

Maintenant, cherchons à voir réaliser cette sauvegarde ?. Sur une de mes machines à la maison : bof et puis elles ne sont quand même pas allumées tout le temps. Or, en matière de sauvegarde, mieux vaut avoir ceintures et bretelles sans quoi la loi de Murphy s’applique toujours. Donc l’idéal, c’est d’utiliser un autre serveur distant 24/24. Il y a bien une option FTP sur les VPS OVH, mais elle est plutôt chère. J’ai donc commencé à regarder un peu ce qu’on pouvait trouver à un prix raisonnable, quand il m’est venu une idée : utiliser les nombreux Mo disponibles de mon hébergement (600 Mo sur un 60 gp). Seul hic, la sécurité des serveurs fournit par OVH sur ce type d’offre qui laisse à désirer (pur FTP, mot de passe court…). Il suffirait de crypter les fichiers résultants pour qu’au minimum, ils ne soient pas lisibles par quiconque parviendrait à se connecter.

Enfin attardons-nous sur le comment : quel type de sauvegarde ? Je cherchais du simple et classique : des complètes et des incrémentielles avec la possibilité de revenir n jours en arrière, mais surtout avec un paramétrage qui reste simple.

En résumé, il me fallait une solution :

  • qui sache prendre en charge une sauvegarde à chaud d’une base postgresql
  • qui prenne en charge une plate-forme trac avec son SVN
  • qui chiffre les fichiers
  • qui calcule tout seul ce qu’il faut sauvegarder sans poser trop de questions
  • qui sache déposer le résultat sur un FTP distant

Solutions

Après avoir fait un peu fausse route vers backup-manager, je suis tombé sur duplicity puis revenu vers Backupninja qui de prime abord m’avait semblé un peu usine à gaz.

duplicity

La force de duplicity (du moins ce que j’en ai retenu) c’est sa capacité à sélectionner des fichiers selon différents critères (dont l’optimisation des transferts pour ne pas sauvegarder n fois les mêmes données), à les encrypter voire les signer et enfin les déposer potentiellement à distance selon divers protocoles.

En résumé, sa force c’est la sauvegarde de fichier.

Deux références inévitables :

Backupninja

Backupninja dans tout ça, c’est plutôt un orchestrateur. Un outil qui va préparer, dans l’ordre que vous lui indiquerez, les différents éléments à sauvegarder. Par exemple, un export au format SQL d’une base de données…

Il regroupe un ensemble de scripts fournis par la communauté pour gérer la sauvegarde de bases de données, de SVN, de plate-forme trac… En fin de chaîne, il facilite le paramétrage de duplicity en vous posant des questions simples (ou en modifiant le fichier de configuration très lisible qu’il génère). En particulier, il offre une interface WEB 0.0 qui effrayera certainement les jeunes générations accros au flash et à l’AJAX, mais qui au demeurant est diablement efficace.

Sa force c’est de vous poser les bonnes questions ou d’avoir de bons paramètres par défaut, pour mettre en place l’ensemble de votre stratégie de sauvegarde.

Mise en oeuvre

Pour ce qui est de l’installation sous Debian, les choses sont assez simples :

sudo apt-get install duplicity backupninja

Par défaut, duplicity utilise une clef symétrique pour le chiffrage des données. Par contre, si on lui spécifie un jeu de clefs asymétriques, il utilise la clef publique pour le chiffrement des données (que vous serez le seul à pouvoir déchiffrer). Enfin, on peut demander en plus la signature des fichiers différentiels, surtout dans le but d’en garantir l’intégrité. Dans ce cas, il faut indiquer un 2nd jeu de clefs (cette fois-ci, c’est la clef privée qui sera utilisée). Certains utilisent le même jeu pour le chiffrement et la signature, même si l’idéal est d’en utiliser 2 différents.

Il se peut donc que vous ayez à créer des paires de clefs, selon votre paranoïa ou l’enjeu que constituent vos données. Voici 2 commandes pour créer et lister des clefs :

gpg --gen-key (puis se laisser guider)
gpg --list-keys

Comme il devient de plus en plus dur de produire du chaos et encore plus sur un VPS sur lequel vous n’avez même pas d’environnement graphique, je recommande la compilation et l’utilisation du code GUChaos.c et la lecture du billet : Remplir le réservoir d’entropie avec « Give Us Chaos! ».

Ensuite, la démarche à suivre est de lancer backupninja, de générer quelques actions et de contrôler ce qui a été créé dans /etc/backup.d. Pour cela, il suffit de taper :

sudo ninjahelper

Alors, avec un peu de réflexions et sans grande expertise (en particulier sur duplicity), on parvient assez vite à mettre en place votre stratégie de sauvegarde.

Enfin, cet article ne serait pas complet s’il n’était pas indiqué comment récupérer ses données en cas de besoin. Je ne citerai qu’un seul cas, semblable au mien, la récupération complète depuis un site FTP (d’autres exemples sont donnés dans les références fournies plus haut sur duplicity). Le plus simple et sûr est de se créer un petit fichier après avoir récupéré l’identifiant de sa clef grâce à la commande gpg --list-keys. Ce fichier doit ressembler à ça :

#!/bin/bash
 
# Le repertoire de destination
mkdir /var/tmp/backup-restore
 
# Le mot de passe de votre connexion FTP
export FTP_PASSWORD=********	
 
# La phrase de passe associée à votre clef d'encryption
export PASSPHRASE=********
 
# La commande magique
duplicity --encrypt-key "YOUR_ENCRYPT_KEY_ID" --sign-key "YOUR_SIGN_KEY_ID" ftp://login@ftp.e-gaulue.com/your_backup_directory /var/tmp/backup-restore

Il ne reste plus qu’à l’exécuter puis le supprimer.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *