Petite présentation rapide d'un outil de sauvegarde très peu connu, et pourtant très KISS dans son approche et dans sa configuration !

Katarina est un outil de sauvegarde développé en Perl par Cyril Bellot, disponible sur Sourceforge via ce lien. Il s'appuie sur rsyncd, ce qui implique quelques limitations par défaut (mais nous y reviendrons), et travaille donc en "pull" et en "mode fichiers". Si vous ne savez pas en quoi cela consiste, je vous renvoie en préambule à mon article sur la mise en place d'une stratégie de sauvegarde.

Disclaimer 1 : attention, Katarina n'est pas tout jeune, et n'inclut pas un certain nombre de fonctionnalités qu'on attend d'un logiciel de sauvegarde "récent", à savoir par exemple le chiffrement des données sauvegardées. Son rôle est de faire une sauvegarde simple et rapide d'un parc de machines, avec une configuration légère, et il sait plutôt bien passer à l'échelle. Ceci dit, encore une fois pour les besoins d'une entreprise, de nos jours, il ne sera pas forcément le meilleur candidat, même s'il est tout à fait possible de l'améliorer !

Disclaimer 2 : Katarina se basant sur rsyncd, il est compatible avec (je suppose) la totalité des distributions Unix/Linux existantes. Pour Windows, on peut bidouiller quelque chose avec Cygwin (validé en production), mais ça reste limité et ne permettra de restaurer que des fichiers, pas le système.

Architecture

Comme évoqué en introduction, Katarina est développé en Perl, ce qui implique qu'il peut être déployé sur à peu près n'importe quelle distribution Linux (j'ai eu l'occasion de le valider sur Debian 8, 9 et 10, en environnement professionnel et personnel). Aucune base de données n'est nécessaire.

Son principe de fonctionnement est le suivant :

• Un répertoire contient les fichiers de définition (ou profils) de tous les jeux de sauvegarde à effectuer ;
• Un répertoire (ou volume ZFS, nous y reviendrons) est dédié à chacun de ces jeux de sauvegarde ;
• Un ordonnanceur (appelé par un simple cron) va aller lire les fichiers de configuration, préparer les sauvegardes à exécuter, puis les dérouler à l'aide de son script de sauvegarde (en respectant le parallélisme souhaité).

Au final, nous avons, côté serveur :

• Un répertoire /mnt/whatever pour les sauvegardes ;
• Un répertoire /etc/katarina pour les profils ;
• Un répertoire /opt/katarina pour les scripts ;
• Un répertoire /var/logs/katarina pour les logs (qui font l'objet d'une section dédiée dans cet article) ;
• Un fichier /etc/cron.d/katarina.

Et côté client, nous aurons :

• Le package rsyncd d'installé ;
• Un fichier /etc/katarina/rsyncd.conf

Inutile de vous dire que le déploiement de tout ça s'automatise très facilement :)

Configuration

Les profils

Katarina va donc se baser sur des "profils" de sauvegarde pour travailler. Ces profils peuvent être organisés à votre convenance : par client, par projet, par machine...

Dans un profil, on trouvera :

• La liste des machines à sauvegarder ;
• Le répertoire de destination ;
• Les répertoires à exclure ;
• Les différentes rétentions (exprimées en secondes (oui oui :D)) ;
• Et d'autres options que vous pouvez consulter directement dans cet exemple :

Ces profils seront analysés par Katarina à son lancement, et lui serviront à générer les commandes rsync qui vont aller récupérer vos données.

Le scheduler

Une fois que nous avons un ou plusieurs profils, nous allons les ajouter au "scheduler" : une simple liste des profils à exécuter, qui sera là aussi capable de paralléliser plusieurs jobs (nous y reviendrons).

Puis nous irons rajouter le cron qui va bien pour lancer ce scheduler :

Note : à ce jour, le scheduleur par défaut traite uniquement les jobs "daily" des profils (soit l'immense majorité, car à partir du moment où vous parlez de sauvegardes mensuelles ou au-delà, on peut légitimement s'orienter vers de l'archivage). Pour les autres types de profils (j'y reviens après), vous devrez ajouter les entrées correspondantes directement dans votre cron (voir exemple ci-dessus), ou adapter le scheduleur existant pour en faire un compatible avec vos besoins.

Planification et rétention

Dans le fichier de profil, vous aurez donc identifié la section "cycles". Celle-ci va permettre de définir à la fois notre politique de planification (sauvegardes journalières, hebodmadaires, bi-annuelles...) et leur rétention. Notez que les rétentions sont exprimées en secondes (86400 secondes dans une journée), c'est pourquoi on préfèrera les exprimer en multiples de 86400.

Pour une rétention de 1 mois, par exemple, les notations suivantes sont donc équivalentes (définissez juste votre propre logique) :

Le "cycle" en lui-même est une notion un peu plus abstraite, dans le sens où, bien que définit dans ce fichier, il sera surtout lié aux crons qui vont l'exploiter. Je m'explique :

Vous pensez peut-être que ce mécanisme est saugrenu, voire trompeur, et pourtant c'est très pratique : vous n'êtes plus limité aux traditionnels journaliers/hebdomadaires/mensuels ! Vous pouvez définir les cycles qui vous intéressent, en fonction de vos contraintes métiers ou de vos clients, et simplement définir le cron qui va bien (par exemple, une sauvegarde "yolo" qui est lancée tous les mardis de chaque mois impair (avec une rétention de 200 ans, soyons yolo jusqu'au bout). Bien entendu, 99% de vos cycles seront des "daily", "weekly", etc, mais encore une fois vous être totalement libres de les appeler comme bon vous semble : définissez juste votre propre logique, et tenez-là.

Concernant la rotation des sauvegardes, si vous avez bien suivi vous aurez donc noté qu'on utilise du rsync, et qui dit rsync dit sauvegardes incrémentales. Mais, parce qu'il y a un mais, pas tout à fait, et c'est là que le paramètre "method" des "cycles" va prendre tout son sens. Prenons un exemple :

Soit la configuration par défaut suivante :

Tous les jours, lorsque mon scheduler appelle ce profil, on fait un rsync et on ne copie donc que la différence depuis la veille. Basique.

Maintenant, on ajoute une sauvegarde hebdomadaire :

Ici, toutes les semaines, quand j'appelle ce profil, je fais un rsync depuis la dernière sauvegarde hebdomadaire. On a donc nos journalières basées chacune sur la précédente, et idem pour les hebdomadaires.

Maintenant, imaginons que ces hebdomadaires soient beaucoup trop longues, ou qu'on décide de faire pleinement confiance à rsync :

Ici, chaque weekly se basera sur la dernière daily effectuée (qu'on effectuera juste avant, pour être synchro), ce qui économisera pas mal de temps et de ressources !

Côté client

Bien, notre serveur est prêt, passons au client. On installe rsyncd, et on copie un fichier de configuration de la forme suivante (qui devra bien entendu être chargé avec un redémarrage du service rsyncd) :

Ici, on fait simple :

• rsyncd est à l'écoute et n'autorise que les IP de vos serveurs de backup ;
• une connexion légitime donnera accès aux répertoires autorisés, en lecture seulement, et avec les droits nécessaires.

Vous noterez au passage que cette transaction n'est pas très sécurisée : pas d'authentification, et les flux rsync passeront en clair sur votre réseau. Cette méthode n'est donc à utiliser que sur un réseau que vous maîtrisez parfaitement (il existe des méthodes pour améliorer un peu tout ça, nous verrons ça plus tard).

Faire une sauvegarde

Nous avons un profil, nous avons des clients configurés, nous avons un répertoire pour déposer nos sauvegardes : sauvegardons !

Non, attendez, il manque une étape : il faut d'abord qu'on vérifie que notre configuration est bonne.

Voilà, là on a vérifié que le profil est bon, que le répertoire de destination est bon, et que tous les clients répondent correctement (ou pas, à vous de diagnostiquer éventuellement vos flux réseaux).

Maintenant, on peut sauvegarder :

Et voilà, c'est tout.

Bien entendu, si vous lancez une sauvegarde manuellement comme dans l'exemple ci-dessus (pour des tests ou pour relancer un jeu tombé en erreur, en mode "retry" au lieu de "backup"), pensez à le faire dans un screen ou un tmux ; si c'est le scheduler qui s'en occupe, vous n'avez rien à faire.

Restaurer une sauvegarde

Allez, on va vite : pour restaurer, vous naviguez dans votre arborescence pour trouver le profil, puis la machine, puis le jeu de sauvegarde, puis le répertoire/fichier qui vous intéresse, et vous le copiez/synchronisez à l'envers vers votre machine cliente.

C'est là l'un des côtés pratiques de Katarina : pas de volumes à explorer avec des outils spécifiques, pas de bases de données à consulter pour récupérer l'index d'une sauvegarde, juste une arborescence à plat, bien rangée. Encore une fois, pour des besoins de sécurité 2019-compliant, on fait largement mieux, mais ça reste d'une simplicité et d'une rapidité déconcertante pour restaurer en quelques secondes le site web qui vient de flancher en production.

Analyser les logs

Admettons, pour les besoins de la Science™, qu'une sauvegarde se soit mal déroulée (problèmes réseaux, électriques, systèmes...) : Katarina saura vous donnez des logs. Beaucoup de logs.

Dans le répertoire qui va bien (pour rappel, /var/log/katarina), vous trouverez plusieurs fichiers intéressants :

• Tout d'abord, le <votre_profil>.<votre_cycle>.report, qui vous donnera le dernier rapport de sauvegarde, également envoyé par mail (voir plus haut, j'ai déjà donné un exemple) ;
• Ensuite, le <votre_profil>.<votre_cycle>.debug, qui vous détaillera tout le déroulement de la dernière tentative ;
• Et enfin, le répertoire ./srv, qui contiendra la sortie complète de tous les rsync correspondants, pour pouvoir éventuellement tracer le fichier précis qui aura coincé (et ça m'a servi plus d'une fois !).

Vous aurez également la possibilité d'avoir un petit aperçu rapide de vos différents jeux :

"copy" vs "snap"

Je ne sais pas si vous vous en souvenez, mais le terme "ZFS" a fait une furtive apparition au début de cet article, et figurez-vous que Katarina peut également s'en servir comme backend de stockage !

En mode "copy" (par défaut), la rotation des fichiers se fait via des cp et des hardlinks. C'est propre, fonctionnel, suffisant, mais on peut faire mieux : utiliser les snapshots ZFS (d'où le mode "snap", si vous suivez). On aura toujours une rotation en mode "cp", mais chacune se retrouvera figée dans un snapshot, ce qui permettra de l'isoler et d'apporter une petite sécurité supplémentaire (éviter un effacement accidentel, notamment). Katarina se chargera de purger les anciens snapshots au fil du temps, il n'y a donc pas grand chose de plus à faire. En bonus, ça permet aussi de transférer les sauvegardes (ou de les répliquer) sur d'autres machines très facilement avec du ZFS send/receive, de façon incrémentale grâce à ces snapshots.

Note : à l'usage, pour avoir géré plusieurs milliers de machines clientes avec Katarina (pro et perso), le mode "snap" n'est finalement pas le plus pratique, pour plusieurs raisons :

• si vous avez omis une exclusion dans l'un de vos profils, et que vous avez donc sauvegardé en trop certains répertoires pendant plusieurs jours d'affilé (le stockage, ça coûte cher), vous ne pourrez pas aller faire de ménage sur le serveur de backup, vu que ces répertoires sont figés dans les snapshots des jours précédents : vous pourrez les supprimer du dataset courant, mais devrez attendre la fin de la rétention de votre profil pour que Katarina ait supprimé tous les snapshots antérieurs, et que ZFS purge donc les-dites données ;
• de la même façon, si vous souhaitez supprimer une machine d'un profil, vous pouvez bien entendu supprimer les sauvegardes correspondantes, mais là encore uniquement du dataset courant, et devrez attendre les 7 jours/3 mois/15 ans de rétention du-dit profil pour libérer réellement l'espace que cette machine occupait (notez cependant que, contractuellement, ça peut parfois se tenir, car on peut vous demander de restaurer finalement cette machine 2 semaines après sa suppression...) ;
• enfin, naviguer dans l'arborescence des sauvegardes peut s'avérer fastidieux, car on cumule une rotation à base de hardlinks + des snapshots : chaque snapshots contient donc une vision de l'arborescence de la veille, ce qui peut vite devenir perturbant. A titre personnel, je n'utilise plus le mode "snap", simplement "copy" sur un backend ZFS pour profiter de la gestion des quota et de la compression (voire de la déduplication, si un jour j'ai assez de RAM).

Performances et montée en charge

Même pour lire et préparer ses centaines de profils de sauvegarde, Katarina va vite. Ce qui va prendre du temps, ce sont surtout :

• les rotations de vos sauvegardes et la purge des rétentions, donc ça travaille côté disques et I/O ;
• les rsync en eux-mêmes depuis vos clients (et donc là encore les disques, ainsi que le réseau).

Afin d'accélérer un peu les choses, Katarina va permettre de définir un degré de parallélisme, et donc la quantité de jobs à exécuter en parallèle, et ceci à 2 niveaux :

• dans chaque profil, en définissant le nombre de machines à sauvegarder en même temps ;
• dans le scheduleur, en définissant le nombre de profils à exécuter en même temps.

Ces deux paramètres sont très utiles pour optimiser vos flux et l'utilisation des ressources de vos infras (par exemple, si plusieurs profils tapent sur des machines qui tournent sur les mêmes clusters/SAN, ça peut occasioner des latences sévères sur vos I/O). Gardez en tête que ces 2 niveaux de parallélisme se multiplient, et que si vous configurez par exemple un parallélisme de 7 sur vos profils (7 machines en même temps) et de 7 dans votre scheduler (7 profils en même temps), vous allez sauvegarder... 49 machines en parallèle, donc votre infra pourrait souffrir un peu.

Katarina étant très léger et simple à déployer, si vous commencez à vous sentir à l'étroit côté disque/bande passante sur votre serveur de sauvegarde, déployez-en un deuxième ! Vous n'aurez qu'à déployer Katarina, migrer les fichiers de profils qui vous intéressent, migrer les données correspondantes (rsync ou ZFS send/receive, selon votre installation), et bien penser à activer ces profils dans votre nouveau scheduler :)

Katarina over SSH

Bon, que dire de plus ? On a des profils assez customisables, des sauvegardes qui fonctionnent de façon plutôt KISS, une arborescence très simple pour restaurer... Sauf que ça pèche un peu côté sécurité, tout ça, mine de rien.

Si par défaut Katarina utilise rsync, et surtout rsyncd côté client, on peut aller un peu plus loin, pour peu d'efforts. On pourrait par exemple envisager de remplacer par rsync par Borg (mais en mode pull, ça serait via du sshfs, pas sûr que les perfomances soient suffisantes).

Dans mon cas, j'ai implémenté les 2 ajouts suivants :

• une authentification par clé publique, pour ne plus me baser sur une whitelist d'IP ;
• et une encapsulation des flux au travers de SSH (pour rappel, si aujourd'hui un rsync se fait par défaut over SSH, ce n'est pas le cas quand on va aller discuter en face avec rsyncd...).

Pour ça, rien de bien complexe : on va simplement lancer le démon rsyncd à distance à travers SSH ! :D

L'idée est la suivante :

• On crée un utilisateur autorisé à lancer la sauvegarde sur le client, et sa clé ;
• On pousse la clé sur le serveur, en limitant cet utilisateur au seul lancement du démon rsyncd avec le fichier de configuration qui va bien :

• On modifie le profil Katarina correspondant pour lui dire de passer via SSH :

• On met en place un fichier de config SSH qui va bien côté serveur, pour qu'il utilise la bonne clé :

• Du coup, pour chaque machine, on se connecte, on lance le démon, on sauvegarde, et on se déconnecte, ce qui coupe le démon.

Simple, rapide, efficace.

Point bonus : on peut ainsi sauvegarder des machines en faisant des rebonds par d'autres (des bastions, par exemple).

Conclusion

Katarina est un petit outil génial. En quelques minutes, j'ai mon parc de dizaines de machines qui est en sauvegarde (du moins pour les fichiers), avec un système de scheduling et de rétention hautement personnalisable, et des rapports par mail. Bien qu'il ne gère pas les sauvegardes des bases de données, pour des besoins modestes il est tout à fait exploitable, et on peut parfaitement envisager d'utiliser un orchestrateur externe pour coordonner des dumps et Katarina (à titre personnel, je fais juste mes dumps à minuit, et Katarina se lance à 1h, ce qui pour mes besoins en auto-hébergement laisse largement assez de temps à mes dumps pour être terminés avant que rsync ne fasse son travail, et j'ai en parallèle une supervision de mes dumps).

Côté sécurité, on a pu voir qu'à moindres frais on peut déjà sensiblement améliorer les choses. Vos serveurs de sauvegarde étant quoiqu'il arrive un point très sensible de votre infrastructure, une solution comme Katarina seule ne suffit pas : à vous de gérer correctement les droits et accès à vos machines. Bien entendu, si vous externalisez vos sauvegardes sur des machines que vous ne maîtrisez pas (coucou le Cloud™ !), il faudra chiffrer tout ça, et donc plutôt passer sur des solutions comme Borg, qui auront toutefois besoin d'un peu d'orchestration et de reporting aussi.

A titre d'information, j'ai administré pendant 3 ans une plateforme de sauvegarde basée sur Katarina, dont voici quelques chiffres :

• 7 à 8 serveurs (du vulgaire Rxx de chez Dell avec des disques SATA), répartis sur 2 datacenters ;
• environ 140To utilisés pour environ 360To réels (non-compressés) ;
• quelques 900 machines clientes en moyenne (variable selon la période).

Et souvenez-vous qu'il n'y a pas de solution de sauvegarde magique qui fait tout, et même le café, gratuitement et de façon infaillible. Choisissez juste vos armes en fonction de vos ennemis, camarades !