+++

title = "Quelques pistes pour une sauvegarde répartie (1)"
date = 2011-09-27
aliases = [ "post/2011/09/27/Quelques-pistes-pour-une-sauvegarde-répartie-(1)"]
[taxonomies]
tags = [ "système", "sauvegarde" ]
+++

Ou comment mettre toutes tes saloperies sur les PCs des autres pour être peinard…

<!-- more -->

L'une des grosses problématiques quand on s'auto-héberge, c'est la sauvegarde. Pour le moment, il n'y a concrètement que trois solutions :
* Faire ça en local : ça peut être suffisant pour revenir en arrière, mais si le chat pisse sur la machine, tu vas te retrouver en culotte courte ;
* Faire ça sur un disque externe : mieux, mais faudrait en réalité toujours se trimballer avec ;
* Externaliser la sauvegarde : et donc la confier potentiellement à des malfaisants.

`duplicity` permet de résoudre partiellement le souci de la sauvegarde externalisée : il est possible de chiffrer les fichiers de sauvegarde avant de les envoyer à l'extérieur.

C'est effectivement mieux, seulement tu restes dépendant d'un service éventuellement payant, et en plus, ça reste de la sauvegarde « old school », avec un catalogue en local, un média de sauvegarde.

Pas de quoi faire sauter une braguette, ce serait quand même bien de tenter un truc plus couillu, un machin qui pourrait se répliquer à des dizaines d'exemplaires en quelques minutes, voire quelques heures. Et en fait, tant qu'il s'agit de fichier relativement petit, ce n'est pas si difficile que cela à faire…

Comment alors ? En utilisant le seul système, réparti, robuste et accessible dans le monde entier, j'ai nommé le DNS.

La procédure est relativement simple :
* créer une archive contenant les données sauvegardées (je pense sincèrement qu'au delà de 10Mio, il vaut mieux tenter les choses autrement…) ;
* chiffrer cette archive (avant de montrer son cul au monde entier, on met des gros pixels devant comme dans les pornos jap !) ;
* effectuer une somme MD5 du fichier (cela servira de clé pour le DNS) ;
* encoder le fichier en ASCII grâce à UUencode : cet utilitaire crée des fichiers ASCII à partir de fichiers binaires. À ce moment, nous avons un fichier purement texte représentant un fichier chiffré d'une archive (tu suis toujours là, c'est bon ?).
* Utiliser l'utilitaire `split` pour séparer le fichier en morceaux de 65535 octets (la taille maximale d'un engistrement TXT sur un serveur DNS).

Il suffit alors d'insérer le contenu des fichiers générés par `split` dans des enregistrements TXT dans ton serveur DNS, en prenant bien soin de les numéroter correctement (par exemple <somme MD5>-numéro) et voilà le tour est joué. En quelques minutes, les serveurs DNS secondaires vont récupérer l'intégralité de ta sauvegarde et pour  peu qu'ils soient un peu nombreux (2, 3 ou 4), cela crée autant de copies de cette sauvegarde qui sera alors accessible de n'importe où.

Et pour la taille ? Avec une archive compressée de 319Kio, j'obtiens un fichier chiffré de 320Kio (rien d'extraordinaire) et un fichier uuencodé de 441Kio (soit environ 37% de plus) ce qui nous donne 6\*64+57Kio au niveau de `split`.

Avec quelques bases (dotClear, SPIP, RSSLounge, etc…), un dump compressé MySQL ou des fichiers SQLite doivent facilement atteindre les 6 ou 7Mio chez tout bon singe qui se respecte. En extrapolant un peu, on peut raisonnablement penser que cela permet de placer 10Mio de données dans un fichiers de zone.

Alors ouais, c'est un peu la méthode à la porc, mais reconnais que c'est quand même pas mal efficace. En plus, ça permet de squatter en toute impunité les serveurs DNS secondaires de ton registrar ou de ton hébergeur, sans que celui-ci puisse soupçonner quoique ce soit. Manque juste le script poilu autour de ça qui permet de sauvegarder plus facilement que de tout faire à la main.

Au prochain épisode, une idée pour les gros (très gros) fichiers de sauvegardes.
