Sauvegarder ses machines avec Katarina

Rédigé par Fenix - - 2 commentaires

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 :

root@toto:~# cat /etc/katarina/mon_profil.kat
# -*- perl -*-
#

our %globals = (
    "mail"         => "mon@mail.fr",
    "active"       => 1,
    "forks"        => 3,
    "backup_dir"   => "/nas/backups/katarina/mon_profil",
#    "premounted"   => "/nas/backups/katarina/mon_profil", // Only needed if LVM or ZFS
    "rsynccmd"     => "/usr/bin/rsync --timeout=300",
    "rsyncretries" => 2,

    "rotate_mode"=> "copy",

    "cycles"  => {
        "daily" => {
            "method" => "rsync",
            "retention" => (15 * 86400),
            "late_warning" => (86400 * 1.1),
        },
    },

    "exclude" => [
                ".recycle",
                ".zfs",
                "/dev",
                "/home/*/.cache",
                "/proc",
                "/root/.cache",
                "/run",
                "/selinux",
                "/sys",
                "/tmp",
        ],
);

our %targets = (
    #"serveur.fqdn" => { # Mandatory
    #    "active"  =>  1, # Mandatory (1/0)
    #    "ip"      => "", # Optional : If no fqdn
    #    "module"  => "", # Optional : remote rsync module
    #    "exclude" => "", # Optional : exclude directories/files
    #   "bwlimit" => "", # Optional : bandwidth limit in kByte/s (0 = no limit)
    #    },

    "machine1" => {
            "active" => 1,
                "exclude" => [
                        "/mnt/torrents",
                ],
    },
    "machine4" => {
            "active" => 0,
    },
    "machine2" => {
            "active" => 1,
                "exclude" => [
                        "/var/cache/apt-cacher-ng",
                ],
    },
    "machine3" => {
            "active" => 1,
    },
);

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).

root@toto:~# cat /etc/katarina/katarina-scheduler.conf
# -*- perl -*-
#

our %globals = (
    "mail"   => "mon@mail.fr",
    "forks"      => 2,
    "command"    => "/opt/katarina/katarina.pl -t backup -m -n daily -p ",

);

our @profiles = (
    "profil1",
    "profil2",
    "profil3",
);

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

root@toto:~# cat /etc/cron.d/katarina
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:$PATH

# Daily scheduler
30 0 * * * root /opt/katarina/katarina-scheduler.pl >/var/log/katarina/cron.scheduler.log 2>&1

# Weekly backup
0 6 * * 0 root /opt/katarina/katarina.pl -t backup -m -p mon_profil -n weekly

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) :

            "retention" => (31 * 86400), // 31 jours dans un mois
            "retention" => (4 * 7 * 86400), // 4 semaines de 7 jours dans un mois

 

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 :

Soit le cycle "toto" (avec une rétention de 15 jours, par exemple, mais peu importe) : si j'appelle ce cycle tous les jours, alors c'est un cycle journalier ; si je l'appelle toutes les semaines, alors c'est un cycle hebdomadaire ; si je l'appelle une fois tous les 10 ans.... et ben je l'appelle une fois tous les 10 ans, donc "toto" ça va très bien comme nom.

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 :

    "cycles"  => {
        "daily" => {
            "method" => "rsync",
            "retention" => (7 * 86400),
            "late_warning" => (86400 * 1.1),
        },
    },

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 :

    "cycles"  => {
        "daily" => {
            "method" => "rsync",
            "retention" => (7 * 86400),
            "late_warning" => (86400 * 1.1),
        },
        "weekly" => {
            "method" => "rsync",
            "retention" => (4 * 7 * 86400),
            "late_warning" => (86400 * 1.1),
        },
    },

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 :

    "cycles"  => {
        "daily" => {
            "method" => "rsync",
            "retention" => (7 * 86400),
            "late_warning" => (86400 * 1.1),
        },
        "weekly" => {
            "method" => "use daily",
            "retention" => (4 * 7 * 86400),
            "late_warning" => (86400 * 1.1),
        },
    },

Ici, chaque hebdomdaire se basera sur la dernière journalière effectuée (qu'on effectuera juste avant, pour être synchro). Ce qui veut dire que cette "weekly" sera l'équivalent d'un snapshot de la dernière daily : aucun rsync n'est effectué sur le client ! Ce fonctionnement est très pratique, dans le sens où on évitera de copier 2 fois les données du jour depuis la machine cliente, et ça sera franchement plus rapide, hein, quand même.

 

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) :

root@client:~# cat /etc/katarina/rsyncd-katarina.conf

[katarina]
comment = Katarina Backup
path = /
use chroot = no
lock file = /var/lock/rsyncd
read only = yes
list = yes
uid = root
gid = root
ignore errors = no
ignore nonreadable = no
transfer logging = no
timeout = 600
refuse options = checksum dry-run
hosts allow = 192.168.31.1, 192.168.31.2

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.

root@toto:~# katarina-check mon_profil
machine1                                 [On]  Rsync reply OK
machine2                                 [Off] Rsync reply OK
machine3                                 [On]  Rsync reply OK
machine4                                 [On]  Rsync reply OK
machine5                                 [On]  Rsync reply ERROR 5

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 :

root@toto:~# /opt/katarina/katarina.pl -t backup -m -s -p mon_profil -n daily

root@toto:~# cat /var/log/katarina/mon_profil.daily.report
mon_profil daily backup report on toto

Mode : backup
Rotate mode : copy
Backup started on 2019-09-29 at 00:30:01
Report generated on 2019-09-29 at 04:48:21

Katarina ending with status 0

---------------------------------- ----------- ------RECVEIVE----- ROTATE ---TOTAL
HOSTNAME                     STATUS Tr        MB MM:SS   MM:SS             MB
---------------------------------- ----------- -------------------------- ------------ ------------
machine1                          ok           1     88.00   3:46      3:19               2250
machine2                          ok           1   305.09  17:06     13:16           14331
machine3                          NOK 5    2       0.00   4:20      1:51                     0
---------------------------------- ----------- -------------------------- ------------ ------------

Initial disk stats :
Filesystem                     Size  Used Avail Use% Mounted on
nas/backups/katarina/mon_profil  412G  248G  164G  61% /nas/backups/katarina/mon_profil

Final disk stats :
Filesystem                     Size  Used Avail Use% Mounted on
nas/backups/katarinamon_profil  410G  249G  162G  61% /nas/backups/katarina/mon_profil

------------------------------------------------------------------------
machine3
## rsync command:
/usr/bin/rsync --timeout=300 --rsh=ssh -z -av --numeric-ids --delete-during --bwlimit=0 machine3::katarina /nas/backups/katarina/mon_profil/machine3/daily.last --exclude "*.iso" --exclude "*/.zfs/*" --exclude ".recycle" --exclude ".zfs" --exclude "/dev" --exclude "/home/*/.cache" --exclude "/proc" --exclude "/root/.cache" --exclude "/run" --exclude "/selinux" --exclude "/sys" --exclude "/tmp" --exclude "/var/cache" --exclude "/var/lib/lxcfs" --exclude "/var/lib/mysql" --exclude "/var/lib/pgsql" --exclude "/var/spool/postfix" --exclude "lost+found" --exclude "/media" --exclude "/var/backups/*.gz" --exclude "/var/lib/apt/lists" --exclude "/var/lib/mlocate" --exclude "/var/lib/rrdcached" --exclude "/var/lib/smartmontools" --exclude "/var/log/*.gz" --exclude "/var/log/*/*.gz" --exclude "/var/log/atop" --exclude "/var/log/journal" --exclude "/var/lib/postgresql/10/main/base" --exclude "/var/lib/nginx/proxy"  >> /var/log/katarina/srv/mon_profil-machine3.out 2>&1
## rsync exited with value: 5 (1280)
rsync: did not see server greeting
rsync: did not see server greeting
rsync error: error starting client-server protocol (code 5) at main.c(1666) [Receiver=3.1.2]
rsync error: error starting client-server protocol (code 5) at main.c(1666) [Receiver=3.1.2]

retry command:
/opt/katarina/katarina.pl -t retry -p mon_profil -n daily -s -m

scripts in retry pool:
mon_profil-daily-machine3.lrdf.fr.sh

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.

root@toto:/nas/backups/katarina/mon_profil/machine1# ll
total 26K
drwxr-xr-x 17 root root 18 sept. 29 00:51 .
drwxr-xr-x 19 root root 19 sept.  8 02:22 ..
drwxr-xr-x 17 root root 20 août  21 19:46 daily.1569364202.20190925-00:30:02
drwxr-xr-x 17 root root 20 août  21 19:46 daily.1569450601.20190926-00:30:01
drwxr-xr-x 17 root root 20 août  21 19:46 daily.1569537001.20190927-00:30:01
drwxr-xr-x 17 root root 20 août  21 19:46 daily.1569623401.20190928-00:30:01
drwxr-xr-x 17 root root 20 août  21 19:46 daily.1569709801.20190929-00:30:01
lrwxrwxrwx  1 root root 34 sept. 29 00:51 daily.last -> daily.1569709801.20190929-00:30:01

root@toto:/nas/backups/katarina/mon_profil/machine1/daily.last# ll daily.last/
total 35K
drwxr-xr-x  17 root root  20 août  21 19:46 .
drwxr-xr-x  17 root root  18 sept. 29 00:51 ..
drwxr-xr-x   2 root root 136 avril 13 20:41 bin
drwxr-xr-x   4 root root  27 août  13 08:18 boot
drwxr-xr-x 122 root root 221 sept.  7 22:15 etc
drwxr-xr-x   4 root root   4 mai    4 22:40 home
lrwxrwxrwx  15 root root  29 juin   7 22:49 initrd.img -> boot/initrd.img-4.9.0-9-amd64
drwxr-xr-x  20 root root  32 avril 13 23:19 lib
drwxr-xr-x   2 root root   3 mars   5  2019 lib64
drwxr-xr-x   6 root root   6 mars  12  2019 mnt
drwxr-xr-x   3 root root   3 oct.  29  2018 opt
drwx------   9 root root  20 sept. 16 08:53 root
drwxr-xr-x   2 root root 221 juin  28 12:45 sbin
drwxr-xr-x   2 root root   2 mars   5  2019 srv
drwxr-xr-x  10 root root  10 mars   5  2019 usr
drwxr-xr-x  11 root root  13 mars   5  2019 var
lrwxrwxrwx  15 root root  26 juin   7 22:49 vmlinuz -> boot/vmlinuz-4.9.0-9-amd64
lrwxrwxrwx  15 root root  26 mars   5  2019 vmlinuz.old -> boot/vmlinuz-4.9.0-8-amd64

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 :

root@nexus:~# katarina-status
                         Running-+
                        Active-+ |
Profile                        | |  Progress
-----------------------------  - -  --------------------------------
mon_profil1 (daily)          X .  Last exit with status 40
mon_profil2 (daily)          X .  Last exit with status 0
mon_profil3 (daily)          X .  Last exit with status 0

 

"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 qu'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 :
katarina@client:~$ cat .ssh/authorized_keys
command="sudo /usr/bin/rsync --config=/etc/katarina/rsyncd-katarina.conf --server --daemon .",no-pty,no-user-rc,no-X11-forwarding ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAID7O0uV1SWMpa+vmrSGDKYx+MF1OS2YjTbXXiTBLkH1b katarina@server
root@client:~# cat /etc/sudoers
katarina ALL=(ALL) NOPASSWD: /usr/bin/rsync --config=/etc/katarina/rsyncd-katarina.conf --server --daemon .
  • On modifie le profil Katarina correspondant pour lui dire de passer via SSH :
    "rsynccmd"     => "/usr/bin/rsync --timeout=300 --rsh=ssh -z",
  • On met en place un fichier de config SSH qui va bien côté serveur, pour qu'il utilise la bonne clé :

host client1
        port 8888
        user katarina
        IdentityFile /root/.ssh/katarina

host client2
        port 8888
        user katarina
        IdentityFile /root/.ssh/katarina
        proxycommand ssh -W %h:%p client1

  • 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 !

2 commentaires

#1  - Gérard a dit :

Bonjour,
Je suis très tenté par cet outil. Je l'ai récupéré mais je n'ai pas trouvé le fichier INSTALL ... qui, à priori, devrait décrire l'installation ...
Faut-il simplement créer soi-même les répertoires pour l'appli ?
Cordialement.

Répondre
#2  - Fenix a dit :

Bonsoir !

En effet il n'y a plus de fichier INSTALL ni d'exemples de configurations dans l'archive... étrange :(

Donc, il suffit de :
- créer les répertoires /etc/katarina (pour les configurations), /opt/katarina (pour les scripts) et /var/log/katarina (pour les logs)
- créer des fichiers de configurations sur l'exemple de ceux dans l'article (un .kat pour le profil à sauvegarder, et éventuellement un katarina-scheduler.conf s'il y a plusieurs profils à gérer)
- et configurer un cron pour appeler tout ça !

Dispo si besoin de plus d'informations :)

Répondre

Fil RSS des commentaires de cet article

Écrire un commentaire

Quelle est la deuxième lettre du mot svdpg ?