Jusqu'ici, il n'y avait aucune sauvegarde automatisée mise en place sur le serveur. Mais cela vient de changer. Avant, si l'appartemment de Pantin (lieu où est installé le serveur) subissait des dommages, il y avait un risque pour que le serveur soit détruit, et les préçieux fichiers des utilisateurs avec. Ou simplement lors d'une panne de SSD... Heureusement, Notre cher ADMINSYS à eu la bonne idée de mettre en place un protocole de sauvegarde.

Redondance

La base de la sauvegarde est la redondance des données, c.a.d. le fait que les données soient dupliqués sur deux supports. De cette façon, lorsque l'un ne fonctionne plus, il reste toujours l'autre. Ouf...

Mais encore faut il que les deux supports ne soient pas détruits en même temps. S'ils sont stockés au même endroit et que, par exemple, un incendie se déclenche, alors ce n'était pas la peine d'avoir dupliqué les supports...

C'est pourquoi il est astucieux d'utiliser une sauvegarde externalisée, c.a.d. qui duplique les données loin du lieu où se trouve le premier support.
La question qui se pose alors est la suivante : où mettre ce deuxième support ?

Plutôt que de construire un deuxième serveur uniquement dans ce but, qui ne se réveillerait qu'une fois par semaine, la nuit venue, pour acceuillir la sauvegarde hebdomadaire, on a voulu ré-utiliser un serveur déjà existant, qui voudrait bien accueillir nos sauvegardes. Encore un cas où les amitiés dans la vrai vie peuvent améliorer la sécurité informatique : En demandant gentillement, c'est un certain Sylvain qui a accepté de stocker nos sauvegardes sur son home-serveur parisien. Merci à lui !

Petite explication plus technique

Le logiciel a été choisi selon un cahier des charges assez précis. Il fallait en effet que tout soit automatisé et facile à configurer en CLI, que les sauvegardes soient incrémentales et dédupliquées et qu'il soit possible de répartir les sauvegardes sur plusieurs serveurs. En plus de ça il fallait que les bases de données (MySql et PostgreSql) soient sauvegardées de manière intelligente (c'est-à-dire via un dump et non une copie des fichiers binaire). Evidemment toutes ces exigeances n'étaient pas aisement satisfaites par un seul logiciel.

C'est le conseil d'un ami, Julien, qui nous a orienté vers la bonne piste. Il nous a suggéré l'utilisation du logiciel Borg. Celui-ci remplissait à lui seul une grande partie de notre cahier des charges, à savoir fournir des sauvegardes incrémentales, dédupliquées et réparties sur plusieurs serveurs en plus d'être doté d'une CLI très complète. De plus les sauvegardes sont chiffrées. Ce détail n'avait pas été pris en compte dans un premier temps mais il s'est avéré nécessaire pour les sauvegardes distantes en raison de la sensibilité des données qu'elles contiennent. Son seul point faible étant de ne pas gérer l'automatisation des sauvegardes, il fallait donc réaliser le script de sauvegarde soi-même. Cette manière de faire a l'avantage d'offrir plus de flexibilité mais elle est aussi plus délicate à mettre en place et, bien que le script ne soit pas si compliqué à écrire et que Borg fournisse toutes les commandes necessaire, un bug dans ce dernier entrênerait une perte de données conséquente en cas de panne.

Nous ne sommes evidemment pas les premiers à être confrontés à ce problème, c'est pourquoi certains ont eu la bonne idée de créer une surcouche d'automatisation pour Borg, intelligeament nommée Borgmatic. Celle-ci permet de gérer avec aisance plusieurs repos borg à l'aide de fichiers de configuration. Il suffit de créer un fichier par repo dans lequel l'ensemble des paramètres de la sauvegarde sont configurables, comme par exemple le nombre de sauvegardes quotidiennes, hebdomadaires et mensuelles conserver, les adresses des repos distants et, cerise sur le gâteau, les bases de données SQL à inclure dans la sauvegarde.

Ces deux logiciels étant bien-sûr tous deux inclus dans les dépots Debian, on préférera leur installation via apt plutôt que via pip comme suggéré dans leurs docs. La suite se résume à configurer Borgmatic selon les préférences de chacun.

Enfin, Borgmatic fournit une fonctionnalité supplémentaire qui n'était pas prévue dans le cahier des charges initial mais qui s'est également révélée être primordiale pour la fiabilité du système : sa capacité de branchement avec des systèmes d'alertes tiers. Nous avons donc mis en places des alertes à l'aide d'https://healthchecks.io, un excellent service open-source pour vérifier la santé de taches CRON avec lequel Bormatic s'intègre parfaitement. Le statut de nos sauvegardes peut ainsi facilement être vérifié à tout moment grâce au badge d'état des sauvegardes. De plus, healthchecks est capable d'envoyer des notifications via Matrix — le système de messagerie instantanné qu'on utilise chez CLUB1 — ce qui nous permet de recevoir les alertes immédiatement.