Sauvegarder ses machines avec Borg et Backupninja

Nous en avions déjà parlé, chez Sysnove nous utilisons backupninja pour nos sauvegardes. C'est à la fois l'outil le plus simple et le plus souple que nous avons avez trouvé. Backupninja se configure par module : un pour le système de fichiers, un pour PostgreSQL, un pour MySQL, etc. Chaque module est configurable par un fichier de configuration contenu dans /etc/backups.d/ et peut être géré par une interface en console : ninjahelper.

Jusqu'ici, nous utilisions le module rdiff-backup pour sauvegarder l'ensemble des fichiers des serveurs. Cet outil a de nombreux avantages, mais aussi quelques défauts :

les sauvegardes ne sont pas compressées
on ne peut pas régler finement la conservation des sauvegardes (exemple : tous les jours pendant une semaine, puis un par semaine pendant un mois, plus un par mois…)

Mais ça, c'était avant. Avant que l'on ne me parle de BorgBackup en me disant, je cite, « je pense qu'on a définitivement résolu la question des backups ».

Borg

Contrairement à rdiff-backup qui a un algorithme basé sur rsync et fonctionne par incrémentation de version en version (ce qui interdit notamment de supprimer une version intermédiaire), BorgBackup utilise une technique de déduplication de morceaux (chunks). Au lieu de travailler par fichiers, il concatène (et compresse) tout ce qu'il y a à sauvegarder, pour le stocker par morceaux de 50Mo. Sans rentrer dans les détails, les intérêts sont multiples :

C'est beaucoup plus efficace, car ces chunks évitent de stocker des millions de fichiers sur le serveur de sauvegardes. Sur ce point, rdiff-backup commençait à nous poser de vrais problèmes.
C'est compressé, donc beaucoup plus léger. Depuis la mise en place de Borg, la taille totale des sauvegardes de tous nos clients a été divisée par 4… pour le même contenu original et la même rétention !
Ça ne tient plus du tout compte des noms de fichiers. On peut par exemple renommer un gros fichier, il ne sera pas re-sauvegardé (car Borg détectera les morceaux similaires).
On peut faire de la déduplication sur plusieurs serveurs. On ne le fait pas, mais c'est possible.

Et cerise sur le gâteau, la documentation est limpide, et c'est trivial à utiliser :

borg init user@hostname:backup # Initialiser le dépôt
borg create --compression lz4 user@hostname:backup::2016-05-17 ~ # Faire un backup
borg create --compression lz4 user@hostname:backup::2016-05-18 ~ # Faire un autre backup

Quant à la restauration, je ne pense pas qu'il soit possible de faire plus simple. Vous pouvez monter n'importe quel backup dans un répertoire.

borg mount user@hostname:backup::2016-05-17 /mnt

Et à partir de ça, utilisez les outils que vous voulez pour restaurer, ou simplement consulter la sauvegarde.

Intégration à Backupninja

Pour ajouter ce nouveau module, il suffit de placer le fichier borg dans le répertoire /usr/share/backupninja/. Pour compléter, vous pouvez aussi placer le fichier example.borg dans /usr/share/doc/backupninja/examples/. Cette fois, je n'ai malheureusement pas pris le temps de faire un helper pour configurer le backup via ninjahelper.

Une fois le module en place, copiez example.borg dans /etc/backup.d/90.borg, adaptez la configuration, et testez avec backupninja -n ou avec ninjahelper.

Ansible

Si, comme nous, vous gérez beaucoup de serveurs, la question du déploiement automatisé va finir par se poser. Typiquement, il va falloir s'assurer que les clés des serveurs sauvegardés soient bien déployées sur le serveur de sauvegardes pour que la connexion SSH de borg fonctionne, et en profiter pour forcer la commande borg serve coté serveur, afin de sécuriser les sauvegardes de tous les clients. Voici un extrait simplifié de nos playbooks Ansible.

Conclusion

Nous utilisons ce nouveau système depuis maintenant deux mois.

Grâce à la compression, les sauvegardes prennent en moyenne 4 fois moins de place. Sur plusieurs To c'est un gain énorme.
Les sauvegardes se font de manière beaucoup plus fluide. On ne voit plus de problème de charge liée aux IO sur notre serveur de sauvegardes. C'est à la fois dû à la compression et au fait qu'elles sont stockées par chunks.
Le mécanisme de restauration est simple et maitrisé. Il permet même de consulter n'importe quelle sauvegarde sans avoir à la restaurer.
Les sauvegardes sont cloisonnées et sécurisées. Si besoin, chaque client peut aisément les utiliser sans risque.
La supervision des sauvegardes est beaucoup plus simple. Il suffit de vérifier qu'une sauvegarde existe au nom de la date du jour. On a même un script Nagios pour ça : check_borg_backup.sh.

On ne peut que confirmer : avec BorgBackup on a définitivement résolu la question des backups.

À propos de l'auteur

Guillaume est l'un des deux fondateurs et cogérants de Sysnove. Développeur Python et administrateur système passionné de logiciel libre et des technologies liées à Internet, il participe à divers projets, notamment le fournisseur d'accès Internet Aquilenet ainsi que la Fédération FDN.

Chez Sysnove, son rôle consiste à mettre en place et administrer les infrastructures nécessaires à l'hébergement des services fournis aux clients. En tant que directeur général, il gère aussi les aspects administratifs de l'entreprise.