Différences

Ci-dessous, les différences entre deux révisions de la page.

--- fr:rapports:2021:09-05 [2021/09/05 17:04] – hgo
+++ fr:rapports:2021:09-05 [2022/07/22 13:15] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 6: / Ligne 6: @@
 Présences :
 - Celo
 - HgO
@@ Ligne 31: / Ligne 32: @@
 En gros, l'idée c'est d'avoir plusieurs méthodes et plusieurs lieux de backup, pour que si un se casse la gueule on a toujours une autre méthode de secours.
--> 3 lieux différents
+- 3 -> 3 lieux différents
--> 2 backups différents, deux méthodes (par exemple différentiel et dump)
+- 2 -> 2 backups différents, deux méthodes (par exemple différentiel et dump)
--> 1 source.
+- 1 -> 1 source.
 Donc les fichiers qui utilisent une base de données sont une sources. Un dump SQL est une seconde source.
@@ Ligne 124: / Ligne 125: @@
 Inconvénient : on a 1 backup, on n'a pas d'historique. rsync ne gère pas la rétention des données.
-##### [duplicity](http://duplicity.nongnu.org/)
+##### duplicity
+http://duplicity.nongnu.org/
 Il permet de créer un dossier avec tous les fichiers dedans, et on peut faire des incréments. Par exemple, à une date donnée, on fait une copie de tout, puis dans le dossier 2 septembre, il fait des liens sympboliques vers les fichiers du premier dossier qui sont en commun.
@@ Ligne 134: / Ligne 137: @@
 Il permet deux méthodes de chiffrement, GPG, du chiffrement assymétrique ou du chiffrement symétrique. Il gère aussi la rétention et est compatible avec plusieurs stockage à distance.
-##### [borg](https://www.borgbackup.org/)
+##### borg
+https://www.borgbackup.org/
 Borg est un peu comme duplicity pour la base (différentiel, incrément, chiffrement (mais que symétrique)) par contre il rajoute une notion : la déduplication.
@@ Ligne 148: / Ligne 153: @@
 Désavantage : borg limite le type de stockage pour les backup, c'est soit du local fichier, soit du distant ssh avec serveur de l'autre côté.
-##### [borgmatic](https://torsion.org/borgmatic/)
+##### borgmatic
+https://torsion.org/borgmatic/
 C'est un wrapper autour de borg. En fait, on a des fichiers de configuration en .yaml qui permettent de faciliter la configuration de borg.
@@ Ligne 156: / Ligne 163: @@
 Problème : on ne le trouve pas toujours bien à jour dans toutes les ditributions. Mais borg est du go, borgmatic est du python, on peut s'en sortir mais ça n'est pas toujours évident à maintenir.
-##### [restic](https://restic.net/)
+##### restic
+https://restic.net/
 restic a les mêmes avantages de borg, mais la différence, c'est qu'il peut backuper sur un grand nombre de stockages. Lorsqu'on fait du stockage distant, on aime bien utiliser du S3 par exemple, restic le fait nativement.
@@ Ligne 162: / Ligne 171: @@
 Il a aussi une api rest.
-##### [Crestic](https://github.com/nils-werner/crestic)
+##### Crestic
+https://github.com/nils-werner/crestic
 Equivalent de borgmatic pour piloter restic avec des fichiers de config.
@@ Ligne 176: / Ligne 187: @@
 Permet de backuper / restorer une seule table de la base de données. Ne gère pas la rétention.
-##### [PGbackRest](https://pgbackrest.org/)
+##### PGbackRest
+https://pgbackrest.org/
 Dans toutes bases de données, il va créer des journeaux de ce qui doir ecrire (WAL dans le monde de PG).
@@ Ligne 185: / Ligne 198: @@
 Il permet aussi le chiffrement, la compression, le différentiel, et à quel niveau de rétention on veut agir. (Avant, il y avait une rétention en terme de combien de backup, mais maintenant c'est possible en temps.)
-##### [Barman](https://www.pgbarman.org/)
+##### Barman
+https://www.pgbarman.org/
 Permet le streaming de backup et de créer des cluster pg et de restorer en quelque secondes.
-##### [Wal-e](https://github.com/wal-e/wal-e)
+##### Wal-e
+https://github.com/wal-e/wal-e
 Moins de fonctionnalité que dans PGbackrest. Il y a [Wal-g](https://wal-g.readthedocs.io/) aussi comme successeur, mais plus récent / expérimental.. Bref, on a différentes variantes.
@@ Ligne 198: / Ligne 215: @@
 Il y a trois modes :
 - snapshot
 - pause
@@ Ligne 218: / Ligne 236: @@
 Cas d'une base de donnée : le mode snapshot n'est pas cohérent. Il faut le faire un mode stop pour avoir un backup cohérent. Parce que tant qu'il y a de la donnée dans la RAM, elle n'est pas inscrite sur le disque, et donc promox ne peut pas la voir et la backuper.
-Le snapshot d'une VM n'est pas un backup. Dans Promox, on a des fonctions de backup, mais l'onglet snapshot est différent. C'est autre chose. Pourquoi ? Parce que c'est sur le même disque que la VM et que
+Le snapshot d'une VM n'est pas un backup. Dans Promox, on a des fonctions de backup, mais l'onglet snapshot est différent. C'est autre chose. Pourquoi ? Parce que c'est sur le même disque que la VM et que ce n'est pas exportable.
+##### Stockage du backup
+On a deux possibilités:
+- fichiers
+- proxmox backup server
+On a pas mal de libertés pour la solution fichiers, notamment stocker le backup dans du s3 avec cloud-fuse par exemple. Ce ne sont pas des backup différentiels.
+Dans le cas du proxmox backup server (PBS), on doit installer le serveur PBS, mais cela permet de faire des backups différentiels.
+Ce qui se passe : au moment où le backup a lieu, avec bitmap ou bitstream (?), proxmox peut détecter le delta par rapport au backup précédent et n'envoyer que ça au PBS.
+Ce qui est génial : on peut lui dire qu'on veut un delta tous les jours, sur les 7 derniers jours, et au 8ème jour lui emander de merger le premier et le deuxième jour en semble. On a alors un nouveau backup full.
+PBS check les backups, donc il n'y a pas de risque d'avoir un delta corrompu.
+#### Serveur physique
+C'est un peu compliqué. On peut les considérer comme des VM mais "vu leur nombre chez Neutrinet, on les voit plutôt comme des animaux de compagnie que du bétail" (Tharyrok, 5 septembre 2021)
+En fait, c'est un vrai truc :p
+Historiquement, on avait tendance à gérer les serveurs comme des animaux de compagnie et les tuer même si c'est douloureux. Maintenant, on en a beaucoup et c'est plus facile de les mener à l'abatoir et les reconfigurer from scratch.
+Les serveurs de Neutrinet n'ont pas une config très poussée (seule la config réseau est un peu complexe), donc ça n'a pas forcément un grand intérêt de les backuper. Il y a aussi peu de chance de perdre les trois serveurs ensembles, on a donc toujours la configuration quelque part.
+### Pour la suite
+Il faudrait ensuite discuter du lieu, mais c'est compliqué de prendre la décision du lieu sans avoir les méthodes de backup... Celles-ci vont limiter le nombre de lieux...
+On aimerait bien utiliser du S3 car cela permet d'utiliser différents lieux, par ex:
+- https://www.scaleway.com/fr/c14-cold-storage/
+- https://filebase.com/
+Attention, certains storage ne coûtent rien pour envoyer de l'information, mais cher quand on doit la récupérer ! Si on met en place une solution crade qui est d'avoir un file system en s3, on va avoir beaucoup d'échanges lectures / écritures… et donc on va douiller.
+Les copains de la ffdn pour avoir de l'espace de backup.
+Pour le PBS, on a une machine chez Hetzner avec un raid5 de 5.4To, et on utilise que 3% (140Go). Mais ça va bouger quand on aura Ketupa qui se mettra en route (avec les VPS)
+### A faire
+ - Choisir l'outils pour les fichiers
+     - se renseigner sur restic et borg
+ - CHoisir pour les bases de données
+ - Definir un budget backup pour le lieu
+Faire un moment hub-infra pour
+- résumer tous les neutritons
+  - Rappel des choix techniques
+- avancement dans l'infra
+- avancement dans le réseau
+- ketupa
+## Prochaine réunion
+Prochain Neutriton : 10/10 à 14h00
+Sujet : Renforcement des réseaux
+Lieu : Jitsi et Caldarium.
+## Météo de fin
+*Moment informel durant lequel on exprime **en peu de mots** comment, à titre personnel, la réunion a été vécue que ce soit positif ou négatif.*
+*Si une ou plusieurs **tension est née** durant la réunion, il est peut-être nécessaire d'envisager l'une ou l'autre réunion pour y remédier.*
+{{tag>infra neutriton}}