Borg, Kopia, Restic: from configuration to first backup

[This is the English translation by DeepL]
[Version originale en français]

All backup solutions require a minimum of configuration to do the job. These three solutions are no exception.
What Borg, Restic and Kopia have in common is the use of a repository into which they push backups. This repository must be initialized before the first backup can be made. In practice, here's how I proceeded with each of these programs.

Borg

Borg relies on an SSH key to open the communication tunnel between Borg on the server and Borg on the client. For this purpose, I use a dedicated SSH key and configuration. If you've mastered SSH configuration on the client side, this opens the door to fairly fine-tuning of the tunnel between client and server. We're back in familiar territory, and it's quite comfortable.

$ borg init --encryption=repokey-blake2 --rsh "ssh -F .ssh/config_bkp" bkppat@192.168.0.22:/backupmaison/bench-borg

Creating the first backup, on the other hand, is a completely different story. The number of parameters is so great that, in my scripts, I define them as variables which I then use in the various commands:

$ 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}

With Borg, all parameterization is done in this way. There is no configuration file. Fortunately, a backup task is supposed to be automated, i.e. to reside in one form or another in a script that doesn't need to be retyped manually at the command line. The disadvantage is therefore rather minor.

Kopia

If you're using SFTP transport, then Kopia works in much the same way as Borg, except that Kopia uses its own SSH implementation by default. This requires you to specify the location of the known_hosts file, for example. Nor will it take into account the configuration file of the machine's native SSH client. Unfortunately, Kopia's native implementation of the SSH protocol does not support all key types. This bug has been identified but not yet corrected. The use of Elliptic Curve keys remains possible if the Kopia client is told to use an external SSH client. For my part, I chose to create an RSA key to get around the 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

Unlike Borg, Kopia's configuration is largely deported to the repository. This involves using policy management commands to set a certain number of parameters for use by the Kopia client.
Here's how it works in my case :

$ 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

These policies are inherited, from the most general to the most specific:

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

As the various client parameters used to define backup and purge tasks are deported, the command line for the various actions is greatly simplified. You still need to to connect the client to the backup server. This is done with a command like :

$ 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

Disconnection is then carried out as follows:

$ kopia repository disconnect

It's important to understand that this connection and disconnection doesn't have to be done systematically. It's a mistake I made myself: in the early days of running my backup scripts, for each Kopia task I would connect, perform the task and then disconnect. The side effects are minimal, but I'll come back to that later. In any case, a connection at time T persists, because it's not a network connection. It's best to think of this as a pre-configuration of the client, enabling it to use the server's login, password and contact details to carry out backup tasks. In the rest of my tests, I simply made a connection once and never disconnected my client again. As a result, creating a backup is as simple as this trivial command:

$ kopia snapshot create /Users/patpro

The difference with Borg is obvious.

Restic

To test Restic, I decided to use the REST-server. Transport is over HTTP and the command is relatively trivial. On the server side, configuration is fairly basic, since I've simply specified the storage path, interface and TCP port for listening and the --no-auth parameter, as I don't need authentication.

$ restic -r rest:http://192.168.0.22:8000/ init

Like Borg, backup and purge tasks require all parameters to be passed on the command line:

$ 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

There's not much more to say about Restic, which behaves much like Borg in terms of settings and command line. Even if the number of parameters were to multiply, it would all take place in a perfectly readable shell script.

To conclude

I really like the readability of a command line with or without variables: it allows me to analyze a backup script in any editor and in any context. Nevertheless, I have to admit that I'm quite taken with the elegance of Kopia's policy system, even if accessing the policy content requires access to the Kopia command in a terminal as well as to the backup repository (which is a drawback). I think we're faced with a choice criterion that will depend solely on the end-user's preference.

Related posts

Borg, Kopia, Restic : de la configuration à la première sauvegarde

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.

Related posts

Borg, Kopia, Restic: functional scope and general information

[This is the English translation by DeepL]
[Version originale en français]

The functional scope of the three backup solutions is relatively equivalent. Each operates in "push" mode, i.e. the client initiates the backup to the server. This mode of operation is undoubtedly best suited to people who manage a small handful of machines. The "pull" mode is available for Borg, but requires a few adjustments.
All three programs use duplication and compression mechanisms to limit the volume of data transmitted and stored. With Kopia, compression is not activated by default. All three also implement backup retention and expiration management, repository maintenance mechanisms, etc.

Borgbackup

logo BorgbackupBorgbackup, or Borg, is a solution developed in Python. It is relatively easy to install, but does not allow Windows workstations to be backed up. Its documentation is relatively exhaustive, and its ecosystem includes automation and GUI solutions. It evolves regularly. Tests were carried out with version 1.2.7. Branch 1.4 (beta) is available and branch 2 is under active development.

To use Borg, the software must also be installed on the destination server. This is a constraint that may prevent some people from using Borg. Remote backup requires an SSH connection. In addition, access to the backup repository is exclusive (lock), i.e. it is not possible to back up several machines to the same repository at the same time. Furthermore, backing up multiple clients to the same repository is discouraged for various reasons.

Should the client machine be compromised, there is cause for concern that the backup software present on the machine will allow remote archives to be destroyed. By default, this is the case. Nonetheless, Borg's client-server operation allows you to add controls. It is possible, for example, to configure the client so that it can only add and restore files, but not delete archives.

All Borg settings are made using command-line arguments. There are no parameter files, although dedicated files can be used to deport lists of exclusions and inclusions, for example.

Official website: https://www.borgbackup.org/
Official documentation: https://borgbackup.readthedocs.io/en/stable/
Cooperative development platform: https://github.com/borgbackup/borg

Kopia

logo KopiaKopia is a solution coded in GO. The version used here is 0.15.0 and the project is active. It is a monolithic binary available for different architectures and operating systems. Kopia is Windows-compatible and offers a GUI version. It also works with many different types of remote storage, such as S3, Azure blob Storage, Backblaze B2, WebDAV, SFTP and others. You don't need to install any server-side components to use Kopia.
It is also possible to back up several clients in the same repository. Deduplication can then be achieved across backups of all clients.

Kopia also features an optional "server" mode, which can be configured to add user management when users share the same repository, for example. This feature can also be used to limit the client's rights over stored archives, for example, by prohibiting their deletion. If you don't use the server part of Kopia, you won't be able to prevent a compromised client from deleting its backups.

Kopia lets you manage backup policies that are saved and then applied to backup jobs (or cleanup jobs, since these policies also include the notion of retention). This backup policy management is rather elegant, and allows you to limit the number of command line arguments each time a job is launched.

Official website: https://kopia.io/
Official documentation: https://kopia.io/docs/
Cooperative development platform: https://github.com/kopia/kopia/

Restic

logo ResticRestic is also coded in GO. The version used here is 0.16.4 and the project is active. It is available for various architectures and operating systems, including Windows. The range of remote storage solutions supported by Restic is broadly similar to that of Kopia. Restic also offers its own high-performance HTTP server, which implements Restic's REST API. As with Kopia and Borg, this can ensure secure backups by limiting client rights.

This secure backup protocol, commonly referred to as "append-only", poses constraints on use that can be discouraging for users. Indeed, backing up machines to repositories on which old backups cannot be deleted poses a problem of volume management. For my part, I'd much prefer the client to have full rights over the backups, but for the repository of these backups to be stored on a file system that allows regular snapshots to be generated. In my case, all backups are written to a ZFS file system and automatic snapshots are taken every day with relatively long retention times.

Like Borg, Restic relies exclusively on command-line parameters to configure the various tasks.

Official website: https://restic.net/
Official documentation: https://restic.readthedocs.io/en/stable/index.html
Cooperative development platform: https://github.com/restic/restic

In a nutshell

Everyone has to make up their own mind according to their own needs, but if you don't rule out any scenario (Windows client backup, shared repository or S3 storage...), Borg doesn't have the edge. If, like me, you back up a handful of macOS/FreeBSD/Linux machines to servers on which you can install software and to which you can connect via SSH, then Borg is on a par with Kopia and Restic.

Borg Kopia Restic
Portability - + +
Storage options - + +
Transport options - + +
Multi-client repository - + +
Related posts

Borg, Kopia, Restic : périmètre fonctionnel et généralités

Le périmètre fonctionnel des trois solutions de sauvegarde est relativement équivalent. Chacune fonctionne sur le mode «push», c'est-à-dire que c'est le client qui initie la sauvegarde vers le serveur. Ce mode de fonctionnement est sans doute le plus adapté aux personnes qui gèrent une poignée de machines. Le mode «pull» est disponible pour Borg, mais requiert quelques aménagements.
Les trois programmes utilisent les mécanismes de duplication et de compression pour limiter les volumétries transmises et stockées. Attention cependant, avec Kopia, la compression n'est pas activée par défaut. Ils implémentent aussi tous trois une gestion de la rétention et de l'expiration des sauvegardes, des mécanismes d'entretien du dépôt, etc.

Borgbackup

logo BorgbackupBorgbackup, ou Borg pour les intimes, est une solution développée en langage python. Elle s'installe plutôt simplement mais ne permet pas la sauvegarde des postes Windows. Sa documentation est relativement exhaustive et son écosystème inclut des solutions d'automatisation et d'interfaces graphiques. Elle évolue régulièrement. Les tests ont été faits avec la version 1.2.7. La branche 1.4 (beta) est disponible et la branche 2 est en cours de développement actif.

Pour utiliser Borg, il est nécessaire que le logiciel souhaite aussi installer sur le serveur de destination. C'est une contrainte qui pourra bloquer certaines personnes. La sauvegarde distante passe par une connexion SSH. De plus, l'accès au dépôt de sauvegarde est exclusif (verrou), c'est-à-dire qu'il n'est pas possible de sauvegarder plusieurs machines dans le même dépôt en même temps. Par ailleurs, la sauvegarde de plusieurs clients sur le même dépôt est découragée pour différentes raisons.

En cas de compromission de la machine cliente, on peut s'inquiéter du fait que le logiciel de sauvegarde présent sur la machine permette la destruction des archives distantes. Par défaut c'est bien le cas. Néanmoins, le fonctionnement client-serveur de Borg permet d'ajouter des contrôles. Il est possible par exemple de configurer le client pour qu'il ne puisse faire que des ajouts et des restaurations de fichiers, mais pas de suppression d'archives.

Tout le paramétrage de Borg se fait avec des arguments en ligne de commande. Il n'y a pas de fichier de paramètres, même si on peut déporter dans des fichiers dédiés comme les listes d'exclusions et d’inclusions par exemple.

Site officiel : https://www.borgbackup.org/
Documentation officielle : https://borgbackup.readthedocs.io/en/stable/
Plate-forme de développement coopératif : https://github.com/borgbackup/borg

Kopia

logo KopiaKopia est une solution codée en GO. La version utilisée ici est la 0.15.0 et le projet est actif. Il s'agit d'un binaire monolithique disponible pour différentes architectures et systèmes d'exploitation. Kopia est compatible Windows et propose une version graphique. Il fonctionne aussi avec de nombreux stockages distants différents comme par exemple les stockages de type S3, Azure blob Storage, Backblaze B2, WebDAV, SFTP, etc. Il n'est pas nécessaire d'installer des composants côté serveur pour utiliser Kopia.
Il est aussi possible de sauvegarder plusieurs machines dans le même dépôt. La déduplication pourra alors être mise en commun.

Kopia dispose tout de même d'un mode «serveur» facultatif qu'il est possible de configurer pour ajouter une gestion d'utilisateurs, lorsque ces derniers partagent un même dépôt par exemple. C'est aussi grâce à cette fonctionnalité qu'il est possible de limiter les droits du client sur les archives stockées, par exemple en interdisant leur suppression. Si vous n'utilisez pas la partie serveur de Kopia, vous ne pourrez pas empêcher qu’un client compromis supprime ses sauvegardes.

Kopia permet de gérer des politiques de sauvegarde qui sont enregistrés et ensuite applicables à des tâches de sauvegarde (ou de nettoyage, puisque ces politiques incluent aussi la notion de rétention). Cette gestion de politiques de sauvegarde est plutôt élégante et permet de limiter le nombre d'arguments de la ligne de commande à chaque lancement d'une tâche.

Site officiel : https://kopia.io/
Documentation officielle : https://kopia.io/docs/
Plate-forme de développement coopératif : https://github.com/kopia/kopia/

Restic

logo ResticRestic est aussi codé en GO. La version utilisée ici est la 0.16.4 et le projet est actif. il est disponible pour différentes architectures et systèmes d'exploitation, y compris Windows. L'éventail de solutions de stockage distant supporté par Restic est à peu près similaire à celui de Kopia. Restic propose en plus son propre serveur HTTP haute performance qui implémente l’API REST de Restic. Cela permet, comme dans le cas de Kopia et de Borg, d'assurer une sécurisation des sauvegardes en limitant les droits du client.

Ce protocole de sécurisation des sauvegardes, communément appelé «append-only», pose des contraintes d'utilisation qui peuvent être décourageantes pour l'utilisateur. En effet, sauvegarder des machines vers des dépôts sur lesquels on ne peut pas supprimer les anciennes sauvegardes pose un problème de gestion de volumétrie. Pour ma part, je préfère de loin que le client ait tous les droits sur les sauvegardes, mais que le dépôt de ces sauvegardes soit stockés sur un système de fichiers qui permet de générer des snapshots réguliers. Dans mon cas, toutes les sauvegardes sont écrites sur un système de fichiers ZFS et des snapshots automatiques sont pris tous les jours avec des rétentions relativement longues.

Tout comme Borg, Restic s'appuie exclusivement sur des paramètres de ligne de commande pour assurer la configuration des différentes tâches.

Site officiel : https://restic.net/
Documentation officielle : https://restic.readthedocs.io/en/stable/index.html
Plate-forme de développement coopératif : https://github.com/restic/restic

Pour résumer

Chacun doit se faire sa propre idée à l’aune de ses propres besoins, mais si l’on n’exclue aucun scénario (sauvegarde de client Windows, dépôt partagé ou encore stockage S3…), Borg n’a pas l’avantage. Si comme moi vous sauvegardez une poignée de machines macOS/FreeBSD/Linux à destinations de serveurs sur lesquels vous pouvez installer des logiciels et auxquels vous pouvez vous connecter en SSH alors Borg fait jeu égal avec Kopia et Restic.

Borg Kopia Restic
Portabilité - + +
Options de stockage - + +
Options de transport - + +
Dépôt multi-client - + +
Related posts

Borg, Kopia, Restic : un comparatif

[English translation by DeepL]
Depuis plusieurs années, j'utilise Borg Backup. Cependant, fin 2023, j'ai rencontré des problèmes importants avec la sauvegarde d'une de mes machines. J'ai donc décidé d'explorer des pistes alternatives. Une recherche rapide m'a permis de trouver des solutions relativement équivalentes à Borg Backup : Restic et Kopia.

En absence d'un comparatif de ces trois solutions (il existe un comparatif «ancien» entre Borg et Restic mais il ne va pas aussi loin et ne mentionne pas Kopia), j'ai décidé de me lancer dans des tests moi-même, pour pouvoir comparer des métriques simples et communes aux trois logiciels.

Finalement, une fois qu'une sauvegarde régulière est automatisée, les métriques importantes sont pour moi : la durée d'une sauvegarde, la volumétrie des échanges réseau et la volumétrie de stockage sur le serveur de sauvegarde. Des métriques similaires sont intéressantes à explorer sur les opérations de restauration d’une sauvegarde et sur les opérations de maintenance du serveur de sauvegardes.

Mon environnement de test est constitué de ces différentes briques :

  • machine cliente : macmini M2 Pro sous macOS 13.6.3, 32 Go RAM
  • serveur de sauvegarde : PC à base de Intel(R) Core(TM) i3-3220T, sous FreeBSD 14, 16 Go RAM, stockage ZFS sur SSD
  • réseau ethernet 1Gbps «switché»
  • une instance Splunk pour ingérer les logs et produire des statistiques et des graphiques

Pour m'assurer de travailler sur des données représentatives, j'ai décidé de sauvegarder une partie de mon répertoire utilisateur. J'ai exclu un immense répertoire de photos numériques qui ne bouge que très rarement, ainsi que de nombreux répertoires de cache qu’il n’est pas pertinent de sauvegarder. La volumétrie finale de ma cible de sauvegarde avoisine les 140Go.

Je me suis basé pour mon protocole de sauvegarde sur mon expérience acquise avec Borg. Néanmoins, chaque logiciel ayant ses spécificités, un temps de documentation et d'adaptation a été nécessaire. Malgré ces préparatifs, le déroulement des sauvegardes m'a réservé quelques surprises.

L'automatisation des sauvegardes s'est faite par un script bash unique permettant de lancer dans un ordre aléatoire la création des sauvegardes via Borg, Restic et Kopia. J’avais dans l'idée que la première tâche de sauvegarde serait potentiellement pénalisée par l'accès à des fichiers sur le poste client qui ne seraient pas dans le cache du système, mais après 15 jours de test, j'ai constaté qu'il n'y a aucune différence visible de temps de sauvegarde qui soit imputable à l'ordre des tâches de sauvegarde. J'ai donc décidé ultérieurement de figer l’ordre des tâches de sauvegarde, ce qui me permet aussi de suivre les métriques bien plus facilement.
La machine cliente a des périodes de sommeil planifié la nuit. Pendant ces périodes de sommeil, aucune sauvegarde n'a lieu. De plus, la planification du script est faite dans Launchd via l’argument StartInterval à 3600 secondes. Contrairement à une planification de type crontab, par exemple, celle-ci assure un délai incompressible d'une heure entre deux exécutions du script. C'est-à-dire qu'il doit s'écouler une heure entre la fin de l'exécution précédente et le début de la nouvelle exécution. Ainsi, le script est réellement lancé un peu moins d'une fois par heure. Par exemple si chaque exécution dure 5 minutes, alors il faut 26h et non 24h pour qu’il soit lancé 24 fois.

Note importante : je ne vais pas aborder en détails dans ces articles les différences d'ergonomie de ces logiciels, la disponibilité ou non d'une interface graphique de gestion, etc. Certaines des solutions présentées ici disposent de plusieurs interfaces graphiques différentes, les fonctionnalités des trois produits varient, et je ne souhaite pas faire un catalogue qui comparerait chaque logiciel point par point.

Voici le sommaire de mon comparatif. Le lien vers chaque article deviendra actif à sa publication.

Related posts

Borg, Kopia, Restic: a comparison

[This is the English translation by DeepL]
[Version originale en français]

I've been using Borg Backup for several years now. However, at the end of 2023, I encountered major problems with the backup of one of my machines. So I decided to explore alternative solutions. A quick search revealed two solutions that were relatively equivalent to Borg Backup: Restic and Kopia.

In the absence of a comparison of these three solutions (there is an "old" comparison between Borg and Restic, but it doesn't go as far and doesn't mention Kopia), I decided to carry out some tests myself, to be able to compare simple metrics common to all three software packages.

Finally, once a regular backup is automated, the important metrics for me are: backup duration, network exchange volume and storage volume on the backup server. Similar metrics are worth exploring for backup restore operations and backup server maintenance operations.

My test environment consists of the following components:

  • client: macmini M2 Pro running macOS 13.6.3, 32 GB RAM
  • backup server: Intel(R) Core(TM) i3-3220T-based PC, running FreeBSD 14, 16 GB RAM, ZFS storage on SSD
  • switched 1Gbps ethernet network
  • Splunk instance to ingest logs and produce statistics and graphs

To make sure I was working with representative data, I decided to back up part of my user directory. I've excluded a huge directory of digital photos that rarely changes, as well as numerous cache directories that it's not relevant to back up. The final size of my backup target is around 140GB.

I based my backup protocol on my experience with Borg. However, as each software has its own specificities, it took some time to document and adapt. In spite of these preparations, the backup process did have a few surprises in store for me.

Backups were automated using a single bash script, which launched the creation of backups via Borg, Restic and Kopia in random order. I had in mind that the first backup task would be potentially penalized by access to files on the client workstation that were not in the system cache, but after 15 days of testing, I found that there was no visible difference in backup time attributable to the order of the backup tasks. I therefore subsequently decided to freeze the order of backup jobs, which also makes it much easier to track metrics.

The client machine has scheduled sleep periods at night. During these sleep periods, no backup takes place. In addition, the script is scheduled in Launchd by setting the StartInterval argument to 3600 seconds. Unlike a crontab schedule, for example, this one ensures an incompressible delay of one hour between two script executions. In other words, one hour must elapse between the end of the previous execution and the start of the new one. This means that the script is actually run just under once an hour. For example, if each execution lasts 5 minutes, then it takes 26 hours, not 24 hours, to run the script 24 times.

Important note: I'm not going to go into detail in these articles about the differences in the software's ergonomics, the availability or otherwise of a graphical management interface, etc. Some of the solutions presented here have several different graphical interfaces, the functionalities of the three products vary, and I don't wish to make a catalog comparing each software point by point.

Here's the table of contents of my comparison. The link to each article will become active upon publication.

Related posts

Cartographie de l’utilisation d’un clavier

Il y a quelques temps je me suis mis en tête d'investir dans des claviers mécaniques de bonne facture. L'exercice va se solder notamment par l'achat d'un Vortex ViBE sur lequel il manque pas mal de touches par rapport à un clavier étendu grand public.
J'ai donc voulu faire un état des lieux de mon utilisation actuelle du clavier étendu dans mes activités privées et professionnelles, raison pour laquelle j'ai investi dans un enregistreur de frappes clavier.
Après environ 3,5 jours d'utilisation de ce keylogger j'ai obtenu un fichier de ~55000 "touches pressées".
J'ai plusieurs options pour exploiter ce fichier : un compte-rendu statistique en chiffres et graphiques ou une cartographie visuelle (heatmap). J'ai choisi la cartographie dans un premier temps pour sa lisibilité immédiate. C'est par contre une option complexe à mettre en œuvre. Il existe différentes pistes pour réaliser une heatmap de clavier sur la base d'un texte fourni par l'utilisateur, mais toutes celles que j'ai trouvées utilisent un clavier réduit et ne proposent pas la disposition AZERTY.
La seule piste viable était donc de trouver une solution libre et ouverte, dans un langage que je comprenne a minima, de sorte que je puisse modifier le programme pour l'adapter à un clavier étendu en français.
J'ai jeté mon dévolu sur Tapmap, petit programme codé en Python 3. La première étape a été de valider que le programme fonctionne sur mon PC sous FreeBSD, après une installation via pip install --user pour épargner mon système. Le test avec un jeu de données bidons ayant été concluant, le plus gros du travail restait à faire. Avant d'attaquer la modification du code de l'application pour étendre la liste des caractères pris en charge j'ai remplacé le fichier keyboard.png représentant un clavier qwerty court par un clavier azerty étendu. Par chance le clavier initial est de marque Apple, ci-bien qu'il est exactement superposable à une image de mon propre clavier. Cela évite d'avoir à refaire toute la correspondance entre un caractère et ses coordonnées physiques sur l'image du clavier. Attention, l'image du clavier doit être en PNG avec une couche alpha, sinon le logiciel ne pourra pas lui superposer la heatmap.
À partir de là il reste le plus dur : faire correspondre chaque caractère enregistré par le keylogger à une zone de pixel sur l'image du clavier. Le programme tapmap est très simple : pour chaque caractère présent dans le fichier en entrée, il cherche une correspondance dans un tableau de coordonnées. Cela impose que chaque caractère qu'on veut représenter soit décrit de manière unique dans la table de correspondance, et que chaque touche qu'on souhaite représenter soit codée par un caractère unique.
De ce constat découlent deux problèmes : le 1 en haut à gauche du clavier doit être traité différemment du 1 du pavé numérique, les codes multi-caractères enregistrés par le keylogger doivent être convertis en caractères uniques. Par exemple quand le keylogger enregistre [1N] il indique que le 1 du pavé numérique a été tapé, quand il enregistre [Sh]1 il indique que la touche majuscule a été pressée pour taper le chiffre 1 en haut à gauche du clavier. Dans le même esprit [Alt][Sh]° représente le caractère ] obtenu par pression sur les touches alt-maj-) du clavier.
Pour palier ces deux problèmes d'un seul coup j'ai converti l'ensemble des codes spécifiques en caractères spéciaux (des lettres grecques en majorité). Ainsi le 1 du pavé numérique ([1N]) devient ρ, le 0 ([0N]) devient π, etc. Via un script shell (juste une grosse commande sed) je transforme le fichier du keylogger en fichier utilisable par tapmap où chaque caractère représente de manière univoque une touche du clavier.
Par de nombreux tests successifs la table de correspondance entre caractères et emplacements sur l'image est complétée avec les spécificités du clavier Apple français, et les touches supplémentaires du clavier étendu. Au final, j'obtiens ces résultats comme synthèse de mes ~55K touches enregistrées :




En fonction du choix de gradient de couleurs la lisibilité est très variable, le second rendu permet par exemple de distinguer bien plus de nuances que les deux autres puisqu'on y aperçoit même les frappes sur le pavé numérique.
En supprimant du fichier source tous les caractères qui ne représentent pas des chiffres il devient possible de comparer l'utilisation du pavé numérique avec l'utilisation des chiffres du haut du clavier :

Dans mon cas le petit doigt de la main gauche appuie sur "maj" et l'index et le majeur atteignent les chiffres de 1 à 5, alors que la main droite se reporte spontanément sur le pavé numérique, que j'utilise aussi systématiquement pour poser des calculs ou taper des adresses IP.

Related posts

Bref, j’ai acheté un keylogger

Avant d'en venir au dispositif qui donne son titre à cet article il me semble important de donner un peu de contexte. Je cherche depuis plusieurs mois maintenant à me procurer un bon et beau clavier mécanique. "Beau" est bien évidemment un critère totalement subjectif, et si "bon" inclue des éléments objectifs comme la solidité, la fiabilité, il intègre lui-aussi des éléments totalement subjectifs.
Ce qu'il y a de merveilleux dans le monde des claviers mécaniques haut de gamme, c'est qu'il est presque possible de faire n'importe quoi : si aucune marque ne propose un clavier tout fait qui vous corresponde, il est presque toujours possible d'en construire un qui répondent à nombre de vos critères. Presque, parce que la France n'est pas tout à fait cœur de cible : trop peu de demande pour susciter une offre variée, me suis-je laissé dire. Aussi le critère "AZERTY" ou ISO-FR est sans doute un des plus difficiles à remplir. Vous trouverez tous les claviers ou jeux de touches en ANSI-US, une portion raisonnable en ISO-UK, ISO-NO, ISO-DE, mais presque aucuns en ISO-FR. Ceux que vous trouverez seront les plus grand public, souvent des claviers de gamer dans des formats réduits comme le populaire TKL ("ten key less"), qui comme son nom l'indique fait l'impasse sur pas mal de touches.
Vortex ViBE © vortexgear.twAprès quelques mois d'étude du marché, de documentation sur les technologies, sur les capacités des claviers, sur les marques et leur réputation, de recherche d'un modèle qui réponde à mes besoins et à mes envies (surtout), j'ai fini par jeter mon dévolu sur deux modèles : le ViBE de Vortex Gear (photo ci-dessus), et le Tab 90M aussi chez Vortex Gear.
Bien sûr, je les veux en ISO-FR : je tape autant de texte que je code ou que je joue. J'ai besoin que mes accents et cédille soient accessibles sans contorsion. Et très honnêtement si je devais changer de disposition de touches j'irais sur un BEPO, pas sur l'archaïque ANSI-US.
J'ai plein d'autres critères que je ne détaille pas ici car ils n'ont aucun lien avec cette histoire de keylogger.
Comme on le remarque rapidement, le Vortex ViBE ne dispose pas de toutes les touches habituelles d'un clavier étendu : exit les flèches, page-down, page-up, etc. Toutes les touches entre le pavé numérique et le bloc de touches principal ont disparu. Par un jeu de combinaison de touches, il est possible d'utiliser le pavé numérique pour jouer le rôle des touches absentes. Dans mon quotidien, je fais un grand usage des flèches de navigation et du pavé numérique. En tout cas c'est ce qu'il me semble. J'utilise aussi les touches de fonctions (absentes sur le ViBE), et les touches "multimédia" du clavier étendu Apple qui est branché sur mes machines au travail et à la maison.
Je tenais donc à évaluer précisément l'usage que je fais de ces touches, histoire de ne pas prendre une trop grosse claque quand le fameux clavier arriverait. Et quoi de mieux pour savoir ce qu'on l'on tape toute la journée qu'un keylogger ? (réponse : rien).
La solution gratuite est assez facile à mettre en œuvre : trouver et installer sur mon poste un keylogger logiciel qui écrit dans un fichier texte tout ce qui passe par mon clavier. Mais cette solution est problématique à plusieurs égards. Notamment j'ai plusieurs machines. À la maison j'ai un OSX, un Windows et un FreeBSD, utilisés via un unique clavier physique au travers d'un switch USB. Il faudrait que je trouve une solution logicielle homogène à installer sur les trois systèmes. Au boulot et bien, juste non. Installer un keylogger logiciel qui pourrait exfiltrer à mon insu mes frappes clavier n'est réellement pas une bonne idée. Par ailleurs une solution logicielle attraperait aussi au vol ce qui sort de mes Yubikeys, et ça non plus ça ne me convient pas.
keygrapper © keelog.comLa solution matérielle qui stocke mes frappes clavier en son sein, sans rien faire sortir et qui s'affranchit totalement du système sur lequel est branché le clavier me semble donc la plus sûre à tout point de vue, et la plus adaptée à mes besoins. Bien évidement je me suis assuré que le dongle n'exfiltre aucune données via mes machines. L'exfiltration de données via un réseau hertzien est assez peu probable même si le dispositif semble assez grand pour héberger une SIM et l'électronique nécessaire pour tout renvoyer par SMS. Par ailleurs comme le dongle est branché sur un unique clavier, il m'est toujours possible de saisir des données sensibles via un autre clavier :)
Ceci posé, n'installez pas de keylogger chez vous sans savoir très exactement ce que vous faites et dans quoi vous mettez le doigt.

J'utilise le keylogger matériel depuis quelques dizaines de minutes, mais je vois déjà qu'il me faudra peut être tenter de le régler un peu finement : je tape trop vite pour lui, et pas mal de mots sont tronqués dans la capture. Cela a peut être aussi à voir avec le fait que c'est un modèle spécial supposé filtrer le trafic USB d'un clavier Apple. Les claviers Apple sont des hub USB, et sur le mien j'ai branché un casque/micro USB qui peut donc générer pas mal d'interférences au niveau du dongle qui connecte le clavier au switch USB. Quoi qu'il en soit ce n'est pas un drame puisque ce que je cherche à obtenir c'est une vue statistique de mes frappes, de mon utilisation du clavier.
Petit exemple de ce que cela donne :
[Sh]Parailleur comme le donge est branc sur un uniqu cver, il n[Bck]mest [Bck][Bck][Bck][Bck]e'est
Certains mots sont sévèrement amputés, mais l'esprit est là ! J'espère pouvoir obtenir des statistiques représentatives assez rapidement.

Bref, j'ai acheté un keylogger.

Related posts