Table des matières
Bonjour à tous,
Ce mois de septembre fut très chargé pour moi ! Je n’ai donc pas eu le temps de m’attarder longuement sur un sujet pour en faire un article dédié. Mais c’est l’occasion pour moi de sortir le 3ème article de la série Pêle-mêle.
Aujourd’hui, on va parler de sauvegardes ainsi que de mes besoins spécifiques qui me poussent à développer un plugin pour Traefik.
Sauvegardes
Contexte
Mon serveur distant est sauvegardé par un script toutes les 12 heures.
Les fichiers sont copiés sur un disque dur dans mon appartement à l’aide du logiciel rsync puis sont archivés avec Borg.
Chaque dimanche, le script effectue également la commande borg prune
de façon à garder les archives selon cette configuration:
- Toutes les archives réalisées dans les 48 dernières heures.
- 1 archive par jour sur les 7 derniers jours.
- 1 archive par semaine sur les 4 dernières semaines.
- 1 archive par mois ad vitam æternam.
Cela me permet d’avoir une grande latitude si j’ai besoin de restaurer des données à une date spécifique tout faisant régulièrement le tri pour économiser de la place sur le disque.
Point positif, Borg évite la duplication entre archives. Par exemple si au mois de janvier, j’ai un fichier de 2Go et qu’il reste intouché pendant toute l’année, à la fin, j’aurai 12 archives, mais le total occupé sur le disque pour ce fichier sera de 2Go.
Les données sauvegardées
Tout d’abord, le script (bash) qui réalise les sauvegardes commence à vraiment dater.
À l’époque, tous les services présents sur le serveur étaient installés à la main et bichonnés à l’ancienne.
Au moment de sauvegarder, je sélectionnais donc la racine du serveur à laquelle j’excluais quelques dossiers comme /var/log
, /run
ou /tmp
mais quand j’avais écrit le script, j’avais commenté le tout avec un TODO qui recommandait de mieux choisir les dossiers.
Force est de constater que l’heure est venue de traiter ce TODO !
Bref, je me suis retrouvé par exemple à sauvegarder et archiver /var/lib
sur plusieurs années.
Le souci est qu’il ne restait plus que 500Go sur les 3To du disque de sauvegarde, j’ai donc investigué et c’est là que je suis (re)tombé là-dessus.
J’ai donc rapidement trouvé la commande borg recreate
(documentation présente ici).
Il faut cependant faire attention à la version de borg, dans mon cas, je suis en 1.1.16 (avec un borg --version
) et il n’est pas nécessaire de faire la commande borg compact
citée dans la documentation la plus récente.
Avec cette commande, j’ai pu gagner déjà une trentaine de Go en repassant sur toutes les archives pour supprimer tout ce qui ne nécessite pas un archivage.
Coupure internet
Sauvegarder son serveur distant à domicile nécessite à priori 2 choses: électricité et internet. Eh bien il se trouve que j’ai eu une coupure internet alors que j’étais en plein télétravail vers 14h15 un mardi. Dans la foulée, je réalise alors des tests sur le site d’Orange (je suis chez Sosh), le résultat est le suivant: il faut patienter ou prendre rendez-vous avec un technicien. Je décide de prendre mon mal en patience et je relance le test une petite heure après, puis en début de soirée. Les tests ont tous deux ressorti les mêmes conclusions.
En fin de soirée, après discussion avec mes voisins, je suis le seul de l’immeuble sans internet, je décide de relancer le test (la prise de rendez-vous ne se fait qu’en fin de test). Et au moment où je clique sur le bouton pour lancer le test, SURPRISE, un message m’indique qu’on est limité à 3 tests par jour … Au réveil, je relance enfin le test qui me permet de prendre rendez-vous pour le lendemain (plage horaire entre 8h et 13h, heureusement que je peux faire du télétravail …).
Le mercredi soir (la veille du rendez-vous pour l’intervention), je me dis que ça fait déjà un bout de temps que je n’ai pas pu réaliser de sauvegardes. Le Raspberry Pi responsable des sauvegardes est branché à la box en Ethernet, j’ai un peu la flemme de lui configurer le Wifi du partage de connexion de mon téléphone. Ma Tour (mon PC principal) est sous Windows (pour pouvoir jouer, c’est le meilleur compromis …), et même avec WSL, je n’ai pas confiance pour utiliser LUKS pour déchiffrer le disque.
Bref, je sors mon vieux portable 10 pouces sous Debian (il faut toujours un PC sous Linux, quoi qu’il en soit …). Je le connecte au Wifi du partage de connexion de mon téléphone et tente de me connecter au serveur, pas de bol la clé SSH du PC n’est pas autorisée par le serveur … Je me connecte alors au serveur via une application SSH sur mon téléphone pour ajouter la clé de mon PC. Ensuite, je peux brancher le disque dur pour lancer le rsync (donc sur ma 4G), et à ce moment-là, je n’ai que 15 minutes avant de devoir partir à un concert (il y a pire comme contrainte, c’est sûr :)). Au moment où je m’apprête à interrompre le rsync, il rend la main comme par magie, la copie est terminée sans erreur ! Parfait ! :)
Pour finir, le jeudi matin, l’intervention aura pris une petite vingtaine de minutes le temps de faire les branchements à l’appartement, descendre jusqu’au boitier fibre, changer le câble, et remonter tester. C’était pour changer, un problème lié à une intervention précédente d’un autre technicien … (la première fois que ça m’arrive cela dit).
Petite morale de l’histoire:
- Oui, en cas de coupure internet, je peux tout de même faire des sauvegardes à l’aide de ma 4G (sans en abuser, ce n’est pas illimité …)
- Non, en cas de coupure internet, je ne suis pas capable de restaurer tous mes services en cas de pépin sur le serveur (disque qui lâcherait ou autre). Mon site ne pèse que quelques dizaines de Mo (les images) donc c’est bon, idem pour la base de données du gestionnaire de mots de passe (moins de 1Mo), mais Nextcloud pèse presque 200Go donc impossible sur la 4G évidemment.
Ce problème de coupure internet serait encore pire en cas de coupure électrique, car celle-ci entrainerait également une coupure internet …
Développement d’un plugin pour Traefik
Sur mon serveur, je reçois toujours pas mal de requêtes de robots pour s’authentifier sur des chemins connus tels que /wp-admin
de Wordpress.
Mon site n’est pas un Wordpress donc les robots tombent sur une erreur 404 puis ils essaient sur quelqu’un d’autre.
Il y a quelques années, j’aurai pu mettre en place une zip bomb. C’est un fichier qui pèse quelques Ko ou Mo réels sur le serveur, mais qui, une fois téléchargé, peut monter à plusieurs To. Par exemple, cette bombe permet de passer de 10 Mo à 281 To.
Mais en 2021, d’un point de vue écologique, ça me paraît bien ridicule, je vais donc mettre en place des règles dans Traefik pour qu’ils tombent directement sur une erreur 403 sans même avoir à charger le CSS et tout le tralala, ils seront alors éjectés au plus tôt en consommant le moins possible de bande passante.
Pour les curieux, avec Traefik c’est tout simple, il suffit d’utiliser ce plugin (miroir ici) qui permet de bloquer des chemins à l’aide d’expressions régulières.
Dans le cas d’un vrai site Wordpress (et j’en héberge), j’aimerais que ces requêtes soient bloquées de la même façon sauf si elles viennent de chez moi.
Je n’ai pas trouvé de fonctionnalité de base ou de plugin pour faire ce genre de choses, j’ai donc commencé le développement d’un plugin dont je vous partagerai le résultat une fois que j’aurai trouvé du temps pour y bosser dessus.
Conclusion
J’espère que ce petit article vous aura plu et intéressé, je n’ai pas trop le temps en ce moment de faire des gros articles comme j’aime bien le faire … Mais j’apprécie quand même ces articles pour vous partager quelques petites geekeries que je traverse !
D’ailleurs, loin de moi l’idée de faire du teasing, mais après presque un an et demi d’absence, une recette va enfin bientôt apparaitre sur mon site de cuisine (qui tourne sur Wordpress d’ailleurs) (et la recette sera une croûte aux champignons, je dis ça, je dis rien !).