Borg est-il prêt pour faire des sauvegardes de la production ? En un mot, je répondrai oui. En plus détaillé, il y aura le présent billet de blog. Les personnes voulant plusieurs retours d'expériences et sachant lire l'anglais pourront se tourner vers de post Reddit Reddit - Is Borg backup suitable for the production ?
Le contexte
Borg est utilisable et utilisé en production par différentes personnes avec qui j'ai discuté. Dans mon cas, je l'utilise pour sauvegarder des fichiers de serveurs Linux (fichiers plats et binaires), et des dumps de base de données.
Quelques liens
La page la plus complète que l'on peut trouver en français sur le sujet de Borg est celle du wiki de Sebsauvage
Lors des JRES, Framasky, l'administrateur système qui gère les machines de Framasoft qui permettent au projet Degooglisons d'exister avait une conférence Quelle infrastructure pour dégoogliser Internet - JRES 2017 dans laquelle il parle, entre, des outils de sauvegarde et évoque Borg.
Une autre conférence est celle donnée par Maurice LIBES, Didier MALLARINO, Sauvegardes en mode dédupliquée avec Borg-Backup : retour d'expérience, le titre parle de lui-même.
Autre lien, en anglais sur les Sauvegardes de bases de données, Create daily database backups with Borg
Enfin, ayant créé des alias pour mes sauvegardes personnelles que je fais aussi avec Borg, suite au partage d'expérience de Djan Gicquel, je mets le lien vers son article Alias et fonctions pour Borgbackup (Djan Gicquel avait lui-même adopté Borg suite à mon article de présentation, la boucle est bouclée).
Un espace dédié par serveur
Borg permet de la déduplication et si un même fichier est présent sur plusieurs serveurs, il peut être tentant (utile) de profiter de cette déduplication en sauvegardant ces différents serveurs dans un même espace. Le fichier ne sera sauvegardé d'une fois, commun aux sauvegardes des différents serveurs et conservé tant qu'une sauvegarde de l'un des serveurs y fera référence.
Par contre, dans le cas d'un répo unique, il s'avère que
if you back them up into a single repo, you will have to frequently resync the chunks cache on each server and also you can't do backups in parallel to same repo.
ce que l'on peut traduire par le fait qu'il faudra régulièrement lancer la commande de resynchronisation du cache sur chaque serveur qui fait ses sauvegardes via Borg et il n'est pas possible de sauvegarder plusieurs serveurs en même temps sur le même répo.
Pour ne pas avoir ces contraintes j'ai donc fait le choix de faire une stratégie de sauvegarde avec un espace dédié par serveur (et avec des sous-répertoires pour avoir différents repo Borg pour les différents types de données des serveurs).
Sens des sauvegardes : Push vs Pull
Push Borg marche très bien vers SSH. Mais cela nécessite d'installer Borg sur chaque machine client pour envoyer les données à sauvegarder sur un espace de fichier sur un serveur dédié. A ce sujet, voir le billet de blog de Karolak sur monter un serveur de sauvegarde avec Borgbackup
Pull C'est la machine de stockage qui lance Borg et centralise les tâches Cron de sauvegarde. Il faut monter l'espace distant à sauvegarder via SSHFS et alors faire la sauvegarde.
Le choix de l'un ou de l'autre dépend de plusieurs choses dont un aspet sécuritaire.
Dans le cas du Push, chacune des machines à un accès SSH sur le serveur de Sauvegarde. La compromission de la machine sauvegardée permet par rebond d'accéder à la machine de sauvegarde. Dans le cas du Pull, le serveur de sauvegarde a lui accès à toutes les machines et la compromission de ce dernier permet par rebond d'accéder à toutes les machines sauvegardées...
Dans le cas du Push, le client ne peut avoir accès qu'en "append" sur le serveur de backup et le serveur de backup n'a pas accès sur la machine client.
Quelques remarques
Prenons le cas de la sauvegarde d'un site web que l'on sauvegarde avec Borg. La déduplication marche quand les fichiers restent inchangés. Pour les dumps de la base de données, si il y a eu le moindre changement dans la base, le dump est différent et il sera vu comme un nouveau fichier. On profitera toutefois de la compression de Borg permettant un gain de place pour la sauvegarde et du fait que Borg découpe le fichier en chunk, et que les parties communes du fichier dump ne seront pas dédupliquées.
Les limites
On ne peut sauvegarder que des fichiers statiques. Même si Borg est rapide, une sauvegarde avec Borg prend un certain temps et le fichier ne doit pas avoir été modifié durant le laps de temps que dure la sauvegarde, sinon cela peut rendre la sauvegarde de ce dernier inconsistante.
Il n'y a pour l'instant pas d'interface graphique pour la gestion des sauvegardes, même si un projet Borg Web a été initié et repris par une start-up (ce sera le sujet d'un autre billet de blog. J'ai testé le projet en développement BorgWeb sans réussir à le faire fonctionner).
Améliorations à prévoir
Dans les améliorations que je prévois dans mon usage de Borg, il y a celui d'utiliser Borgomatic pour la création des configuration de sauvegardes. Car actuellement, je passe par la copie d'un script de référence contenant les lignes de sauvegarde et de conservation (option prune) que j'adapte au cas par cas...
Il existe des scripts pour Nagios et pour Zabbix qui vérifie la présence des sauvegardes et alertes si celle-ci sont manquantes. Je n'ai pas encore utilisé le plugin Zabbix (https://github.com/theranger/zabbix-borg) et c'est prévu
De même Borg peut s'interfacer avec l'outil BackupNinja. Là encore, c'est dans ma todo d'étudier ça.
on a 4 exemplaires de la donnée : la donné initiale (1), la donnée dans l'archive .tar.gz (2), la donnée copiée sur le serveur via rsync (3) et la donnée dans la sauvegarde borg (4).
