Bonjour tout le monde ! 
Je vais essayer de garder ce premier message concis pas TROP long, mais je suis dispo pour discuter plus en détail ensuite. 
tl;dr : qui est intéressé pour qu’on fasse et qu’on s’échange nos backups avec des outils adaptés ? Lisez la suite pour du contexte!
Je suis Quentin, un membre du chaton Picasoft. Je travaille à temps partiel et jusqu’à la fin de l’année au laboratoire de recherche Heudiasyc (à Compiègne), sur un petit projet ANR nommé Isorédu, pour Informatique SOlidaire, RÉsiliente et DUrable.
Il étudie quoi, ce projet ?
Notamment les alternatives aux solutions cloud proposées par les multinationales que vous connaissez bien. Le projet est conçu en « recherche-action », et les « cibles » initiales sont des PME, collectivités et associations, qui utilisent les services cloud parce qu’ils sont simples à utiliser et
résilients, par exemple pour le stockage de données. La résilience, c’est très dur à définir mais les fournisseurs cloud se sont accordés pour proposer de la très haute disponibilité pour pas cher et imposer ce besoin comme allant de soi.
Forcément, une PME ne peut pas développer en interne un tel niveau de disponibilité sans énormément d’argent, de matériel et de compétences.
Pour autant, l’utilisation de ces services ont beaucoup d’inconvénients que vous connaissez bien : dépendance, rapport de force déséquilibré, perte d’autonomie citoyenne, renforcement de la logique capitaliste, centralisation des pouvoirs, etc, tout ça est un peu synonyme et lié.
Quel rapport avec les backups ?
La sauvegarde est un cas d’étude « simple », car il s’applique à beaucoup de structures : les gens ne veulent pas perdre leurs données, peu importe la nature de leurs activités.
Les PME qu’on a interrogées ont soit des systèmes maison à base de « je sauvegarde sur un NAS chez moi toutes les semaines », soit sont chez Google & co, soit rien.
Des questions se posent, par exemple :
- Que proposer comme alternatives à ces structures pour leurs backups, avec un bon niveau de résilience ?
- C’est quoi, un bon niveau de résilience ?
- A-t-on vraiment besoin d’une haute disponibilité, ou juste d’une garantie de ne pas perdre de données ?
La question d’une alternative ne se pose en fait pas qu’en terme de résilience :
- L’impact écologique doit être pensé. Augmenter la disponibilité, c’est souvent acheter du matériel.
- Une solution archi-technique n’est pas appropriable et ne suscite pas la confiance. La convivialité est importante.
- Le coût doit rester faible. On ne peut pas réserver une alternative aux structures qui ont les moyens.
Au final, c’est la difficulté de proposer une alternative avec un mélange « durable-convivial-résilient-inclusif ». Note : je pense que c’est une question qui taraude toutes les luttes contemporaines.
Un point de départ du projet, c’est que dans tous les cas, si on veut protéger les supports de stockage, il faut répliquer, donc il faut du matériel supplémentaire ! Et si tout le monde fait ça, l’impact écologique est colossal.
En d’autres termes, il faut mutualiser : les acteurs doivent pouvoir s’échanger leurs sauvegardes. De ce fait, on ré-utilise le matériel existant au maximum. On cherche donc un système de sauvegarde résilient, solidaire et convivial.
Et alors, il en est où le projet ?
Un backup résilient, c’est deux choses :
- Des sauvegardes en lecture seule des données, pour protéger par exemple des erreurs concernant les données elles-mêmes (« j’ai supprimé tel machin sans faire exprès », etc).
- Des copies distantes (= réplication) des historiques, pour protéger des pannes, incidents, etc sur les supports de stockage eux-mêmes.
Je vais publier un comparatif des outils de sauvegarde et de réplication, dont la « contribution » est de baser les critères techniques de comparaison sur les exigences de résilience, de solidarité, de convivialité et de minimisation de l’empreinte écologique.
Pour donner des exemples, on a probablement besoin de chiffrement à la source si on partage ses sauvegardes, de déduplication pour minimiser l’espace pris, d’outils qui supportent une forte latence puisque les acteurs seront vraisemblablement connectés via Internet et pas un réseau très haut débit dédié, etc.
Sur la base de ce comparatif, l’idée est de réaliser un prototype qui forme une alternative crédible aux fournisseurs de Cloud.
Ok, et ce prototype ?
Prototype, c’est un bien grand mot, car il ne s’agit pas de réinventer la roue. Et à plus forte raison parce que je n’ai pas les compétences ! L’idée est plutôt de combiner des outils existants et de travailler sur la forme de cette combinaison, si ça prend ou pas, pour qui, comment donner confiance, comment donner de l’autonomie à ses utilisateur·ices, rendre le prototype intégrable dans tous types d’infrastructures (i.e. ne pas avoir à réinstaller un système de fichier ou je sais pas quoi), etc. Et je n’ai pas encore les réponses.
Je garde cette section concise car le but n’est pas de rentrer à fond dans la technique.
Le système global que je propose est le suivant :
- Chaque structure est modélisée comme un ensemble de machines qui fait des sauvegardes de certaines données.
- Chaque structure centralise ces sauvegardes sur un machine spécifique, disons un nœud.
- Les nœuds de chaque structure sont interconnectés et forment un cluster. Chaque donnée du cluster est répliquée plusieurs fois diminuer les risques de perte.
Pour les outils eux-mêmes, j’ai proposé de combiner :
- Restic, pour la sauvegarde. Restic chiffre à la source, garantit cryptographiquement l’intégrité et l’authenticité des données, minimise fortement l’espace de stockage nécessaire grâce à une déduplication efficace, etc. Restic est configuré grâce à autorestic.
- Garage, qui crée le cluster de stockage et se charge de la réplication. C’est du stockage objet, donc ça fonctionne a priori bien avec Restic, qui produit des blobs.
- Un serveur REST Restic, pour la centralisation des sauvegardes locales à une structure. L’implémentation de rclone est retenue car elle peut directement communiquer avec Garage via le protocole de stockage objet S3.
Je dis un mot sur mon admiration pour Garage, c’est vraiment un cadeau du père Noël pour moi. Je vous laisse lire le sujet de @quentin qui présente l’outil : https://forum.chatons.org/t/garage-stocker-des-donnees-en-dehors-des-datacenters/3202/10
Il est incroyable, parce qu’il présente des qualités très similaires à d’autres outils « usines à gaz », mais offre d’excellentes performances, marche sur des machines même très peu puissantes, sur internet, supporte les pannes, tout en étant à l’état de l’art sur tout un tas d’optimisation, etc. Bravo, bravo à toute l’équipe.
L’intérêt d’un tel outil est de permettre à des nœuds de tomber sans faire tomber tout le système, voir peut être même d’être alimentés de manière intermittente (nomade ? (bon je crois qu’en l’état c’est pas possible avec Garage mais l’idée est là) alimentation solaire ? etc)
Quel rapport avec les CHATONS ?
On y vient enfin. En fait, il me semble que beaucoup de CHATONS ont bricolé des solutions de backup manuelles imparfaites, ou n’en font pas vraiment, ou s’arrangent entre eux. En tout cas, à Picasoft, nos backups sont imparfaits. Si le DC de Tetaneutral brûle, ben on est très mal.
La question a été abordée plusieurs fois sur le forum, par exemple cette fois-ci. @neil a également proposé de mettre en place un partage de backup entre CHATONS en 2019 .
Sur les problématiques spécifiques aux backups coopératifs, je n’ai trouvé qu’une seule étude qui en traite. Elle date de 2006 et a ses imperfections (pour les curieux·ses).
Néanmoins, elle rappelle qu’il y a un enjeu à travailler sur la confidentialité et l’intégrité des données partagées, mais aussi à réfléchir aux questions d’équité, de la possibilité d’acteurs malveillants, égoïstes, non-coopératifs, etc. Garage permet bien de définir une sorte de « poids » pour chaque nœud, qui répartit le volume de données en fonction des moyens de chacun, mais ne règle pas les autres questions. Par exemple, un acteur qui voudrait stocker trop de données que ne peut en supporter le système pénaliserait les autres.
Au final, pour les chatons, seule la partie partage (donc Garage) serait commune. Le reste pourrait servir aux structures qui n’ont pas encore de mécanisme de sauvegarde robuste.
Pourquoi ce sujet, au final ?
Pour clarifier mes intentions, je n’ai aucun d’intérêt personnel à ce que ça se fasse, je n’y gagne rien. C’est une initiative personnelle, et j’aimerais me rendre utile au collectif. Puisque du temps de travail pourrait y être dédié, je me dis que c’est l’occasion.
1. Pour prendre la température
D’abord, j’aimerais savoir si parmi vous, des structures seraient intéressées pour expérimenter un tel système. Ce n’est pas un engagement, car de toute façon rien n’est prêt/arrêté, c’est une prise de température.
J’aimerais aussi récolter vos opinions critiques, les potentiels freins pour vous, les limites que vous identifiez, etc.
2. Pour soigner la forme
Chaque structure gère son infrastructure différemment. À la main, avec de l’automatisation, avec de l’Infrastructure as Code, avec Yunohost… Un tel système d’échange de backup n’est pertinent que s’il est interopérable entre nos façons de faire. Par exemple, je connais mal la manière dont Yunohost gère les backups, et il me semble qu’un projet de partage de backups était déjà en réflexion? (@ljf ?)
C’est un peu votre lettre au père Noël : si vous êtes intéressée, quelles seraient vos « conditions idéales » vis-à-vis de votre infra ?
3. Pour questionner la pertinence de la proposition
Peut-être que ma proposition n’est pas fonctionnelle et que je ne m’en suis pas rendu compte ! Peut-être qu’un membre de Deuxfleurs va me faire réaliser que Garage n’est pas adéquat pour stocker la sortie de Restic, qui sait (et j’aurais du leur en parler avant, sans doute…).
Peut-être qu’une autre initiative est déjà expérimentée par d’autres structures.
Peut-être qu’en fait, le besoin n’existe pas vraiment. etc.
4. Pour questionner la tension verrou technique/confiance
En gros, plus l’absence de confiance entre acteurs est grande, plus la complexité technique augmente. Une paranoïa complète tend souvent vers une blockchain où tout est prouvé cryptographiquement et indélébile.
Les mêmes questions se posent ici : faut-il implémenter un mécanisme technique supplémentaire qui garantit qu’aucune structure qui participe à l’échange n’abuse du système, ou bien un mode de gouvernance qui gère ces potentiels abus ?
Je penche souvent du côté du mode de gouvernance, mais il faut tout de même penser à la présence de potentiels acteurs malveillants, y compris extérieurs. Par exemple, pour ajouter un nœud à un cluster Garage, il faut les pleins pouvoirs sur le cluster. C’est dangereux, si un tel accès se retrouve dans la nature ou est piraté ! Et puis, qui l’a ? Comment on le transmet ? Qui décide si on peut rajouter une structure ou non ?
Je n’ai pas les réponses, et j’ai aussi envie de stimuler le débat sur ces questions.
Épilogue
J’avais prévu d’être court. Je suis désolé, j’ai fait ce que j’ai pu.
J’espère tout de même que ce sujet rencontrera de l’intérêt et produira des discussions stimulantes.
Je suis bien mal placé pour demander l’attention du collectif, vu mon faible taux de participation aux réunions mensuelles. Peut-être que ce sujet pourrait y être abordé, d’ailleurs ? Une nouvelle fois je ne suis pas disponible pour la prochaine, les soirées sont terriblement chargées depuis plusieurs mois. 
Mais bref, assez parlé de moi, à vous ! Merci de m’avoir lu !!
)
À ma connaissance, Restic n’est pas le seul à supporter une target S3, il y a aussi Duplicity, Dupliciti, kopia et knoxite de ce que j’ai identifié. Peut-être que YunoHost aura envie d’intégrer un de ces outils dans sa distribution ? Sinon une solution intermédiaire c’est de faire un backup Borg sur un NAS local par exemple, et de mirrorer ce backup sur S3 avec un 
