Je vais m'intéresser dans cet article un peu plus en détail aux métriques relatives aux sauvegardes. Notamment celles qui sont faciles à mesurer : le temps d'exécution d'une sauvegarde et les volumétries des transferts réseau. La consommation CPU n'est pas évidente à mesurer sur la plate-forme de test et dans mon contexte, c'est quelque chose qui a assez peu d’importance. La mesure des I/O sur le stockage aurait pu être intéressante, mais comme le disque de destination des sauvegardes est partagé avec d'autres usages ce n'était pas une métrique récupérable lors de mes tests.
Sans m'étendre trop sur la méthodologie, voici rapidement comment j'ai procédé à ces mesures. Côté client le script de sauvegarde place des lignes horodatées dans un fichier de log (début de sauvegarde pour Borg, fin de sauvegarde pour Borg, début de purge pour Borg, etc.). Côté serveur, tcpdump m'a permis d'enregistrer le traffic réseau. Les fichiers PCap ont été transformés dans tshark pour obtenir la liste des conversations réseaux. La liste horodatée et le fichier de log du client ont ensuite été injectés dans Splunk. J'obtiens donc les traces horodatées correspondant au début et à la fin de chaque tâche de sauvegarde avec, en sandwich, les nombres de paquets et volumes de données échangés entre client et serveur.
Je collecte aussi, à chaque itération du script de sauvegarde, les volumétrie des dépôts de ces sauvegardes.
Les premières statistiques que je voudrais détailler ici sont relatives à la création de la première sauvegarde. Cette création révèle déjà une différence importante entre les trois solutions :
Pour un volume initial de 145 Go
| durée | vol in | vol out | stockage | |
|---|---|---|---|---|
| Borg | 1118 s | 1,2 Go | 52 Go | 62 Go |
| Kopia | 716 s | 1 Go | 39 Go | 75 Go |
| Restic | 583 s | 0,7 Go | 32,2 Go | 58 Go |
Pour la durée de création nous avons une variation du simple au double entre Restic et Borg. C’est assez significatif. Restic est configuré pour ouvrir quatre flux de lecture concurrents, ce qui va bien évidemment maximiser l’utilisation de toutes les ressources (réseau, IO). Restic utilise aussi son serveur HTTP pour le transport. Cela lui permet une taille de paquets supérieure et donc d'en envoyer moins que Borg ou Kopia (33,1 millions pour Restic contre 54,6 millions pour Kopia). Il en résulte une quantité de données transitant inférieure aux deux autres (moins de paquets = moins d’overhead).
Notez qu’à ce stade de mon expérimentation je n’avais pas activé la compression de Kopia (inactive par défaut) mais a priori le client ssh intégré compresse les flux. La compression est aussi désactivée sur le stockage ZFS de destination.
J’ai quelques théories mais pas de vraie explication pour la différence de volume à l’arrivée, entre les logiciels d’une part et avec le volume de données qui transite d’autre part.
Les sauvegardes suivantes sont bien plus courtes puisque seules les données modifiées depuis la sauvegarde précédente sont envoyées sur le serveur. Au long cours, Restic perd son avantage face à Kopia et se rapproche des temps constatés pour Borg.
| Avg | Median | perc98 | |
|---|---|---|---|
| Borg | 30,54 s | 30,00 s | 38,86 s |
| Kopia | 8,53 s | 8,00 s | 13,86 s |
| Restic | 24,96 s | 25,00 s | 30,00 s |
L’avantage de Kopia est réellement impressionnant.
Sur environ un mois de mesures on note même une tendance haussière pour la durée moyenne des sauvegardes Borg et Restic et baissière pour celles de Kopia (4 périodes de 7 jours, 1 de 4 jours, 295 sauvegardes pour chaque logiciel) :
| Borg | Kopia | Restic | |
|---|---|---|---|
| 2024-02-19 | 29,07 | 8,76 | 23,72 |
| 2024-02-26 | 31,28 | 9,08 | 25,57 |
| 2024-03-04 | 31,59 | 8,26 | 25,29 |
| 2024-03-11 | 31,36 | 7,77 | 26,34 |
| 2024-03-18 | 32,38 | 8,38 | 26,09 |
Sur les durées des sauvegardes, Kopia est donc très largement meilleur que ses concurrents. Sur les volumes d’échange réseau il est aussi le meilleur, mais avec une marge bien moins importante. Il se place juste devant Borg et loin devant Restic. Je n’ai pas agrégé de statistiques chiffrées car ma collecte tcpdump n’était pas suffisamment «maniable» sur une longue période. J'ai par contre quelques graphiques sur une période de 4 jours, dont j’ai vérifié manuellement les données.
L’évolution de la volumétrie du stockage des sauvegardes est intéressante à plusieurs titres. Elle permet bien sûr de faire un peu de prévision en terme de capacité. Elle permet aussi de déterminer quel logiciel est le plus efficace pour empiler un maximum de sauvegardes dans un minimum d’espace. Pour finir elle met en exergue une différence absolument fondamentale dans la gestion des rétentions entre Kopia et ses 2 concurrents. Différence qui m’a vraiment pris par surprise.
Sur le graphique suivant, l’évolution du volume des sauvegardes est visible du 17 février au 21 mars. L’axe des ordonnées est en octets, l’abréviation B est pour l’anglais «billion» : 60B est donc équivalent à 60 Go.
Dès les premiers jours, Borg est bon élève, avec une approche très efficace. Kopia et Restic par contre voient les volumétries s’envoler. Restic infléchi finalement sa trajectoire avec les premières tâches de purge visant à respecter la politique de rétention.
Le repère 1 marque le moment où j’ai activé la compression pour Kopia, sans cela je craignais que mon test soit écourté par la saturation du stockage de destination.
Le repère 2 marque la première purge de sauvegardes obsolètes pour Kopia, le motif en dents de scie descendant est probablement du au fait que Kopia purge des sauvegardes non-compressées et les remplace par des sauvegardes compressées.
Le repère 3 marque le soir du 5 mars. À ce moment les archives Borg sont au nombre de 68, les snapshots Restic au nombre de 52, et ceux de Kopia au nombre de 24. Pourtant les politiques de rétention ont été alignées :
Options de purge de Borg :
--keep-last 10 --keep-hourly 48 --keep-daily 7 --keep-weekly 4 --keep-monthly 24 --keep-yearly 3
Options de purge de Restic :
--keep-last 10 --keep-hourly 48 --keep-daily 7 --keep-weekly 4 --keep-monthly 24 --keep-yearly 3
Options de rétention de Kopia :
Annual snapshots: 3 Monthly snapshots: 24 Weekly snapshots: 4 Daily snapshots: 7 Hourly snapshots: 48 Latest snapshots: 10
La différence entre Borg et Restic s’explique très simplement. Borg conserve une archive sur un unique critère de rétention : une archive pourra être conservée parce qu’elle correspond à une rétention horaire (hourly) ou à une rétention journalière (daily), mais jamais les deux. Restic par contre étiquette les snapshots avec différentes rétentions : un snapshot peut être horaire et journalier et hebdomadaire, etc. De plus, il va étiqueter à l’avance les rétentions longues (annuelles, mensuelles…). Au 5 mars Restic stocke l’équivalent de 74 snapshots, même si en réalité il n’a que 52 points de restauration.
Globalement on s’y retrouve.
Borg :
(rule: daily #5): 20240222.1708642488 (rule: daily #6): 20240221.1708553824 (rule: daily #7): 20240220.1708469744 (rule: weekly #1): 20240218.1708295990 (rule: weekly[oldest] #2): 20240217.1708164925
Restic :
2024-02-17 11:35:05 monthly snapshot /Users/patpro
yearly snapshot
2024-02-18 23:41:20 weekly snapshot /Users/patpro
2024-02-25 23:40:46 weekly snapshot /Users/patpro
2024-02-28 19:45:29 daily snapshot /Users/patpro
2024-02-29 12:46:31 hourly snapshot /Users/patpro
../..
2024-02-29 19:23:42 hourly snapshot /Users/patpro
daily snapshot
monthly snapshot
Dans le cas de Kopia, l’histoire est très différente. Il ne calcule tout simplement pas la rétention comme les deux autres. Pour Borg et Restic --keep-hourly 48 signifie «conserve les 48 dernières archives/snapshots horaires». Pour Kopia Hourly snapshots: 48 signifie «conserve les snapshots horaires au maximum 48 heures». C’est extrêmement différent. Souvenez-vous, dans le premier article de la série j’indiquais qu’en raison de l’utilisation de Launchd avec StartInterval «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». J’indiquais aussi que le client dort la nuit, causant une interruption dans les sauvegardes. Par ailleurs, à partir du 27 février j’ai encore réduit la plage de sauvegarde, passant ainsi de 17 ou 18 sauvegardes par jour à 8 ou 9.
Sur cette fenêtre réduite, Kopia ne peut plus faire que 8 à 9 sauvegardes par jour. Après 48h il aura donc pris l’équivalent de 16 à 18 snapshots horaires, une heure plus tard le plus vieux dépassera sa durée de vie et sera purgé. Dans la même situation Borg va garder 48 archives «horaires» s’étalant sur à peu près 6 jours.
Ajoutons à cela que Kopia gère ses snapshots comme Restic : chacun peut avoir plusieurs étiquettes de rétention.
Kopia :
2024-02-18 23:38:41 CET ../.. (weekly-4) 2024-02-25 23:43:54 CET ../.. (weekly-3) 2024-02-28 19:46:56 CET ../.. (daily-7) 2024-02-29 19:20:29 CET ../.. (daily-6,monthly-2) 2024-03-01 19:02:51 CET ../.. (daily-5) 2024-03-02 19:55:36 CET ../.. (daily-4)
Pour finir, Kopia n’hésite pas à supprimer les snapshots les plus anciens là où Borg et Restic vont précieusement les conserver. Au 5 mars, Kopia a déjà supprimé le tout premier snapshot. Au 20 mars le plus ancien disponible est celui du 29 février.
Voici la situation au 20 mars :
nombre de points de restauration par date et par programme
| Borg | Kopia | Restic | |
|---|---|---|---|
| 2024-02-17 | 1 | 1 | |
| 2024-02-18 | 1 | ||
| 2024-02-25 | 1 | ||
| 2024-02-29 | 1 | 1 | 1 |
| 2024-03-03 | 1 | 1 | 1 |
| 2024-03-06 | 1 | ||
| 2024-03-07 | 1 | ||
| 2024-03-08 | 1 | ||
| 2024-03-09 | 1 | ||
| 2024-03-10 | 1 | 1 | 1 |
| 2024-03-11 | 1 | ||
| 2024-03-12 | 1 | ||
| 2024-03-13 | 4 | ||
| 2024-03-14 | 8 | 1 | 1 |
| 2024-03-15 | 8 | 1 | 8 |
| 2024-03-16 | 8 | 1 | 8 |
| 2024-03-17 | 8 | 1 | 8 |
| 2024-03-18 | 8 | 1 | 8 |
| 2024-03-19 | 8 | 8 | 8 |
| 2024-03-20 | 7 | 8 | 7 |
| total | 71 | 24 | 52 |
Pour conclure, si on privilégie des tâches de sauvegardes très rapides et économes en bande passante au détriment d’une rétention garantie et lisible, Kopia est le meilleur candidat. Si à l’inverse on souhaite maximiser le nombre de points de restauration au détriment du temps de sauvegarde et de l’utilisation de la bande passante Borg l’emporte haut-la-main. L’utilisateur de Kopia pourra néanmoins utiliser Latest snapshots pour assurer une rétention minimale pour un client qui n’est pas toujours allumé pour sa sauvegarde périodique.
| Borg | Kopia | Restic | |
|---|---|---|---|
| durée des sauvegardes | - | + | - |
| volume réseau | + | + | - |
| gestion de la rétention | + | - | + |
