Peer-to-peer et sauvegarde croisée

Tags associés : , , posté le 1 october 2006


Logo associé au billet intitulé Peer-to-peer et sauvegarde croisée

Je viens de terminer le livre Peer-to-peer, comprendre et utiliser de Fabrice Le Fessant et une perspective intéressante est évoquée en fin d'ouvrage concernant les sauvegardes personnelles qui sont aujourd'hui un réel casse-tête (en tout cas pour moi). La technique consiste à utiliser l'espace inutilisé des machines du réseau des réseaux comme autant d'espace de stockage et donc de sauvegarde pour vos données personnelles (bien entendu chiffrées).

Évoquée ainsi, l'idée est toute simple[1]. Mais il fallait y penser, imaginez l'économie de support(s) réalisée ! Il suffit d'une connexion haut débit pour synchroniser/récupérer vos données à tout moment. Mais détaillons d'abord le processus :

  • vous sélectionnez les données à sauvegarder ;
  • ces données sont chiffrées et réparties sur des machines distantes ;
  • vous pouvez à tout moment récupérer vos données et les déchiffrer ;
  • il est possible de synchroniser vos données à intervalles réguliers ;
  • en contrepartie, vous proposez votre espace non utilisé pour stocker les données chiffrées des autres utilisateurs.

Le principal problème des sauvegardes réside dans la pérennité des données. Quel que soit le support actuel, et je parle ici de support - pas de format de données, vous savez bien que seul un format ouvert vous garanti une interopérabilité future... - , ce support est périssable. Un CD ou un DVD franchit difficilement son cinquième anniversaire, les disques durs sont fragiles aussi. La solution actuelle à mon avis la plus fiable est le raid + synchro distante régulière mais c'est contraignant... et coûteux ! Il faut le double de capacité en local + une capacité équivalente distante.

Or, faites la somme de tout l'espace non occupé dont vous disposez actuellement. Multipliez ça par le nombre de machines en ligne. Il doit bien y avoir de quoi faire une sauvegarde redondante non ? :-)

Passons maintenant aux inconvénients qui ne sont pas oubliés dans le livre. Tout est dans l'algorithme de redondance des données. Alors qu'il est évident qu'une sauvegarde quotidienne sur un tel réseau est pertinente, qu'en est-il si je stocke des données que je souhaite récupérer des années plus tard ? Certaines machines auront disparues, peut-être que le logiciel de stockage sur le réseau aussi. L'algorithme de chiffrement aura probablement évolué, ça reste un casse-tête aussi. Mais l'idée est là et je la trouve bonne, il reste à creuser un peu tout ça. On creuse ensemble ?

Notes

[1] L'annexe en question est en libre téléchargement sur le site des Éditions Eyrolles, je vous invite bien évidemment à la lire. Pour une critique rapide du livre, il s'adresse aux débutants du peer-to-peer mais peut être intéressant si vous envisagez de partager des fichiers au sein de communautés restreintes.

2 Commentaires

Pour le coup, j'aurais vraiment du mal à disséminer mes archives sur le réseau. Car que se passe-t-il si le réseau (tout ou partie) se casse ? est-on sur de pouvoir à tout moment reconstituer ses archives ?

Ca me parait bien risque tout ça (sans compter l'éventuelle possibilité que qqn déchiffre les données des autres...)

Toi qui disait avoir du mal à confier des données à des prestataires externes, je suis étonné de te voir avancer de telles idées ;-)

"vous savez bien que seul un format ouvert vous garanti une interopérabilité future..."

Je sais pas si ça garantit, je dirais juste que tu augmentes significativement tes chances... contrairement à un format fermé où tes chances sont nulles...

1 | NiCoS, le 1 October 2006 à 23h

> Car que se passe-t-il si le réseau (tout ou partie) se casse ?

Comme il est indiqué page 144 du livre (ou 7 du pdf), il existe des algorithmes permettant d'assurer une redondance des données suffisante à mon avis (par exemple stockage sur la moitié du réseau).

> Ca me parait bien risque tout ça (sans compter l'éventuelle possibilité que qqn déchiffre les données des autres...)

Selon la clé de chiffrement et l'algorithme utilisé, il est possible que les données envoyées soient plus difficiles à déchiffrer que l'accès à ta machine :-)

> Toi qui disait avoir du mal à confier des données à des prestataires externes, je suis étonné de te voir avancer de telles idées ;-)

C'est assez différent. Bien sûr il faudra que l'algorithme de chiffrement et la technologie employés soient accessibles pour ne pas être tributaire d'un seul éditeur. D'autre part, j'ai pas vraiment l'impression qu'avec une telle solution on se fasse de l'argent sur mes données personnelles.

> Je sais pas si ça garantit, je dirais juste que tu augmentes significativement tes chances... contrairement à un format fermé où tes chances sont nulles...

Je suis bien d'accord, je me suis un peu emporté ;-).

2 | David, biologeek, le 2 October 2006 à 12h

Ajouter un commentaire


Billets contextuels

Mozilla Weave : la libération des données utilisateurs par Mozilla

Logo associé au billet intitulé Mozilla Weave : la libération des données utilisateurs par Mozilla

La nouvelle est tellement énorme qu'il est dommage de l'annoncer en ces périodes de fêtes mais ça fait un sacré cadeau de la part de Mozilla : Weave, le framework pour vos données, vient de sortir en version beta ...

★ Quel avenir pour les applications web libres ?

Logo associé au billet intitulé Quel avenir pour les applications web libres ?

Devant la prolifération des coffres forts 2.0, je me pose cette question depuis un bon moment maintenant et je me suis dit qu'on pourrait essayer d'y répondre à plusieurs entre utilisateurs, concepteurs et libristes. Après le succès ...

Le futur du développement logiciel

Logo associé au billet intitulé Le futur du développement logiciel

Voici une traduction de l'article intitulé The Future of Software Development écrit par Alex Iskold et publié sur Read/WriteWeb qui reprend les bases et qui va remotiver tous les développeurs qui me lisent ;-). Je manque de temps en ...


© 2004-2009 David Larlet - Licence (presque) libre - Site enfin propulsé par Django et hébergé par Typhon.