Toute solution de sauvegarde nécessite un minimum de configuration pour faire le travail attendu. Ces trois solutions ne font pas exception.
Borg, Restic et Kopia ont comme point commun d’utiliser un dépôt dans lequel ils poussent les sauvegardes. Ce dépôt doit être initialisé avant de pouvoir faire une première sauvegarde. En pratique, voilà comment j'ai procédé pour chacun de ses logiciels.
Borg
Le fonctionnement de Borg s’appuie sur une clé SSH pour ouvrir le tunnel de communication entre Borg sur le serveur et Borg sur le client. À cette fin, j’utilise une clé et une configuration SSH dédiées. Si on maîtrise la configuration SSH côté client, cela ouvre la porte à un paramétrage assez fin du tunnel entre le client et le serveur. On se retrouve en terrain connu et c'est plutôt confortable.
$ borg init --encryption=repokey-blake2 --rsh "ssh -F .ssh/config_bkp" bkppat@192.168.0.22:/backupmaison/bench-borg
La création de la première sauvegarde par contre est une toute autre histoire. Le nombre de paramètres est plus important, au point que dans mes scripts, je les défini sous forme de variables que j'utilise ensuite dans les différentes commandes :
$ SSH="ssh -F .ssh/config_bkp"
$ HOMEREPO="bkppat@192.168.0.22:/backupmaison/bench-borg"
$ HOMEOPTIONS="--stats --exclude-caches --exclude-if-present .nobench-bkup"
$ SOURCEROOT="/Users/patpro"
$ ARCHIVENAME=$(date "+%Y%m%d.%s")
$ export BORG_PASSPHRASE="foobar"
$ borg create ${HOMEOPTIONS} --rsh "${SSH}" ${HOMEREPO}::${ARCHIVENAME} ${SOURCEROOT}
Avec Borg, tout le paramétrage se fait de cette manière. Il n'y a pas de fichier de configuration. Heureusement, une tâche de sauvegarde est supposée être automatisée, donc résider sous une forme sous une autre dans un script qu'il ne sera pas nécessaire de retaper manuellement à la ligne de commandes. L'inconvénient est donc plutôt mineur.
Kopia
Si l'on utilise le transport SFTP, alors le fonctionnement de Kopia est à peu près similaire à celui de Borg, à ceci près que Kopia utilise par défaut sa propre implémentation SSH. Cela nécessite de lui préciser l'emplacement du fichier known_hosts par exemple. Il ne prendra donc pas en compte non plus le fichier de configuration du client SSH natif de la machine. Malheureusement, l'implémentation native du protocole SSH dans Kopia ne supporte pas tous les types de clés. Il s'agit d'un bug identifié mais pas encore corrigé. L'utilisation de clés de type Elliptic Curve reste possible si on dit au client Kopia d'utiliser un client SSH externe. J'ai, pour ma part, choisi de créer une clé RSA pour contourner le bug.
$ kopia repository create sftp --path=/backupmaison/bench-kopia --host=192.168.0.22 --username=patpro --keyfile=/Users/patpro/.ssh/kopia_rsa --known-hosts=/Users/patpro/.ssh/known_hosts-kopia
À l'inverse de Borg, le paramétrage de Kopia est très largement déporté dans une configuration côté dépôt. Il s'agit, au travers de commandes de gestion de politiques, de régler un certain nombre de paramètres qui seront utilisables par le client Kopia.
Voici ce que cela donne dans mon cas de figure :
$ kopia policy list 85bf7bc7688d5819433aad9ba1c84f6b (global) $ kopia policy set --add-dot-ignore .nobench-bkup 08c59f69009c88ee463de6acbbc59a3a Setting policy for patpro@cassandre:/Users/patpro/08c59f69009c88ee463de6acbbc59a3a - adding ".nobench-bkup" to "dot-ignore filenames" $ kopia policy set --compression=zstd --global Setting policy for (global) - setting compression algorithm to zstd
Ces politiques fonctionnent avec une notion d'héritage, de la politique la plus générale à la plus particulière :
$ kopia policy show --global| head Policy for (global): Retention: Annual snapshots: 3 (defined for this target) Monthly snapshots: 24 (defined for this target) Weekly snapshots: 4 (defined for this target) Daily snapshots: 7 (defined for this target) Hourly snapshots: 48 (defined for this target) Latest snapshots: 10 (defined for this target) Ignore identical snapshots: false (defined for this target) $ kopia policy show 08c59f69009c88ee463de6acbbc59a3a| head Policy for patpro@cassandre:/Users/patpro/08c59f69009c88ee463de6acbbc59a3a: Retention: Annual snapshots: 3 inherited from (global) Monthly snapshots: 24 inherited from (global) Weekly snapshots: 4 inherited from (global) Daily snapshots: 7 inherited from (global) Hourly snapshots: 48 inherited from (global) Latest snapshots: 10 inherited from (global) Ignore identical snapshots: false inherited from (global)
Les différents paramètres du client permettant de définir les tâches de sauvegarde et de purge étant déportés, la ligne de commandes pour les différentes actions s’en trouve grandement simplifiée. Il reste néanmoins à connecter le client au serveur de sauvegarde. Cela se fait avec une commande de ce style :
$ kopia -p foobar repository connect sftp --path=/backupmaison/bench-kopia --host=192.168.0.22 --username=patpro --keyfile=/Users/patpro/.ssh/kopia_rsa --known-hosts=/Users/patpro/.ssh/known_hosts-kopia
La déconnexion se faisant alors de cette façon :
$ kopia repository disconnect
Il est important de comprendre que cette connexion et cette déconnexion ne doivent pas nécessairement être faites de manière systématique. C'est une erreur que j'ai moi-même commise : lors des premiers jours d'exécution de mes scripts de sauvegarde, pour chaque tâche de Kopia, je faisais la connexion, la tâche puis la déconnexion. Les effets de bord sont minimes, mais j'y reviendrai. Dans tous les cas, une connexion à un instant T persiste, car ce n'est pas une connexion réseau. Il vaut mieux voir cela comme une pré-configuration du client, lui permettant d'utiliser notamment les login, mot de passe et coordonnées du serveur pour dérouler les tâches de sauvegarde. Dans la suite de mes tests, j'ai simplement fait une connexion une fois et je n'ai plus déconnecté mon client. Si bien que la création d'une sauvegarde se résume à cette commande triviale :
$ kopia snapshot create /Users/patpro
La différence avec Borg saute aux yeux.
Restic
Pour tester Restic, j'ai souhaité utiliser le REST-server. Le transport se fait sur HTTP et la commande est relativement triviale. Côté serveur, la configuration est assez basique, puisque j'ai simplement précisé le chemin du stockage, l'interface et le port TCP pour l'écoute et le paramètre --no-auth car je n'ai pas besoin d'authentification.
$ restic -r rest:http://192.168.0.22:8000/ init
Tout comme Borg, les tâches de sauvegarde ou de purge nécessitent le passage de l'intégralité des paramètres dans la ligne de commandes :
$ export RESTIC_PASSWORD=foobar $ restic -r rest:http://192.168.0.22:8000/ backup --verbose --exclude-if-present .nobench-bkup --one-file-system --exclude-caches --no-scan --read-concurrency 4 /Users/patpro
Pas grand-chose à ajouter du côté de Restic, qui se comporte à peu de chose près comme Borg en terme de paramétrage et de ligne de commandes. Même si les paramètres venaient à se multiplier, le tout prendrait place dans un script shell parfaitement lisible.
Pour conclure
J'aime beaucoup la lisibilité d'une ligne de commandes avec ou sans variables : elle me permet d'analyser un script de sauvegarde dans n'importe quel éditeur et dans n'importe quel contexte. Néanmoins je dois admettre que je suis assez séduit par l'élégance du système de politiques de Kopia, même si accéder au contenu de la politique nécessite d'accéder à la commande Kopia dans un terminal ainsi qu’au dépôt de sauvegarde (c'est un inconvénient). Je crois que nous sommes face à un critère de choix qui dépendra uniquement de la préférence de l'utilisateur final.
