forked from Deuxfleurs/guide.deuxfleurs.fr
Ajout des notes sur les sauvegardes coopératives
This commit is contained in:
parent
63bc50ef6c
commit
7aceef206a
1 changed files with 129 additions and 0 deletions
129
content/vie_associative/conf/sauvegardes-cooperatives.md
Normal file
129
content/vie_associative/conf/sauvegardes-cooperatives.md
Normal file
|
@ -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 !
|
Loading…
Reference in a new issue