1 files changed, 129 insertions, 0 deletions
diff --git a/content/vie_associative/conf/sauvegardes-cooperatives.md b/content/vie_associative/conf/sauvegardes-cooperatives.md
new file mode 100644
index 0000000..ddad228
--- /dev/null
+++ b/content/vie_associative/conf/sauvegardes-cooperatives.md
@@ -0,0 +1,129 @@
+---
+title: Sauvegardes coopératives
+description: Sauvegardes coopératives entre CHATONS
+weight: 10
+---
+
+**Animateurs :** Équipe Picasoft  
+**Prise de note, mise en forme :** Quentin de Deuxfleurs
+
+Vers des sauvegardes solidaires et résilientes.
+
+# À quoi ça sert les sauvegardes ?
+
+Parce qu'il peut y avoir des incidents.
+Exemple de OVH avec une défaillance matérielle, exemple d'une erreur humaine
+Garder un historique des données.
+Restaurer les données telle qu'elles étaient il y a une semaine.
+On a aussi envie de répartir les sauvegardes à différents endroits.
+État des lieux chez les CHATONS
+Aimerait faire un sondage sur comment les CHATONS gèrent leurs sauvegardes.
+
+## Partage d'expérience
+
+Retzien Libre -> Pas toutes les données sauvegardées de la meme maniere.
+Séparer les données crées par les users car irrecuperables si perdues, alors que les données systèmes sont reconfigurables.
+Chez le Retzien, dump de la machine virtuelle.
+Par contre les données Nextcloud plus sensibles, sauvegardes quotidiennes pour pouvoir les récupérer plus rapidement.
+
+Doubler ces sauvegardes par des sauvegardes distantes.
+Deux serveurs, deux sites, les sauvegardes de la veille sont envoyées sur l'autre site.
+Sauvegade J-0 en local, sauvegarde J-1 à distance.
+3 sauvegardes donc.
+
+Distrilab sur Proxmox aussi.
+Sauvegarde locale une par jour, sur le meme serveur.
+Replication sur l'autre serveur tous les 1/4 heures.
+Pour distance, cron pour copier les données à distance sur un NAS.
+0 historique. Peu faire de l'historique avec Proxmox mais prend vite de la place car pas de déduplication.
+Recemment ont essayé Proxmox Backup server, pas completement content car ça prend bcp de temps.
+
+Exarius : volume BTRFS, snapshot, backup disque externe
+Deuxfleurs : restic sur du minio pour le SQL. À plat sur sur du BTRFS pour Garage
+42l : borg chez Picasoft, append only, chiffrement, réflexion sur la sécu.
+
+## En pratique
+
+**Méthode :** Gradation dans la complexité/efficacité : à la main, Sauvegarde auto, Sauvegarde auto + rotation automatique, Tests automatiques et autres propriétés avancées
+
+**Stockage :** Même gradation : meme disque, meme ordi, support amovible, location en datacenter, cloud ?!
+
+**Problème :** stocker à distance des backups ça coute potentiellement cher.
+
+# Imaginer une collaboration entre les CHATONS pour les sauvegardes
+
+Constat que c'est un sujet commun, complexe, avec une composante humaine - le risque d'erreur existe, il y a une responsabilité importante en cas de perte de données, etc. Face à ce constat, l'attrait du cloud est fort pour nombre d'entre nous avec sa promesse d'externalisation des risques. L'idée c'est de réfléchir comment on pourrait être autonome sur ce sujet.
+
+## Proposition 1 - partageons nos sauvegardes
+
+Chacun-e va voir d'autres CHATONS pour demander de l'espace de stockage.
+Difficultés
+ - multiplication des interlocuteurices
+ - heterogeneité des acces (ssh, ftp, etc.)
+ - vérifier que tout fonctionne
+
+Gérer cette complexité est trop compliqué.
+Besoin de normaliser les outils de sauvegarde.
+
+## Recherches sur la normalisation
+
+Il y a plein de façons différentes de faire des sauvegardes, via SSH par exemple, etc.
+La proposition de Picasoft c'est d'utiliser le protocole S3 comme dénominateur commun.
+
+En pratique, on parle d'un démonstrateur à base de Garage et Restic.
+Garage permet un stockage redondant, tolérant aux fautes, matériel hétérogène, peu puissant avec un proto standard S3, compatible avec Restic.
+
+## Proposition 2 : l'île aux chatons
+
+On prend tous les CHATONS et on fait un cluster Garage.
+Point de friction : Gouvernance de l'îlot, super-pouvoirs individuels, volume de stockage hétérogène, traçabilité.
+
+## Proposition 3 : l'archipel des CHATONS
+
+Ensemble d'ilots Garage.
+Les CHATONS qui ont envie montent leur ilot Garage ensemble, c'est à dire un cluster.
+Des groupes de 3, 4 ou 5 CHATONS par exemple.
+Comme ça on réduit le risque en cas de compromission,
+
+Avantage aussi : on créer du lien entre CHATONS.
+
+# Les doutes
+
+Borg va bientot sortir une version 2.0 mais ils ne pensent pas
+non plus implémenter S3. C'est embêtant car Borg est 
+un logiciel de sauvegarde très populaire.
+
+Question sur le fait que S3 pourrait etre un protocole qui ne soit pas libre ?
+Comment on fait si Amazon décider de le changer de manière unilatérale ?
+S3 est un protocole implémenté par une miriade d'outils, et Amazon n'a plus le monopole non plus dessus, plein de presta.
+
+Consommation de ressources ?
+NFS prend 34Mo de RAM en peek seulement.
+Garage prendra plus. Actuellement 2Go en peek.
+Travail en cours sur les perfs.
+Possible d'utiliser sqlite+lmdb en place de LMDB qui pourrait réduire la conso de RAM.
+Quentin Deuxfleurs prense que 500Mo peek
+
+Est-ce qu'on serait obligé de créer 2 ilots minimum ?
+Oui/Non ? On peut stocker sur son propre ilot sur ses sauvegardes,
+mais problème organisationnel.
+L'idée c'est de stocker ses données à un endroit que l'on ne gère pas du tout,
+comme ça si le PC d'un-e admin est compromis, on perd pas les données.
+
+On peut participer à deux ilots ?
+Oui mais si on se fait corrompre, on corrompt 2 ilots, donc pas stratégique.
+En effet chaque noeud peut compromettre l'ilot en entier.
+
+Est-ce qu'on ne peut pas réduire les droits ?
+C'est compliqué de designer un truc correct.
+On préfère une mesure organisationnel à un truc bancale.
+
+Est ce qu'il serait préconisé une sauvegarde locale ?
+Sauvegarde distante longue à restaurer.
+Dépend du cas d'usage et des propriétés qu'on veut avoir, c'est un compromis à réfléchir.
+Picasoft non, mais si tu veux des garanties de service, oui il le faut !
+
+# But du projet
+
+Valider qu'organisationellement ça marche.
+Faire des choses ensemble !