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 soit aussi installé 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 certaines choses 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

De la qualité de l’air

Capteur de CO₂ Aranet4 vu de faceLa pandémie de COVID-19 a mis en lumière de nombreux éléments de notre quotidien auxquels nous n'étions pas habitués à prêter attention : l'impact des différents gestes "barrière" sur la transmission, mais aussi le traitement que l'on applique (ou pas) à notre air intérieur.
En raison de l'activité humaine, la quantité de CO₂ dans l'air dans une concentration urbaine de bonne taille se situe autour de 400 à 450 ppm. En milieu clos la concentration mesurée va dépendre de l'activité, du nombre de personnes et de la qualité de l'aération. Si on exclut les cas où le CO₂ est produit par les plantes et des activités artificielles (gazinière par exemple) alors le CO₂ que vous mesurez dans une pièce peut être corrélé à la quantité d'air sortant des poumons des mammifères présents et passés dans la pièce.
Pour faire simple, une valeur haute montre un déficit d'aération et donc votre risque de contamination peut augmenter et vos capacités cognitives baissent.
"Pour la science" et parce que je suis un irrécupérable geek, j'ai décidé de tester trois capteurs permettant la mesure en continu du taux de CO₂ dans l'air ambiant. J'ai choisi trois appareils tout-faits donc utilisables par le grand public presque sans aucune connaissance technique.

Caractéristiques générales

Aranet4 Home Mini Carbon Dioxide Monitor SCD4x CO₂ Gadget
affichage écran e-ink écran à crystaux liquides 1 LED
historique 7 jours sans 8192 mesures
interface utilisateur app iOS et Android bouton unique app iOS et Android
données CO2, température, humidité, pression atmosphérique CO2 CO2
alerte son et visuel son et visuel visuel (LED rouge)
accès distant Bluetooth sans Bluetooth
source d'energie 2 piles AA batterie interne port USB
autonomie quelques mois à plusieurs années 7 heures sans
prix 261,60 € 64,90 € 71,92 €

(les prix s'entendent TTC et frais de port inclus)

Bilan des expérimentations

J'ai utilisé ces capteurs en conditions réelles : maison, travail, transport, cinéma, etc. Ils utilisent tous trois la technologie NDIR (non-dispersive infra-red) aussi je m'attendais à ce qu'ils fournissent tous des mesures similaires. Ce n'est pas le cas, mais finalement ce n'est pas forcément ce qui retient l'attention à la fin de la journée.

Mesures

Sur la qualité des mesures, les capteurs Aranet4 Home et SCD4x CO₂ Gadget (Sensirion) sont ceux qui donnent les meilleurs résultats : ils sont très proches l'un de l'autre avec un écart qui dépasse très rarement les 50 ppm. En comparaison le Mini Carbon Dioxide Monitor (MCDM) sous-évalue la concentration de CO₂ de 160 à 200 ppm.
Le gagnant de cette catégorie est le modèle Aranet4 qui propose en plus du CO₂ une mesure de la température, de l'humidité et de la pression.

Ergonomie

Capteur de CO₂ avec son mousquetonL'ergonomie se mesure à l'aune des usages de chacun. J'attache pour ma part une grande importance à la qualité des interactions avec les appareils et je n'aime pas la friction dans l'usage quotidien. Pour moi, c'est à nouveau l'Aranet4 qui remporte la palme avec son écran e-ink qui reste lisible tout le temps sans drainer les piles. Une fois paramétré via une application smartphone assez bien faite, plus besoin d'y revenir. C'est agréable.
Il tient aussi tout seul quand on le pose, ce qui n'est pas le cas du MCDM. Ce dernier n'est pas conçu pour être posé à la verticale. On peut le coucher mais cela bloque une partie de la circulation de l'air dans le capteur. L'ergonomie du MCDM est d'ailleurs une catastrophe avec un unique bouton pour tout faire : allumer, éteindre, sortir de veille, calibrer, activer ou désactiver les alertes sonores. Son maniement est pénible et déstabilise certains utilisateurs. Pour les fans de mobilité par contre, le MCDM est sans doute plus ergonomique puisque qu'il est conçu pour être accroché à la ceinture, à un sac, via un mousqueton métallique lourd et robuste.

Autonomie

Bien que clairement conçu pour la mobilité le MCDM pêche par une autonomie catastrophique, tout juste 7 heures. Si vous l'emmenez au travail le matin, il sera vide avant la fin de votre journée et devra être rechargé (câble USB-A vers USB-C fourni). En cause une batterie de taille modeste, le rafraîchissement très rapide des mesures et un écran LCD.
Le modèle Aranet4 dispose quant à lui d'une autonomie record avec juste 2 piles AA. L'écran e-ink y est pour beaucoup mais il ne faut pas oublier que la transmission des données se fait en Bluetooth ce qui est aussi consommateur. L'Aranet4 permet par contre de régler la fréquence de rafraîchissement des mesures ce qui a un effet important sur l'autonomie.
Le SCD4x CO₂ Gadget n'a pas de source d'énergie propre, il doit être branché sur un port USB-A pour être alimenté.
La palme revient évidemment à l'Aranet4 une fois de plus.

SCD4x CO₂ Gadget de sensirion avec sa boîte verte

Gestion des données

L'Aranet4 et le SCD4x CO₂ Gadget peuvent tous les deux stocker des données de mesure pendant un certain temps. L'Aranet4 annonce une rétention de 7 jours, le SCD4x CO₂ Gadget annonce un nombre de points de mesure (l'intervalle de temps entre deux mesures est réglable dans l'application). Les deux disposent d'une application de smartphone pour récupérer les données de l'historique. L'une comme l'autre permettent d'exporter les données, ce qui est sympa si vous souhaitez conserver un historique sur le long terme. Attention cependant, si le SCD4x CO₂ Gadget n'est plus alimenté il oubliera les données enregistrées. L'Aranet4 obtient à nouveau la première place, talonné de près par le SCD4x CO₂ Gadget, largement devant le MCDM qui ne gère aucun historique des mesures.

App et divers

L'Aranet4 et le SCD4x CO₂ Gadget sont tous les deux dépendants d'une application plutôt bien faite dans les deux cas. Ces applications permettent différents réglages sur les appareils ainsi que l'affichage et l'export des données enregistrées sur les appareils. L'Aranet4 et son application sont aussi sécurisés : il faut en effet explicitement apparier la sonde avec l'application au moyen d'un code (manipulation classique avec les appareils bluetooth). L'application permet en plus de mettre à jour le firmware de la sonde. Côté SCD4x par contre, pas de manipulation d'appariement. C'est un peu moyen en termes de sécurité. L'application vérifie aussi la version du firmware de la sonde mais je ne sais pas si elle propose un mécanisme pour pousser une mise à jour le cas échéant.

Podium

Pour moi, la première place revient à l'Aranet4 qui, en dépit d'un prix très élevé, apporte une véritable solution clé en main, complète, fiable et, autant que je puisse en juger, durable.
La seconde place revient au SCD4x CO₂ Gadget. Il est d'une grande simplicité, il est petit et performant ce qui le rend attractif malgré sa dépendance à une source de courant extérieure. Son application est bien faite et j'aime le sens du détail avec le quel tout est pensé (on peut régler l'intensité de la LED).
Bon dernier le Mini Carbon Dioxide Monitor, avec une batterie fixe dont l'autonomie est en contradiction totale avec son ambition de mobilité et qui a un impact très négatif sur la durée de vie probable du produit. Une qualité de mesure légèrement inférieure aux deux autres et une ergonomie affreuse viennent encore noircir le tableau. Mais c'est aussi un modèle très abordable compte tenu du fait qu'il utilise la technologie NDIR.
Je pense qu'il est important de souligner que bon nombre de capteurs de CO₂ vendus sur des sites comme Amazon sont basés sur des technologies très inférieures en termes de qualité et de performance. Certains sont aussi vendus avec la mention NDIR alors qu'ils n'utilisent pas cette technologie. Les trois capteurs que j'ai testés sont parmi les meilleurs dans l'offre grand public.

Si l'argent n'est pas un problème ou si vous avez absolument besoin d'un capteur autonome, lisible par tous, à poser dans un coin et à oublier, achetez un Aranet4.
Si vous voulez seulement un point de mesure fixe sans trop dépenser et que lire les mesures sur une app vous convient, achetez le SCD4x CO₂ Gadget de Sensirion.
Si vous avez besoin, quelques heures dans la journée, d'un capteur qui vous accompagne et qui soit capable de vous alerter très rapidement en cas de dépassement du seuil de CO₂ alors le format "accrochable" et la fréquence élevée de rafraîchissement du Mini Carbon Dioxide Monitor en font l'outil idéal.

photo du gadget de Sensirion branché sur un hub USB et de l'interface d'accueil de l'application de pilotage MyAmbience

SCD4x CO₂ Gadget branché sur un hub USB, écran d'un système sous macOS faisant tourner l'app iOS MyAmbience de Sensirion

Related posts

Cracking passwords: testing PCFG password guess generator

Cracking passwords is a kind of e-sport, really. There's competition among amateurs and professionals "players", tools, gear. There are secrets, home-made recipes, software helpers, etc.
One of this software is PCFG password guess generator, for "Probabilistic Context-Free Grammar". I won't explain the concept of PCFG, some scientific literature exists you can read to discover all the math inside.
PCFG password guess generator comes as two main python programs: pcfg_trainer.py and pcfg_manager.py. Basic mechanism is the following:
- you feed pcfg_trainer.py with enough known passwords to generate comprehensive rules describing the grammar of known passwords, and supposedly unknown passwords too.
- you run pcfg_manager.py, using previously created grammar, to create millions of password candidates to feed into your favorite password cracker (John the Ripper, Hashcat…).

In order to measure PCFG password guess generator's efficiency I've made few tests. Here is my setup:

  • Huge password dump, 117205873 accounts with 61829207 unique Raw-SHA1 hashes;
  • John the Ripper, Bleeding Jumbo, downloaded 20160728, compiled on FreeBSD 10.x;
  • PCFG password guess generator, downloaded 20160801, launched with Python 3.x;

Here's my methodology:

Of these 61829207 hashes, about 35 millions are already cracked. I've extracted a random sample of 2 millions known passwords to feed the trainer. Then I've used pcfg_manager.py to create a 10 millions lines word list. I've also trimmed the famous Rockyou list to it's 10 millions first lines, to provide a known reference.

Finally, I've launched this shell script:

#!/bin/sh
for i in none wordlist jumbo; do
  ./john --wordlist=pcfg_crckr --rules=$i --session=pcfg_cracker-$i --pot=pcfg_cracker-$i.pot HugeDump
  ./john --wordlist=ry10m --rules=$i --session=ry10m-$i --pot=ry10m-$i.pot HugeDump
done

No forking, I'm running on one CPU core here. Each word list is tested three times, with no word mangling rules, with defaults JtR rules, and finally with Jumbo mangling rules.

Some results (number of cracked passwords):

Rules PCFG Rockyou
none 4409362 2774971
wordlist 5705502 5005889
Jumbo 21146209 22781889

That I can translate into efficiency, where efficiency is Cracked/WordlistLength as percentage:

Rules PCFG Rockyou
none 44.1% 27.7%
wordlist 57.1% 50.1%
Jumbo 211.5% 227.8%

It's quite interesting to see that the PCFG generated word list has a very good efficiency, compared to Rockyou list, when no rules are involved. That's to be expected, as PCFG password guess generator has been trained with a quite large sample of known passwords from the same dump I am attacking.
Also, the PCFG password guess generator creates candidates that are not very well suited for mangling, and only the jumbo set of rules achieves good results with this source. Rockyou on the other hand starts quite low with only 27.7% but jumps to 50.1% with common rules, and finally defeats PCFG when used with jumbo rules.

On the word list side, Rockyou is known and limited: it will never grow. But PCFG password guess generator looks like it can create an infinite list of candidates. Let see what happens when I create a list of +110 M candidates and feed them to JtR.

Rules PCFG Efficiency
none 9703571 8.8%
wordlist 10815243 9.8%

Efficiency plummets: only 9.7 M hashes cracked with a list of 110398024 candidates, and only 1.1 M more when the set of rules "wordlist" is applied. It's even less beneficial than with a list of 10 M candidates (+1.3 M with "wordlist" rules, compared to "none").

On the result side, both word list with jumbo rules yields to +21 M cracked passwords. But are those passwords identical, or different?

Rules Total unique cracked Yield
none 6013896 83.7%
wordlist 8184166 76.4%
Jumbo 26841735 61.1%
Yield = UniqueCracked / (PcfgCracked + RockyouCracked)

A high yield basically says that you should run both word lists into John. A yield of 50% means that all pwd cracked thanks to PCFG are identical to those cracked with the Rockyou list.

As a conclusion, I would say that the PCFG password guess generator is a very interesting tool, as it provides a way to generate valid candidates pretty easily. You probably still need a proper known passwords corpus to train it.
It's also very efficient with no rules at all, compared to the Rockyou list. That might make it a good tool for very slow hashes when you can't afford to try thousands of mangling rules on each candidate.

Some graphs to illustrate this post:

every john session on the same graph

every john session on the same graph

every session, zoomed on the first 2 minutes

every session, zoomed on the first 2 minutes

Rules "wordlist" on both lists of candidates

Rules "wordlist" on both lists of candidates

Rules "none", both lists of candidates

Rules "none", both lists of candidates

Related posts

ZFS primary cache is good

Last year I've written a post about ZFS primarycache setting, showing how it's not a good idea to mess with it. Here is a new example based on real world application.
Recently, my server crashed, and at launch-time Splunk decided it was a good idea to re-index a huge apache log file. Apart from exploding my daily index quota, this misbehavior filed the index with duplicated data. Getting rid of 1284408 events in Splunk can be a little bit resource-intensive. I won't detail the Splunk part of the operation: I've ended up having 1285 batches of delete commands that I've launched with a simple for/do/done bash loop. After a while, I noticed that the process was slow and was making lots of disk IOs. Annoying. So I checked:

# zfs get primarycache zdata/splunk
NAME          PROPERTY      VALUE         SOURCE
zdata/splunk  primarycache  metadata      local

Uncool. This setting was set locally so that my toy (Splunk) would not harvest all ARC from the server, hurting production. For efficiency's sake, I've switched back the primary cache to all:

# zfs set primarycache=all zdata/splunk

Effect was almost instantaneous: ARC filled with Splunk data and disk IOs plummeted.

primarycache # of deletes per second
metadata 10.06
all 22.08

A x2.2 speedup on a very long operation (~20 hours here) is a very good argument in favor of primarycache=all for any ZFS user.

acceleration of a repetitive splunk operation thanks to ZFS primarycache setting

Acceleration of a repetitive splunk operation thanks to ZFS primarycache setting

Related posts

L4D2: comparative benchmark between Mac OS X and Windows

Back in december 2012 I've benchmarked (shortly) native and virtualized Mac OS X against virtualized Windows.
Few days ago, I've dedicated a 250G B SSD to a Windows 7 installation, inside my Mac Pro. Weird thing for me to go back and forth between Mac OS X and Windows. I'm more accustomed to +50 days long uptime. Admittedly my various attempts to put Mac OS X into deep sleep, reboot on Windows, and go back later to a fully restored Mac OS X session right out from deep sleep, are failing. That's another story.
Nevertheless, I'm using this Windows system as a playground.

Inside this Mac Pro model 2010, I've one Xeon quad core 2.8 GHz with 24 GB RAM, and a Radeon HD 5770. One SSD is dedicated to Mac OS X 10.6.8, and one SSD is dedicated to Windows 7 Pro 64 bits (with latest stable Catalyst drivers). Both systems are using the latest Steam client with a fully updated and clean Left 4 Dead 2 install.

I've recorded a demo, and played back this file on both systems with identical video settings, recording fps numbers during the playback. The demo is 17827 frames long, and video settings are "MSAA x4", "Anisotropic 8x", "vertical sync triple", "resolution 1920x1200", "shader detail very high', "effect detail high", "model/texture detail high".

The playback is a bit laggy on Mac OS X, especially when the player is looking at fire. It would be playable, but not a very smooth experience. The playback is better on Windows.
Here is the plot of numbers of frames calculated at a given fps rate. For example, on Mac OS X (black line) a total of 4 frames were calculated at a frame rate of 10 fps. On Windows, 90 frames where calculated at a frame rate of 47 fps.

click plot to display full size

click plot to display full size

Windows 7 has better drivers, and may be the game itself is coded better. The fact is some situations in the game are not handled very well by the GPU on Mac OS X. The huge spike around 30 fps means that ~2500 frames were computed at about 30 fps. Not good. But more importantly the global shape of the plot shows a spread of fps values from as low as 10 fps to 60 fps. Note that the log scale on Y does mask isolated frames (Y=1).
Windows does a better job here, with only a handful of frames below 40 fps.

Fortunately L4D2 is an old game, and my hardware is enough to handle it nicely even on Mac OS X (I usually play at 1600x1000), but being able to push it a little further with full quality on Windows is a nice thing. I hope L4D3 will run ok too, some day, in a not too distant future.

Edit

To complete the comparison, I've made a Cinebench R15 benchmark. The OpenGL score on Windows 7 is ~64 fps, and the same test on Mac OS X 10.6.8 is ~53 fps. On CPU side both OSes score around 440.

Related posts