Partage de backups entre CHATONS : vers une expérimentation?

Bonjour tout le monde ! :smile:

Je vais essayer de garder ce premier message concis pas TROP long, mais je suis dispo pour discuter plus en détail ensuite. :slight_smile:

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 : Garage, stocker des données en dehors des datacenters - #10 par quentin
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. @Association42l 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. :confused:

Mais bref, assez parlé de moi, à vous ! Merci de m’avoir lu !!

12 Likes

Je suis partant avec @enough.community pour partager des backups.

2 Likes

C’est une excellente initiative. Je vais essayer de convaincre mes petits camarades de mon chaton favori @Hadoly , (le chaton historique peu efficace mais finalement assez résilient :slight_smile:

3 Likes

Excellente initiative en effet! Ça fait un moment que l’idée de mutualiser des ressources entre chatons me trotte dans la tête, le faire sur les backups me semble être l’idéal pour un test à l’échelle réelle et plus si affinités.

@clawd.fr participera à ce projet

3 Likes

Bonjour et merci de ce sujet qui me semble si primordial au sein de notre collectif :slight_smile:

Grâce à vous, nous dormons un peu mieux en sachant que nos sauvegardes sont hébergées chez Picasoft depuis quelques mois ! Et je rejoins et partage entièrement les arguments que tu as énoncés dans ce message.

Pour le moment, nous ne pouvons pas matériellement prendre part à la réplication des données avec Garage faute de notre infrastructure de petite taille, notamment en terme d’espace disque ; mais nous avons hâte de la rejoindre lorsque nous en aurons les capacités.

Nous n’avons pas testé Restic, mais je comprends l’enjeu de trouver un logiciel compatible avec du stockage objet (et donc avec Garage), ce que Borg Backup ne permet pas. À l’inverse, Borg peut compresser les sauvegardes (au-delà de la déduplication et du chiffrement), ce qui présente un intérêt majeur pour notre cas d’utilisation à espace disque limité (comparatif des deux solutions).

Avec Borg, nous avons pris le temps de consolider quelques solutions pour répondre à diverses considérations de sécurité d’un système en production :

  • Sauvegardes en mode « append-only » : protège les savegardes si nos serveurs sont compromis
  • Chiffrement intégral : même si on se sent bien chez Picasoft, dans notre modèle de sécurité, nous partons du principe que les données que nous stockons sur notre serveur de sauvagarde sont open-bar. Comme si on ouvrait un serveur HTTP à la racine qui sert tous nos fichiers, littéralement.
  • Suppression régulière et automatique des sauvegardes : la partie qui a été la plus difficile pour nous avec Borg − comment supprimer nos sauvegardes automatiquement, en sachant que :
    • Nos serveurs en production n’ont qu’un accès en lecture seule sur les sauvegardes précédentes (le mode append-only) ;
    • On ne peut pas écrire de cron à cet usage sur notre serveur de sauvegarde, car la commande pour supprimer nos anciennes sauvegardes nécessite d’entrer la phrase de passe pour déchiffrer les sauvegardes et supprimer les plus anciennes. Il faudrait donc stocker ce mot de passe en clair sur la machine de sauvegarde, ce qui n’est pas possible car rappelez-vous, on part du principe que tout le système de fichiers est open-bar.
    • Nous ne souhations pas supprimer nos anciennes sauvegardes à la main et dans l’idéal, nous ne souhaiterions pas affecter une machine supplémentaire à cette tâche car cela étendrait notre surface d’attaque et complexifierait notre infrastructure pour une simple tâche.

Il s’agit de contraintes très terre-à-terre, mais nous ne les avions pas pleinement considérées avant de nous lancer, mis à part pour le chiffrement.

Saurais-tu nous dire si, à l’usage, l’ensemble Restic + Garage répondrait à ces trois contraintes, et en particulier à la troisième ?

~ Neil

2 Likes

Sauf que ce mode ne fonctionne pas de la façon dont on peut s’y attendre. La fonctionnalité est mal conçue (un peu cheap) et il y a de fort risque de déclencher la suppression sans le vouloir au final…

Bonjour tout le monde,

Merci pour vos réponses enthousiastes ! :smile:
Comme je l’ai précisé, ce sujet est une prise de température et l’expérimentation, si elle se fait, sera idéalement co-construite et appropriable par toutes les structures. Deuxfleurs, le chaton à l’origine de Garage, devrait apporter des éléments de réponse prochainement.

En attendant, j’essaye de répondre sur la partie technique à @Association42l. Merci pour cette question très intéressante.
Pour la suite, je dis client pour « une machine d’un chaton qui veut sauvegarder ses données », serveur de sauvegarde pour « la machine du chaton qui reçoit les backups des clients » et noeud pour « une machine qui fait partie du cluster de stockage » (les trois peuvent être confondues).

  • Borg ne gère pas directement de backend objet, mais c’est toujours possible de passer par l’intermédiaire de rclone. Quand je disais « compatible stockage objet », je voulais plutôt dire optimisé, au sens où Borg comme Restic produisent des blobs de quelques MB qui sont un cas « simple » dans un protocole comme S3 (pas besoin de découpe, etc. Après, c’est mon intuition, mais il y a moyen que je me plante d’autant que tous les stockages objets ne gèrent pas pareil).
  • Restic gère enfin la compression ! Ce n’est pas encore sorti, mais c’est implémenté et il sera possible de migrer depuis un dépôt existant. Les tests anecdotiques semblent plutôt bons.
  • L’implémentation de l’API REST Restic par rclone propose un mode append-only, une authentification multi-utilisateur et la possibilité de restreindre l’espace d’écriture/lecture de chaque utilisateur. Les utilisateurs peuvent aussi s’authentifier avec un certificat signé par une CA locale.
  • Comme pour Borg (il me semble), Restic chiffre, signe et authentifie l’intégralité des données, et des métadonnées, dont l’index. Son modèle de menace est assez solide.

En revanche, je ne suis pas fan du mode append-only. Même s’il répond au problème réel qui fait qu’un serveur compromis pourra supprimer toutes ses sauvegardes, je n’arrive pas à trouver de solution élégante pour supprimer les vieilles sauvegardes avec ce mode (d’ailleurs, il faut noter que même en supposant un serveur très sécurité, à part, qui a l’autorisation de supprimer les sauvegardes, l’automatisation reste complexe, e.g. si la politique de sauvegarde est du style « garder les N derniers backups », un attaquant pourrait alors faire N+1 backups pollués depuis une machine compromise, ce qui supprimerait effectivement tous les backups non pollués, etc…)

on part du principe que tout le système de fichiers est open-bar.

veut aussi dire que vous partez du principe que le système de fichier pourrait être remis à zéro, même sans connaissance de la clé ? Le serveur de sauvegarde, dans un cluster de stockage objet, a forcément connaissance de la clé d’accès à son bucket. Donc une compromission du serveur de sauvegarde permet de toute façon de supprimer l’ensemble des données du bucket, même si le déchiffrement n’est pas possible car chiffrées à la source.

Garage n’implémente pas le versioning d’objets, ce qui permettrait de rajouter un délai entre ordre de suppression et suppression effective, et donc de limiter les impacts d’une compromission. Mais ça alourdirait aussi pas mal l’espace de stockage. Peut-être que cette fonctionnalité pourrait être implémentée au niveau du serveur REST, ce qui serait équivalent et plus simple, puisque le append-only existe déjà.

Ceci étant, dans le système proposé, chaque client n’a accès qu’à ses propres sauvegardes, ce qui limite déjà l’impact. On pourrait imaginer que la clé privée est stockée hors-ligne pour les clients critiques, ce qui oblige à faire des prune à la main. Mais je ne suis pas entièrement satisfait de cette réponse…

La même question se posera pour l’administration du cluster Garage, peut-être en pire : il me semble que pour le moment, chaque opérateur de nœud (donc chaque chaton, sûrement) a un accès administratif à l’ensemble du cluster et peut créer des clés d’écriture et de lecture sur tous les buckets, ce qui est autrement plus dangereux.

Toute cette question est intéressante pour moi : qu’est-ce-que la solution proposée doit traiter ? Quelle est sa valeur ajoutée (interopérabilité, protection totale contre les erreurs, contre les attaques, création de lien, tout à la fois…) ? Est-ce-que, comme Restic, on part du principe qu’un a au moins une machine à qui on fait confiance ? Plusieurs machines ? Est-ce-qu’on cherche un mode de gouvernance, une sécurité totale, un compromis ? J’espère trouver des éléments de réponses avec vous :wink:

Salut @Chosto,

(Note : Deuxfleurs est encore candidat CHATONS, normalement la confusion sera bientôt terminée, désolé pour l’ambiguité :stuck_out_tongue: )

Merci pour ton message qui nous fait chaud au coeur. Nous aussi on est motivés pour donner un coup de main à ton projet.

Par la suite, je me permets de donner notre avis sur certains points évoqués :

Un serveur Restic → Je ne comprends pas pourquoi tu veux faire restic <-> rclone serve restic <-> Garage. Le client Restic supporte S3 directement. Tu as une vidéo démo ici : https://rfid.deuxfleurs.fr/presentations/2021-11-13/garage/video/02-restic.mp4
Et tu as de la doc ici : Garage - An open-source distributed storage service

Y a t’il des fonctionnalités avancées qui ne fonctionnent qu’avec le serveur Restic ? Si oui, sont elles nécessaires ? Dans mon usage Restic + S3 c’est parfait, pas besoin de plus :stuck_out_tongue: Et S3 a du contrôle de permissions.

Alimentation de manière intermittente → On sait que RésiLien expérimente ce mode d’alimentation intermittente mais pour notre part on n’a pas pris en compte cette contrainte dans la conception du logiciel (parce que OMG c’est compliqué déjà comme logiciel !). Peut-être qu’ils pourront t’en dire plus après quelques temps. Je sais que Nathan Freitas du Guardian Project se demandait à quel point ça pouvait tourner sur un cluster de téléphone, par exemple pour faire une plateforme de stockage éphémère sur batterie.

Le tryptique confidentialité - intégrité - disponibilité → avec le chiffrement par Restic, la possibilité de servir le contenu alors que un ou plusieurs noeuds sont down, la grosse question qui reste est sur l’intégrité principalement. Avec un mode de replication à 3 et avec des outils de scrub + repair, Garage a quelques armes contre la perte de données/corruption de données non malveillante. Par contre, et c’est une crainte de certains membres de Deuxfleurs, si tu es membre du cluster (ou si un membre du cluster se fait hacker), alors le membre (ou la personne qui a hacké) peux effacer tout le cluster (exemple : tu crées une clé et tu lui donnes les droits sur tous les buckets du cluster, et ensuite tu utilises la clé pour effacer tous les buckets avec l’API S3).

Sur le plan technique, en fait un noeud Garage combine 2 composants : « une gateway S3 » et un « storage node ». La gateway S3 envoie des requetes aux storages nodes pour construire sa réponse. Au lieu de partager les clés d’API à travers le cluster, on pourrait les laisser en locale sur une gateway trusted (chaque participant aurait alors sa gateway trusted), et trouver un moyen de signer les RPC dans le cluster avec la clé, de sorte que uniquement quelqu’un qui est capable de signer un RPC avec la bonne clé puisse supprimer des données. Ça résout pas tous les problèmes (comment on gère les changements de topologie ? Peut-être en la faisant signer ce changement par X noeuds ? comment on gère l’ajout/suppression de clés sur un bucket ? etc.). De manière plus simple, on pourrait bind des buckets à une gateway précise de sorte que seule cette gateway ait le droit de les manipuler (ainsi que leurs données), et les storags nodes (bienveillants) valideraient à chaque requête que la gateway est bien autorisée à executer cette action. Si la gateway venait à disparaitre, il faudrait un changement de topologie validé par la majorité pour supprimer la gateway disparue, qui entrainerait du coup que les buckets soient marqués abandonnés et deviennent gérables pas toutes les gateways. Ça c’est purement prospectif et c’est pas dans notre roadmap, mais si vous avez de l’argent ou du temps, voilà une direction pour résoudre ce problème sur Garage :stuck_out_tongue:
On parlait aussi du processus d’adoption d’un nouveau noeud ici : #310 - require new nodes to be validated before being able to connect - garage - Gitea: git with a cup of coffee - Peut-être qu’on veut qu’un nouveau noeud soit adopté par au moins $n$ noeuds avant de rejoindre le cluster, $n$ configurable ? C’est un chantier qui semble moins ambitieux que le précédent, mais qui résout qu’une partie du problème en contrepartie.

Sur le plan organisationnel, tout à fait personnellement, je pense aussi qu’on peut imaginer des mesures pour résoudre ce genre de problèmes, mais c’est pas un avis qui fait forcément consensus en interne car le risque de compromission augmente mécaniquement avec le nombre de participants. Donc même si tu minimises le risque par participant, quand ton nombre de participant devient grand, ce risque est loin d’être négligeable (et tend vers 1 quand le nombre de participants tend vers l’infini). Supposons qu’on ait tous-tes 1% de chance de se faire compromettre dans les 5 ans à venir, à 10 personnes dans le cluster, ça nous fait ~10% de chance de compromission du cluster dans les 5 ans à venir (1 - la probabilité que personne ne se fasse compromettre, soit 1 - 0.99^10 // et la proba passe à ~63% pour 100 personnes en guise de référence). Après le danger, c’est de perdre des backups, on devrait s’en rendre compte assez rapidement (et ça peut être un requirement de checker régulièrement l’intégrité des backups), et si ce cluster Garage est utilisé que pour les backups distants en sachant qu’une copie locale existe, on peut décider de vivre avec. On peut aussi mettre un nombre maximal de participants par cluster (eg. 10 participants). Dans tous les cas, je pense que c’est un choix qui doit être informé : l’existence du risque doit être documentée.

Les quotas - On a un travail en cours pour implémenter des quotas par buckets ici : #326 - WIP: improve internal item counter mechanisms and implement bucket quotas - garage - Gitea: git with a cup of coffee. Et donc ça permettrait d’éviter qu’un user maladroit (mais pas malveillant) ou un script fou remplisse le cluster. Elle devrait prendre un peu de temps à arriver dans une release parce qu’on va devoir pas mal tester en amont mais elle devrait arriver !

Le append only - L’API S3 a un système d’ACL et de Policy management qui permet entre autre d’interdire tout requête qui consiste à supprimer des fichiers. Garage n’implémente pas ces endpoints et à la place à un système de permission très basique (owner, read, write). On peut discuter de rajouter une permission append, qui serait un write sans le delete (il y aurait des questions sur l’overwrite à gérer oui c’est vrai !) ou d’implémenter un bout des ACL ou Policy Management de S3. Clairement, c’est pas négligeable comme travail et du coup c’est pas prioritaire dans notre roadmap, mais c’est pas impossible non plus à faire, et encore une fois, si le besoin est là ça peut nous motiver.

Après pour la garbage collection, il te faudrait une autre clé qui elle a les droits de suppression sur le bucket, et qui serait possiblement sur ton poste de sysadmin. Tu aurais alors probablement un script qui lancerait les bonnes commandes et te demanderait de manière plus ou moins intéractive le mot de passe du backup pour faire la compaction/garbage collection.

Pour notre part, on ne fait pas (encore ?) du backup append-only.

La manière dont Yunohost gère les backups - J’ai eu la chance d’échanger avec LJF aux JDLL et on avait parlé Garage, et tout de suite la question des backups partagés est arrivé sur la table x) Je ne connais pas les autres projets de backup partagé de Yunohost par contre. En tout cas, de mémoire, LJF me disait que Yunohost avait une intégration avec Borg, qui malheureusement ne supporte pas S3 :frowning: À 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 mc mirror ou un rclone sync par exemple, ce qui sera moins efficace qu’une solution intégrée mais qui peut nécessiter moins de développement et suffire à certain-es.

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 - À notre connaissance, Restic devrait bien fonctionner avec Garage, en tout cas c’est un objectif affiché du projet : bien fonctionner avec les logiciels existants utilisant l’API S3 pour peu qu’ils aient pas besoin d’un endpoint qu’on a pas implémenté. Dans nos tests Restic a fonctionné à merveille. On peut pas garantir 0 bug mais si vous les rapportez, on devrait être en mesure de les corriger.

En conclusion :

  • Garage devrait fonctionner sans peine avec Restic

  • Pour les utilisateur-ices de Borg, il est possible de mirrorer une sauvegarde « locale » Borg dans Garage avec rclone ou minio-client.

  • Notre inquiétude principale est que tout membre du cluster puisse effacer le cluster en entier. On a pas de solution technique simple à proposer. On a pas de consensus sur le fait qu’une mesure organisationnelle serait suffisante.

  • Les autres questions techniques (ACL, quotas, intégration yunohost, etc.) me semblent gérables (en comparaison).

Vis à vis de notre engagement :

  • Je peux me réserver du temps pour répondre aux questions/expliquer le fonctionnement de Garage/accompagner dans l’installation du logiciel/remonter les bugs ou frictions que vous trouvez sur le forum, sur la salon Matrix de Garage ou en participant à des réunions visio dédiées

  • On peut mettre des noeuds à disposition pour un cluster backup de test

4 Likes

Bonjour tout le monde,

Désolé pour le temps de réponse. Après discussions, il est vraisemblable que je ne puisse pas mener cette expérimentation sur le projet, ce qui à la fois une « mauvaise » nouvelle (mon temps est limité) et une « bonne » (moins de contraintes sur le format). Peut-être qu’un groupe de travail pourrait se constituer autour de ce projet pour en définir les contours, spécifiquement pour les CHATONS donc. :wink:

@quentin, merci d’avoir pris le temps de faire cette réponse! :smile:

Serveur restic

L’idée du serveur Restic était née dans l’hypothèse où la forme du prototype pourrait être un genre de Raspberry clé en main, qui fait à la fois office de serveur de backup local et de noeud de réplication. Dans ce scénario, le serveur Restic gère l’authentification locale des machines et est connecté à un ou plusieurs buckets. Il n’y a pas vraiment de fonctionnalités avancées, sinon l’append only sur lequel je suis mitigé et des trucs de sécu genre validation d’un certificat client. Ça permet aussi des infrastructures avec des postes qui sont pas connectés à l’Internet (même si bon, en vrai…)
Mais c’est clairement pas un composant essentiel!

Alimentation intermitante

Peut-être qu’en considérant tous les nœuds alimentés par intermittence dans une zone à part, au sein d’un cluster plus « standard », ça le ferait ?.. :stuck_out_tongue:

Intégrité

Merci pour les détails. C’est aussi la crainte que j’ai eu en faisant mes tests en voyant que tous les nœuds du cluster pouvaient exécuter toutes les commandes d’admin possible.
Je partage tes réflexions et j’ai aucune « certitude » qui me vient. Inclure des mécanismes de vote par majorité a tendance à augmenter l’inertie, surtout en grand nombre (cf le collectif CHATONS lui même), ce qui peut être un frein pour l’adoption. Alors peut-être des plus petits cluster, mais dans ce cas moins résilients.
De l’autre côté, signer les requêtes ça paraît pas déconnant et j’ai pas l’impression que ça induise de complexité supplémentaire pour les utilisateur·ices. Pour le changement de topologie, une option pour ajouter un nouveau noeud pourrait se faire à la manière des introducers de Syncthing, i.e. un noeud a le droit de rentrer s’il a été signé par un autre noeud. Vu qu’un noeud qui entre n’a vraisemblablement pas le pouvoir de faire des dégâts irréversible, ça pourrait se combiner avec un mécanisme plus collectif d’exclusion?

Enfin, comme tu le dis, pour moi aussi c’est très prospectif et pour une expérimentation, je ne sais pas d’où on devrait partir.

Quotas

Génial :smile:

Append-only

+1 pour le compromis clé append/clé delete. Il faudrait en revanche que le poste sysadmin ait toutes les clés des repos Restic (ce qui en ferait une machine très sensible)… bon, en tout cas il me semble pas que ce soit le sujet le plus critique.

Yunohost

Je m’en veux de vous avoir manqué aux JDLL, franchement.

Pour Yunohost il me semblait bien qu’il y avait une histoire avec Borg. J’avais directement pensé à rclone en me disant que ça avait l’air robuste, mais niveau performance j’ai aucune idée d’à quel point ça les dégraderait. En première intention ça pourrait fonctionner ? Pour les CHATONS « mono-serveur » avec Yunohost (ou des particuliers, à terme), peut-être qu’intégrer Garage directement dans la distribution et faire tourner un noeud de réplication dessus serait intéressant?

1 Like

Je pense que ce serait effectivement une bonne idée. Je t’invite à lancer un sondage pour fixer une date pour un premier temps d’échange en visio des personnes intéressées par le projet.

Il y a une app restic (un peu moins fiable que l’implémentation yunohost de borg, mais ça s’améliore).

1 Like

Pour toutes les structures intéressées par l’expérimentation, je vous propose un premier contact. Le sondage est par ici : Sondage - Partage de backups entre CHATONS : prise de contact - Framadate :smile:

J’ai essayé de prendre des dates assez larges pour avoir une chance de trouver un moment.

1 Like

Bonjour,

Le partage des sauvegardes est un sujet qui nous intéresse chez @Resilien . Aujourd’hui nous téléversons les sauvegardes chiffrées par Restic sur un stockage distant dans le « cloud » et nous souhaitons à terme déplacer ce stockage vers un environnement plus maîtrisé. Nous expérimentons avec Garage dans le but d’internaliser le stockage des sauvegardes.

Alimentation de manière intermittente → On sait que RésiLien expérimente ce mode d’alimentation intermittente mais pour notre part on n’a pas pris en compte cette contrainte dans la conception du logiciel (parce que OMG c’est compliqué déjà comme logiciel !). Peut-être qu’ils pourront t’en dire plus après quelques temps.

En effet, comme l’a écrit @quentin, nous avons une partie de notre infrastructure que nous éteignons la nuit. Nous avons un cluster Garage depuis quelques semaines qui est installé à travers plusieurs zones de notre infrastructure dont une partie sur les serveurs que l’on éteint quotidiennement. Pour l’instant nous n’hébergeons que des sites webs statiques sur ce cluster mais ça marche très bien (nous utilions le mode de réplication 3-degraded).
Nous avons un Traefik agissant comme équilibreur de charge et redirige vers l’un des trois serveurs formant le cluster. Il effectue des healthchecks pour ne pas rediriger vers les machines qui peuvent être éteintes. Le site web https://simon.constans.io/ est hébergé sur ce cluster Garage et chaque requête arrive donc sur un serveur différent du cluster Garage.

Pour l’instant nous n’avons pas de problème important à signaler. Il semble qu’il y a eu un souci de synchronisation lorsqu’une machine s’est rallumée, mais le problème s’est résolu par lui-même au bout d’un petit moment. Nous continuons nos expérimentations avec Garage et à peaufiner notre architecture :slight_smile:

Nous allons voir en fonction de nos disponibilités pour répondre au sondage de prise de contact.

3 Likes

Hello @KillianKemps, merci pour le partage d’expérience. Le mode 3-degraded semble super intéressant, notamment pour des données qui sont en append-or-delete comme les sauvegardes. Est-ce-que les serveurs que vous éteignez se trouvent des zones distinctes de l’infra ?

@ljf, @Association42l, @stephane et @dachary, @Angie, je vous ping au cas où vous voudriez en discuter de vive voix (les premières dates sont dans une semaine) : Sondage - Partage de backups entre CHATONS : prise de contact - Framadate

Je passe mon tour : le sujet est trop technique pour moi et j’ai plein d’autres choses à faire. Mais tenez-nous au courant de ce dont vous discutez (ici et lors des réunions mensuelles).

Est-ce-que les serveurs que vous éteignez se trouvent des zones distinctes de l’infra ?

Nous avons quatre serveurs qui font partie du cluster Garage de test actuel. Un situé dans le département de la Loire, un en Allemagne chez Hetzner et deux dans les Côtes d’Armor. Ces deux derniers serveurs sont éteints chaque nuit.

Avec le mode 3-degraded la lecture des données est possible tant qu’il y a au moins 2 serveurs sur les 3 qui sont allumés, ce qui correspond à notre cas :slight_smile: .

Bonjour à tous,
J’ai raté le sujet, et je ne réponds que maintenant. Coté caracos.net , on a opté pour une infra full yunohost vanilia pour faciliter une éventuelle rotation entre sysadmin en ayant un minimum de documentation en propre.
Ce qui implique qu’au niveau sauvegarde, on est aussi complétement intégré à Yunohost (et donc borg) sur trois machines, qui sont sur trois sites différents, et qui se sauvegardent entre elles.

Je n’ai pas les compétences techniques de suivre tous ce que vous avez mentionné, mais j’ai une des trois machines qui ne fourni que de la sauvegarde au deux autres et qui est donc en redondance. Je suis prêt à tester si il y a une solution intégrée à yunohost sur cette dernière machine.

Le premier créneau qui ressort du sondage est dans deux jours (mercredi 29 juin 2022 - 19h - 20h), est-ce qu’on se fixe dessus?

@quentin toi qui es en réserve dessus, ça t’irait ou tu peux pas encore te prononcer?

:smiley_cat:

Ok pour moi le mercredi 29

Ok pour moi aussi, est ce que ça vous va sur BBB?

1 Like