Table des matières
2021/09/05 (Neutriton) : Backup
Présences :
- Celo
- HgO
- Tharyrok
Jitsi : https://jitsi.belnet.be/neutriton Caldarium : https://caldarium.be/fr:contact
Météo
Moment informel durant lequel on exprime en peu de mots comment on se sent et si on a une attente forte pour la réunion.
Ce n'est pas un moment de discussion mais d'expression individuelle et ce n'est pas obligatoire 
Attente(s) forte(s)
Si l'une ou l'autre personne exprime une attente forte, merci de vous en occuper en priorité ou de la noter dans le hub ou dans un point approprié.
Ordre du jour
Backups
3 2 1 \o/
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 → 3 lieux différents
- 2 → 2 backups différents, deux méthodes (par exemple différentiel et dump)
- 1 → 1 source.
Donc les fichiers qui utilisent une base de données sont une sources. Un dump SQL est une seconde source.
Au niveau des méthodes : si la méthode traditionnelle est corrompue, une seconde methode assure une solution si la première ne marche pas. Faire un dump base de donnée par base de donnée, c'est un backup, mais avoir ensuite un dump complet de postgresql est une seconde méthode. (Une méthode pour chaque information et une pour toutes les informations.)
3 lieux différents, c'est avoir des lieux locaux et distants bien distants, pour que si une source ou un lieu de backup est compromis, on en ait d'autres. Par ex. un disque de backup attaché aux serveurs, avoir un disque dans sa cave, ailleurs…
Question toutes nos méthodes de backup doivent-elles être dans des lieux différents ?
Au moins deux lieux différents, ça nous paraît important.
Machines virtuelles : un backup local et un backup distant… mais c'est deux méthodes différentes donc ça ne compte pas comme deux lieux différents. Si un des lieux de backup est corrompu, on perd la méthode.
On doit réfléchir à chaque fois à quel niveau on veut être, les ressources et les coûts qu'on veut y mettre. Il y a des backups qui coûtent peu en envoi… mais beaucoup pour récupérer le backup.
Chez Neutrinet, on ne pourra choisir de solutions trop coûteuses…
Question du temps durant lequel on garde les backups…
Rétention: combien de temps on garde des backups? 1 jour ? 1 semaine ? 6 mois ? Fréquence : tous les combien on fait des backups ? chaque heure ? chaque jour ? chaque semaine ?
Cela a-t-il du sens de garder 6 mois de backup, effectués toutes les heures, d'un fichier qui ne bouge pas ?
On va devoir répondre quel resilience on desire, combien de temps la restoration prend et la rentetion que l'on veux.
Il peut y avoir des situations où un backup n'est pas pertinent Par exemple une machine qu'on peut recréer from scratch depuis ansible… on gagne du temps avec un backup mais on sait qu'on peut la refaire facilement… donc il faut toujours voir le temps, les coûts, etc…, que ça prend.
Dumps vs Files
Les bases de données sont un cas un peu particulier. Il y a deux grosses méthodes pour les backuper.
Soit on éteint le serveur de base donnée et on fait un backup de tous les fichiers - c'est contraignant car il faut stopper la base de donnée mais c'est simple à restaurer. Et il y a les dumps à chaud de la base de donnée, ce qui rend plus difficile la création d'incréments.
On a d'autres outils qui peuvent faciliter.
Par ex, pour une base de données ElasticSearch c'est assez complexe à backuper à chaud. En général, les bases de données sont plus compliquées à backuper à chaud, parce qu'il faut que tout reste cohérent. Or, si de nouvelles infos sont écrites dans la base de données pendant qu'on fait le backup, notre backup ne sera plus cohérent.
Local vs Distant
Tout ce qui est accroché physiquement à un ordinateur, c'est du local. Donc, un disque dur externe branché en usb, c'est du local quand même.
On a déjà vu des gens dire qu'on a un backup distant… on peut l'emmener en le débrancherant. Non, tant que le backup peut crâmer avec le serveur, c'est du local.
Idem un disque dur sur un autre serveur dans la même armoire… c'est du local.
Distant : voir quel type de chiffrement on doit avoir..
Dès qu'on est dans un emplacement distant, la question de la confiance qu'on accorde est importante.
Pull vs Push
La question de savoir si c'est le serveur de backup qui se connecter à la machine qu'on veut backuper (pull), ou si c'est la machine qui se connecte au serveur de backup (push) est aussi importante. Ce sont deux écoles, avec de bons arguments de chaque côté… Mais les deux solutions ne sont pas toujours faisable.
Ça dépend des situations, mais en général, on va considérer que la machine à backuper est plus accessible, et donc qu'un attaquant pourrait s'y connecter et avoir le contrôle.
En mode push c'est le serveur qui contient les données qui possède les accès/clés de chiffrement. En mode pull c'est le serveur de backup qui possede les données d'accès vers les données à sauvegarder et aussi les clés de chiffrement.
En mode pull un a attaquant qui a accès au serveur c'est double peine car il peux supprimer les données sur le serveur de backup mais aussi sur le serveurs ou sont les données. En mode push un attaquant peut corrompre le serveur qui contient les donnée mais aussi les backup, une mitigation c'est de limiter l'utilisateur qui se connecte au serveur de backup uniquememnt à l'écriture.
Incrémentiel vs Full
Un backup incrementiel c'est un delta entre la précedent backup et le moment du backup et prendre que ce delta. On peux avoir un backup complet par semaine et des backup incrementiels les autre jours de la semaine. Ce qui permet de diminuer la taille des backup mais consome plus de temps lors des restoration car il faut applliquer tout les deltas.
Si il y a une corruption sur un delta est corrompu cela casse la chaine des increments. Donc c'est mieux de ne pas avoir une trop grande chaine de backup, et de refaire régulièrement un backup complet.
Les outils
Fichier
scp
Il fait de la copie de fichier et passe par ssh. C'est un peu comme rsync mais en plus simple. Il ne fait pas de delta ni de compression, en dehors de la compression ssh.
rsync
avantage : il copie les données, mais il va regarder si le fichier est déjà backupé, s'il y a des modifs, il écrase, sinon il ne fait rien, etc… Donc il faut une archive mais sans tout copier. Ca peut aller donc très vite après le premier backup.
Autre avantage : il est disponible partout.
Il permet aussi de réduire le traffic réseau en compressant les données avant de les envoyer sur la machine distante.
Inconvénient : on a 1 backup, on n'a pas d'historique. rsync ne gère pas la rétention des données.
duplicity
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.
L'outil se base sur des briques élémentaires comme rsync, rdiff, gpg, etc.
IL y a des commandes différentes pour lui dire de faire un backup full ou un incrément. Donc on lui dit quand faire quoi.
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
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.
Lorsqu'il trouve de nouveaux fichiers à backuper, il regarde si cette version-là est déjà connue. Il peut ainsi repérer si on a deux photos à différents endroits qui sont les mêmes. Il fait donc une référence vers le premier fichier et ça prend moins de place.
Il fait de la compression aussi. Il peut aussi faire en local et en distant, mais que vers une machine (push). Mais borg doit être disponible sur le client distant. (Ainsi il peuvent communiquer et savoir tous les deux quels chunks ne sont pas à backuper et ne doivent pas être envoyés.)
Comme tous les outils précédents, c'est un outil en ligne de commande. Il faut donc créer des scripts de backup.
Borg peut monter automatiquement une archive à distance à un moment donné → permet de récupérer un fichier à une date précise, donc de pouvoir backuper une version bien précise du fichier. Il parcourt le backup sans se préoccuper de savoir si c'est un full ou un incrément.
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/
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. Il a aussi la capacité de backuper avec des dumps les bases de données. Le gros avantage est qu'on peut aussi le configurer facilement depuis Ansible.
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
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.
Il a aussi une api rest.
Crestic
https://github.com/nils-werner/crestic
Equivalent de borgmatic pour piloter restic avec des fichiers de config.
Base de donnée
pg_dump
Fait un dump bête et méchant de la base de donnée. Peut le faire à chaud sans problème (les données restent cohérentes). Gère une forme de compression propre à postgres.
Permet de backuper / restorer une seule table de la base de données. Ne gère pas la rétention.
PGbackRest
Dans toutes bases de données, il va créer des journeaux de ce qui doir ecrire (WAL dans le monde de PG). En suivant ces WAL, on voit comment évolue la base de donnée. Avec ces logs, on connaît la différence, les données modifiées à un instant T.
L'idée : on plug un outils qui va relever ces logs et noter les différences de son côté. postgresql permet ensuite d'eécuter une commande lorsq'un WAL apparaît. (par exemple lancer un Crate à chaque WAL).
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
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
Moins de fonctionnalité que dans PGbackrest. Il y a Wal-g aussi comme successeur, mais plus récent / expérimental.. Bref, on a différentes variantes.
Machine virtuelle
Comment fonctionne les backup proxmox ?
Il y a trois modes :
- snapshot
- pause
- stop
Proxmox créé un disque dur temporaire pour y mettre les écritures qui auront lieu lors du backup. Une fois le backup fini, cela est mergé dans le disque dur de base de la VM. Il fait ça grâce aux primitives des backends de stockage.
Par exemple, dans le cas de CEPH, de LVM, ça s'appelle snapshot.
Le type de mode est juste la manière par laquelle la VM va faire un freeze du disque principal et entreprendre la copie sur le dd.
En mode snapshot il va parler au qemu-agent et lui demander que la VM freeze son système de fichier le temps de démarrer le backup.
En pause, proxmox met en pause la machine, elle n'est plus accessible durant le backup.
En mode stop, promox envoie un shutdown à la VM et fait le backup quand elle est arrêtée.
Le dd temporaire existe pendant tout le temps du backup.
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 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 
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:
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.