Wiki de FedeRez

FedeRez est une asso étudiante, dans laquelle, comme pour la plupart des assos de réseau étudiantes (si ce n'est plus), les ressources humaines peuvent fluctuer considérablement au cours du temps, parfois avec pas ou peu de passations de savoir.

Les infrastructures et services que nous mettons en place doivent donc chercher à être aussi robustes que possible.

Mais pas robustes au sens haute disponibilité, failover, etc ; plutôt au sens de disaster recovery.

Ce qu'on veut, ce n'est pas une infra qui ne tombe jamais, c'est une infra qu'on a les capacités de réparer quand elle tombe.

Ça implique plusieurs choses :

* KISS
* Bonne documentation
* Backups solides

Le choix de Borg + ansible me semble un bon compromis à ce niveau : pas de spof, pas de système compliqué de clustering, une seule techno assez simple d'utilisation partout, versatilité importante (se balader dans un backup en fuse, etc…)

Aucune objection à en plus mettre d'autres types de backups tels que des snapshots de vm, c'est incontestablement plus simple d'utilisation dans les cas où c'est applicable, etc. Mais c'est plus limité en scope (proxmox vs hosting chez un tiers) et en résilience (c'est plus la même version de xxxx du coup le snapshot est plus compatible, ah mais on peut pas la restaurer là parce que pas la bonne conf réseau, etc)

BorgBackup (ou Borg) sert à effectuer la sauvegarde proprement dite vers les serveurs de destination. Il gère un historique des versions des sauvegardes ainsi que la déduplication et la compression des données. Son installation et sa configuration sont gérés via ansible.

Backupninja sert pour les sauvegardes automatisées locales (/var/backups) :

• des informations systèmes utiles (dpkg-selections, fstab, lvm…)
• des dumps des bases de données MySQL

Backupninja est installé et configuré manuellement là où il est utilisé.

Actuellement, 2 serveurs sont destination des sauvegardes réalisées par Borg :

• memoragon (LXC non privilégié sur ronderu)
• coronagon (KVM hébergé au Résel)

Cette opération n'est normalement pas requise, un cron s'en charge.
On peut néanmoins lancer manuellement un backup en exécutant le script `/etc/borg/system.sh` sur le système que l'on veut sauvegarder.

La configuration a lieu dans le repo ansible.

La plupart des hôtes utilisent la configuration commune, définie dans inventory/group_vars/all/vars.yml, mais il est possible de surcharger cette configuration par hôte ou par machine dans inventory/group_vars ou dans inventory/host_vars.

Redéployer le playbook après changement.

TODO

Les commandes suivantes peuvent indifféremment être effectuées sur :

* La machine dont on cherche à manipuler les backups
* Un des serveurs de backup

Commencer par configurer les variables d'environnement suivantes :

export BORG_RSH="ssh -i /root/.ssh/id_ed25519-backup"
export BORG_PASSPHRASE="COMMON_SECRET_TO_REPLACE" # Présent dans le repo ansible ou dans /etc/borg/system.sh sur les systèmes backupés
export REPOSITORY="borgbackup@memoragon.federez.net:system" # Remplacer memoragon si vous voulez accéder aux backups stockés sur coronagon

Il est notamment possible de :

* lister les backups
* Faire une archive tar à partir d'un backup
* Monter l'archive localement via fuse et lire son contenu avec n'importe quel outil

Se référer à la documentation de borg pour les syntaxes exactes.

Backupninja sert à créer des backups des informations système ainsi que de la base de donnée MySQL automatiquement.

Pour info, les backups créés par backupninja sont stockés dans /var/backups. Ce dossier est inclus dans la sauvegarde d'obnam ce qui permet d'externaliser les backups effectués par backupninja.

apt-get install hwinfo debconf-utils backupninja

Désactiver l'envoi de mails en cas de succès : dans /etc/backupninja.conf mettre/changer reportsuccess = no.

Activer les backups des infos systèmes ( mettre lvm = no pour les systèmes sans LVM comme quigon)

Ajouter le fichier /etc/backup.d/10.sys

Activer les backups pour la base de donnée MySQL ( uniquement sur hexagon)

Ajouter le fichier /etc/backup.d/20.mysql

Tester avec

sudo backupninja -t -n

Aucune mise en place initiale n'est requise.

Le rôle ansible déployant la configuration est capable d'installer intégralement un serveur de backup, seul un accès ssh est requis.