C’est toujours en cours, je suis proche de la fin mais j’ai du mal à prendre du temps pour le terminer (j’ai encore un problème pour le montage du disque virtuel). J’espère pouvoir faire ça sur noël. Une fois cette étape faite, je serai chaud pour passer en beta test.
1 « J'aime »
Bonjour,
J’ai toujours en projet de pouvoir rejoindre un duo de chatons pour faire le troisième d’un cluster Garage.
Je suis justement en train de faire une refonte de mes sauvegardes d’hébergement.
Actuellement, je finalise l’usage de Restic en mode « sftp » pour faire des archives chiffrés et incrémentales (un peu mieux qu’un simple « rsync » boeuf 
)
Ensuite, je me crée un petit serveur S3 (probablement avec MinIO) pour éprouver ma mécanique de gestion d’archive en changeant le support Restic de « sftp » vers « S3 ».
Normalement, en début de janvier 2023, je serais fin prèt pour rejoindre un cluster Garage 
.
Par contre, mes besoins et mes moyens materiel sont petit : je ne pourrais qu’allouer ~200Go de stockage pour l’instant (mes sauvegardes fond ~90Go ) 
200 Go ca correspond à la taille des noeuds que nous avons choisi d’utiliser pour expérimenter garage de notre coté.
Je l’avais testé mais avec une partition dédiée, pas avec le mécanisme de disque virtuel.
L’install s’était bien passée mais je n’ai pas encore essayé de lui faire rejoindre un ilot avec d’autre serveurs.
Fait
1 « J'aime »
Pour info, l’application garage pour yunohost peut être testée pour ceux qui veulent. Elle n’est pas encore intégrée au catalogue yunohost mais disponible ici maintenant GitHub - YunoHost-Apps/garage_ynh
Je suis preneur de retour !
2 « J'aime »
Bonjour Les Chatons backupés 
Je me permet de vous faire un petit retour l’amélioration de mes sauvegardes en vu de pouvoir rejoindre la démarche Garage :).
Mon contexte:
- Tout plein de petit héberement, chacun de mes « clients » ont un sous-domaine en « sleto.net » avec les différents services qu’ils ont souscrit
- Faire des sauvegardes par sous-domaine, afin de pouvoir restaurer (si besoin) chacun indépendament des autres.
- Faire très régulièrement des sauvegarde, l’idée étant d’arrivé à en faire toutes les heures pour des services « léger » (ex: juste une DB à sauver) à tout les jours (ex: NextCloud)
Au début, je suis parti pour déployer ma sauvegarde avec Restic vu que certain d’entre vous ont des très bon retour.
Le problème, c’est qu’avec le nombre de sous-domaines, je dépassais les 70 min pour réaliser mes sauvegardes
J’ai donc changé mon fusil d’épaule et je suir parti avec Rclone (avec crypto mais sans compression). Il ne possède pas de notion d’incrément, j’ai donc mis en place des sauvegardes avec « timestamp » pour garder toutes les versions et j’ai un script qui nétoie régulièrement les vieux « doublon » (un genre de prune/forget de Restic).
Cette solution est beaucoup plus rapide: je fais mes sauvegarde entre 3 à 4 fois moins de temps .
Reste à me brancher sur S3 (Rclone le suppport aussi comme Restic).
Voilà pour mon retour, si cela peux servir à ceux qui se casse les dents sur leur backup
2 « J'aime »
hmmm intéressant Du coup rclone peut elle être un alternative à scp , cryptage en plus ?
Oui, j’ai trouvé rclone assez interessant d’autant plus que je le trouve assez léger dans son usage.
Permet de faire du SCP (SFTP) et du crytage (Crypt).
Et si l’on veux passer à Garage, il support également S3 (Amazon S3).
J’ai pas testé, mais il a également de la compression (Compress).
En faite, vu que je manipule pas mal de documents déjà comprimés (tar.gz, pdf, OpenDocument, jpeg, …), je risque de plus perdre en temps de traitement pour ce que je vais gagner en Go.
Du coup, je suis partie sur une organisation crypt+sftp pour commencer.
Dans quelque temps, quand j’aurais bien éprouvé cela, je passerais à un ensemble crypt+S3 (via Minio).
Et pour finir, je bougerais alors en crypt+S3 (via Garage), ce qui ne devrait pas être le plus compliqué du coup.
Mhhh, je viens de voir ce post, j’attendais un package yunohost pour tester ça. Je vais essayer de mettre ça en place sur une machine dédié ce weekend.
Pour info, je viens d’ajouter l’application garage au catalogue, il faudra une quinzaine de jours pour qu’elle soit directement disponible normalement.
2 « J'aime »
Hello Laurent, merci pour ton retour ! Est-ce-que tu peux nous dire le volume des données sauvegardées ? Est-ce-que le fait de ne pas dédupliquer te fait utiliser + d’espace, ou bien c’est négligeable ?
Pour info, côté Picasoft, on a pas oublié ! On attend l’AG pour parler matériel, et on devrait d’ici un ou deux mois dédier des disques à un cluster Garage partagé.
J’ai confiance sur le fait que ce sujet avance doucement mais sûrement, comme il y a un besoin et des personnes motivées. J’espère que d’ici l’été, on pourra diffuser un peu plus largement.
Bonne semaine à tout·es
1 « J'aime »
Je dois être à environs ~600Go de sauvegarde pour 45 structures hébergé.
En fait, justement je duplique les données: chacun structure est sauvé toutes les heures et j’en concerve 1 sur les 7 derniers jours et les 6 derniers mois (soit 24 + 7 + 6 = 37 sauvegarde au max)
Du coup, ma technique est gourmande en place mais asssez rapide (en 10 min, je sauve les 45)
L’app est dans le catalogue 
3 « J'aime »
Ce sera compatible avec des sauvegardes Borg ou il faut une autre stratégie ??? Il faut que je lise tout cela…
garage est plutôt fait pour restic.
Juste un petit message pour vous dire que je suis très content de voir que ce sujet est super vivant.
Je n’oublie pas mon engagement et ma volonté de faire parti de l’expérience mais que pour l’instant j’arrive pas à ménager assez de temps pour proposer quelque chose.
On a eu une discussion avec @neil et @ppom à Emancip’Asso, et il apparaissait que Garage - ô grande surprise - pouvait ne pas être adapté à toutes les situations. Par exemple pour des vraiment petits serveurs qui n’ont pas plus de 100Mo de RAM à allouer à ça. Je me disais qu’une ouverture ça pouvait être de considérer une version allégée. restic sera toujours notre lingua franca. Par contre, on pourrait avoir un ilot qui se setup avec 2 ou 3 serveurs, un leader qui prend les connexions SSH, et les followers qui rsync le contenu du leader. On aurait un peu moins de souplesse (en cas de crash du leader, faut changer les DNS à la main par exemple et reconfig les rsync, va falloir des serveurs avec des disques d’a peu pres la meme taille, on peut pas agréger facilement, etc.) mais on peut faire des config qui ont a peu près les mêmes propriétés qu’un ilot garage dans des cas simples.
La question qui reste ensuite c’est combien de redondance on veut pour du backup. Je vais faire court : je ne sais pas.
2 « J'aime »
Merci @quentin pour ce message, je relance le débat Garage/pas Garage au sein de Picasoft pour l’occasion
Hâte de voir ce qu’on se proposera !
Je profite du retour du fosdem pour partager l’état de notre réflexion sur les backups.
Comme décrit ici - docs/use-cases · wip · libre.sh / libre.sh · GitLab - nous pensons qu’il faut repartir des cas d’usage.
Nous en avons identifié 2:
- pitr - point in time recover
- dr - disaster recovery
Pour le pitr, nous estimons que le restore doit pouvoir se faire rapidement, et dans le cas idéal, depuis n’importe quel moment.
Il faut aussi considérer où se trouve le « state » la donnée.
De notre coté, nous n’utilisons que des applications avec ObjectStore (s3) et Postgres. (Ok, nous reste RocketChat avec mongo, mais les meme concepts s’appliquent aussi).
Pour l’objectStore, nous utilisons minio qui peut faire du versioning. Cela nous offre le pitr.
Dans Postgres, on utilise wal-g pour streamer les wal vers un bucket, et cela nous fournit le pitr.
(Si je n’avais pas d’objectStore avec du versioning et que du block, alors j’utiliserai zfs, ou peut-etre que xfs ou btrfs ont aussi du snapshot prod ready, a voir, je sais pas.)
Et donc, à chaud, localement, nous avons du pitr.
nous appelons le.pitr aussi la première ligne.
Reste le dr.
Dans le modèle de menace, une des menaces, c’est, et si le.laptop d’une admin est p0wned, et comme les admin ont accès à toute les machines, et donc les backups aussi, alors cet adversaire pourraient supprimer les backups.
Nous recommendons alors à nos organisations contributrices de venir pull leur backup sur notre infra.
et cela est très simple. Nous créons un user readonly pour tous leur buckets (pitr de postgres et data) et à eux de venir pull leur data.
Et là, c’est pas mal \o/
Mais seulement les plus grosses orgs ont des personnes capables de faire cela.
Et là pourrait intervenir un autre chatons.
Si, par exemple avec rclone, on mirror tous nos buckets, avec du chiffrement, sur un autre objectStore, l’adversaire pourrait silencieusement remplacer le bin de rclone et au bout de qq mois… fin de la partie (j’imagine qu’il existe des mécanismse pour éviter cela, je ne connais pas, et je ne sais pas à quel point cela fonctionne).
La seule possibilité que je vois, et elle me.parait couteuse, c’est la suivante.
Nous mirrorons, avec du chiffrement, la première ligne vers la deuxième ligne. Et une autre entité, un autre chatons vient pull la deuxième ligne sur la troisième ligne sur son infra.
Ou alors, le chatons vient puller les données en clair de la première sur la deuxième ligne.
Dans tous les cas, j’aime beaucoup le fait de réflechir à la logique métier de comment mettre les données pitr, dans une première ligne pas trop loin, mais standardisée sur de l’objectStore. Et le reste du problème devient assez standard, comment déplacer des objets d’un ObjectStore à l’autre.
Voila, j’ai pas trop de réponses sur comment on collabore entre chatons pour les backups, mais j’ai l’intuition qu’utiliser un « standard » tel que s3 (oui je sais… ) va nous permettre de faciliter cette collaboratio.
Et une autre fois, on parlera de l’idée d’une guilde de fournisseur, fournisseuse de bucket d’ObjectStore
2 « J'aime »