Borg, Kopia, Restic : restauration et maintenance

Restauration

Depuis l’article précédent nous savons comment se déroule la sauvegarde dans Borg, Kopia et Restic. Nous allons maintenant examiner la restauration et la maintenance.
La restauration est une étape de la vie d'une sauvegarde, qui — quand tout se passe bien — n’est jamais utilisée. Aussi, il est tout à fait compréhensible que le benchmark de cette étape ne soit pas excessivement intéressant et représentatif. La prise de trace est faite dans le script de sauvegarde original mais la restauration n'a pas été exécutée tous les jours.
Le test a consisté en la restauration d'une archive zip de 39 Mo à partir du plus ancien snapshot disponible dans les archives, ainsi que la restauration d'un répertoire Library/Preferences à partir du plus ancien des 10 derniers snapshots. La taille du répertoire est variable d'une sauvegarde à l'autre, mais tourne globalement autour des 290 Mo pour 951 répertoires et ~15K fichiers.

Pendant ce test de restauration, la différence entre les trois logiciels est à nouveau très marquée. Borg reçoit de la part du serveur autour de 575 Mo de données. Il envoie autour de 6 Mo de données. Kopia est un peu meilleur élève puisqu'il va exécuter la même restauration avec seulement 450 Mo de données en réception et autour de 20 Mo en émission. Mais c'est ici Restic qui a l'empreinte réseau la plus réduite, puisqu'il parvient à faire la restauration complète attendue avec seulement 120 Mo de données en réception et 0,5 Mo de données en émission.

Borg Kopia Restic
avg in -575,00 Mo -447,76 Mo -120,82 Mo
avg out 5,92 Mo 20,59 Mo 0,52 Mo

comparaison sur 3 jours des volumes échangés lors des tâches de restauration

Sur la durée de la restauration, Restic est aussi premier, avec une tâche qui se conclut en 8 secondes là où Kopia tourne entre 12 et 14 secondes et Borg, entre 18 et 19 secondes. On reste sur des durées relativement courtes et même si ces différences peuvent être importantes en proportion cela reste assez faible en valeur absolue.

Pour la restauration, Restic est clairement le vainqueur, assez loin devant Kopia. Borg est bon dernier, en particulier à cause de sa consommation réseau.

Borg Kopia Restic
Durée des restaurations - - +
Volume réseau - - +

Maintenance

La première tâche de maintenance, aussi la plus simple à mesurer, est la phase de «prune». Cette tâche vise à supprimer les archives, snapshots et points de restauration obsolètes. Elle est essentielle pour que le dépôt des sauvegardes ne voit pas sa volumétrie exploser hors de contrôle. C'est cette étape qui est responsable du respect de la politique de rétention que l'utilisateur souhaite appliquer.
J'ai détaillé dans mon article précédent comment la gestion de la rétention pouvait être pleine de surprises. Je ne reviens pas sur ce point en particulier. Je vais m'intéresser ici à la consommation de ressources lors de ces opérations.
À noter que Kopia fait spontanément l'opération de nettoyage au lancement d'une nouvelle sauvegarde sans qu'il soit nécessaire de lui demander. Pour pouvoir mesurer cette opération de manière indépendante j'ai dû la planifier juste avant l'opération de sauvegarde (et pas après, comme initialement prévu).

La consommation de bande passante par l'opération de nettoyage est pour le moins surprenante. Borg est ici le logiciel qui se distingue par sa grande régularité avec environ 180 Mo de données entrantes et 1,3 Mo de données sortantes. Pour les deux autres, la situation est beaucoup plus chaotique. Kopia semble se comporter de manière plutôt stable dans le temps avec des données entrantes extrêmement limitées à ~92 Ko et des données sortantes pour un volume d'environ 70 ko, mais on constate la présence d'anomalies énormes, avec certaines opérations de nettoyage affichant des transferts entrants se rapprochant de 1,4 Go et des transferts sortants proches de 1 Go. Il semble que ces pics soient attribuables à d’autres tâches de maintenance (voir plus loin).
Restic aussi montre une grande irrégularité dans les volumétries de données échangées avec le serveur lors des opérations de nettoyage. Néanmoins, les volumes restent maîtrisés, largement sous la barre des 40 Mo en émission et sous la barre des 70 Mo en réception.

Chiffres sur 4 jours, mi-mars

Borg Kopia Restic
avg in -175,65 Mo -62,02 Mo -24,74 Mo
avg out 1,34 Mo 42,23 Mo 27,55 Mo
median in -181,02 Mo -95 Ko -16,97 Mo
median out 1,31 Mo 70 Ko 28,01 Mo
perc98 in -190,17 Mo -879,78 Mo -66,49 Mo
perc98 out 2,27 Mo 599,28 Mo 34,52 Mo

Sur la durée des étapes de nettoyage, Borg et Kopia sont relativement bien placés avec bien évidemment quelques pics importants pour Kopia et une certaine régularité pour Borg. Restic, quant à lui, est bon dernier avec un écart important avec ces deux concurrents.

Chiffres sur 4 jours, mi-mars

avg median perc98
Borg 9.30 s 9.00 s 14.90 s
Kopia 4.41 s 2.00 s 33.00 s
Restic 113.50 s 126.00 s 140.20 s

Pour conclure sur le nettoyage je laisse la première place à Kopia car les anomalies constatées sont très certainement dues à des opérations de vérification automatique des snapshots/du dépôt qui sont gérées automatiquement par ce logiciel.

Borg Kopia Restic
Durée des nettoyages + + -
Volume réseau - + +

Les autres tâches de maintenance sont liées à la vérification des sauvegardes et du dépôt des sauvegardes. Tout comme le nettoyage, la vérification des snapshots et de l’état de santé du dépôt est gérée automatiquement par Kopia (du moins en théorie). Pour Borg et Restic ce sont des opérations à planifier en plus du reste.
Ces opérations sont réputées rares, certaines même exceptionnelles (comme les opérations de réparation de dépôt). Aussi j’ai décidé de ne pas les mesurer sur le long terme, ni d’en tirer des statistiques. J’ai simplement pris quelques mesures sur des tâches spécifiques.

Borg

$ time borg check --rsh "${SSH}" ${HOMEREPO}

real	8m36.258s
user	4m49.125s
sys	0m25.353s

Cette opération consomme à la louche 100% CPU côté client (python) et 0% CPU côté serveur.

$ time borg check --verify-data --rsh "${SSH}" ${HOMEREPO}

real	26m0.151s
user	15m9.882s
sys	2m37.629s 

Cette opération a des phases à 100% CPU côté client (python) et 1% CPU côté serveur (python) et d’autres phases à 50% python + 35% ssh côté client et 50-60% sshd + 30-40% python côté serveur.

$ time borg check --repair --repository-only --rsh "${SSH}" ${HOMEREPO}
This is a potentially dangerous function.
check --repair might lead to data loss (for kinds of corruption it is not
capable of dealing with). BE VERY CAREFUL!

Type 'YES' if you understand this and want to continue: YES

real	3m29.619s
user	0m0.252s
sys	0m0.088s

Cette dernière charge presque uniquement le serveur : 0% CPU côté client et 85% CPU côté serveur.
À noter que cette réparation s’est faite dans le vide car le dépôt est en parfaite santé.

Kopia

$ time kopia maintenance run
Running full maintenance...
Looking for active contents...
Looking for unreferenced contents...
GC found 16436 unused contents (1.3 GB)
GC found 16550 unused contents that are too recent to delete (1.2 GB)
GC found 409930 in-use contents (73.3 GB)
GC found 28 in-use system-contents (71.6 KB)
Previous content rewrite has not been finalized yet, waiting until the next blob deletion.
Found safe time to drop indexes: 2024-04-06 15:51:09.649426 +0200 CEST
Dropping contents deleted before 2024-04-06 15:51:09.649426 +0200 CEST
Looking for unreferenced blobs...
  deleted 100 unreferenced blobs (2 GB)
Deleted total 138 unreferenced blobs (2.5 GB)
Cleaning up old index blobs which have already been compacted...
Cleaned up 8 logs.
Finished full maintenance.

real	0m9.883s
user	0m15.166s
sys	0m6.066s

$ time kopia maintenance run
Running full maintenance...
Looking for active contents...
Looking for unreferenced contents...
GC found 0 unused contents (0 B)
GC found 18882 unused contents that are too recent to delete (1.6 GB)
GC found 409930 in-use contents (73.3 GB)
GC found 23 in-use system-contents (56 KB)
Rewriting contents from short packs...
Total bytes rewritten 649.4 MB
Found safe time to drop indexes: 2024-04-06 15:51:09.649426 +0200 CEST
Dropping contents deleted before 2024-04-06 15:51:09.649426 +0200 CEST
Skipping blob deletion because not enough time has passed yet (59m59s left).
Cleaning up old index blobs which have already been compacted...
Cleaned up 0 logs.
Finished full maintenance.

real	0m27.121s
user	0m29.134s
sys	0m11.207s

Notez la différence entre les deux exécutions que séparent seulement quelques secondes.

$ time kopia snapshot verify --verify-files-percent=10 --file-parallelism=10 --parallel=10
Listing blobs...
Listed 4141 blobs.
Processed 0 objects.
Processed 12137 objects.
Processed 17883 objects.
Processed 20581 objects.
../..
Processed 365793 objects.
Processed 368714 objects.
Finished processing 389361 objects.

real	3m26.325s
user	0m52.439s
sys	0m48.059s

Kopia dispose de la capacité intéressante de pouvoir vérifier seulement un pourcentage des fichiers d’une sauvegarde (ici 10%).
La consommation CPU se répartie comme suit : 30 à 60% CPU sur le client et sur le serveur 80-90% CPU pour sshd + 15-20% CPU pour sftpd.

Une vérification de 100% des fichiers allonge simplement l’opération :

$ time kopia snapshot verify --verify-files-percent=100 --file-parallelism=10 --parallel=10
Listing blobs...
Listed 4034 blobs.
Processed 0 objects.
Processed 4566 objects.
Processed 4577 objects.
Processed 4594 objects.
../..
Processed 372956 objects.
Processed 373370 objects.
Finished processing 393794 objects.

real	15m54.926s
user	5m37.337s
sys	4m3.843s

Restic

$ time restic -r rest:http://192.168.0.22:8000/ check
using temporary cache in /var/folders/1t/fbr0pvvc8xjg8f006s7cd4280000gp/T/restic-check-cache-2552920101
repository 9c062709 opened (version 2, compression level auto)
created new cache in /var/folders/1t/fbr0pvvc8xjg8f006s7cd4280000gp/T/restic-check-cache-2552920101
create exclusive lock for repository
load indexes
[0:00] 100.00%  6 / 6 index files loaded
check all packs
check snapshots, trees and blobs
[3:46] 100.00%  55 / 55 snapshots
no errors were found

real	3m48.649s
user	2m24.891s
sys	0m31.295s
$ time restic -r rest:http://192.168.0.22:8000/ check --read-data
using temporary cache in /var/folders/1t/fbr0pvvc8xjg8f006s7cd4280000gp/T/restic-check-cache-448461585
repository 9c062709 opened (version 2, compression level auto)
created new cache in /var/folders/1t/fbr0pvvc8xjg8f006s7cd4280000gp/T/restic-check-cache-448461585
create exclusive lock for repository
load indexes
[0:00] 100.00%  6 / 6 index files loaded
check all packs
check snapshots, trees and blobs
[3:46] 100.00%  55 / 55 snapshots
read all data
[10:36] 100.00%  4588 / 4588 packs
no errors were found

real	14m23.868s
user	6m55.821s
sys	1m45.116s

La vérification des données consomme 45 à 55% CPU côté client et autour de 67% CPU côté serveur.

$ time restic -r rest:http://192.168.0.22:8000/ repair snapshots
repository 9c062709 opened (version 2, compression level auto)
found 1 old cache directories in /Users/patpro/Library/Caches/restic, run `restic cache --cleanup` to remove them
[0:00] 100.00%  6 / 6 index files loaded

snapshot 09e89c9e of [/Users/patpro] at 2024-04-04 11:38:02.747322 +0200 CEST)

snapshot 0cf2fd62 of [/Users/patpro] at 2024-04-01 19:20:10.583797 +0200 CEST)

../..

snapshot fbeb283e of [/Users/patpro] at 2024-03-17 19:17:04.390071 +0100 CET)

snapshot fec2f8b1 of [/Users/patpro] at 2024-04-07 17:15:45.588862 +0200 CEST)

no snapshots were modified

real	3m22.149s
user	3m15.453s
sys	0m9.031s

Ici la consommation CPU est d’environ 100% côté client et 0% côté serveur. À priori il travaille entièrement sur le client à partir du cache local. Si le cache local n’est pas disponible, Restic le reconstruit et la consommation CPU du serveur fait alors des pics jusqu’à plus de 80%.

Bilan
Rapportées au nombre de snapshots / archives et à la taille des dépôts, les durées de vérifications exhaustives sont les suivantes :

Borg Kopia Restic
Nombre de snapshots 72 26 55
Volume du dépôt 78,4 Go 74,5 Go 80,5 Go
Par snapshot 22s 37s 18s
Par Go 19,9s 12,9s 10,7s

Borg et Restic sont assez proches en terme de performance quand il s’agit de vérifier les données sauvegardées mais Borg est un poil plus lent tout en consommant plus de CPU sur le client. Kopia est finalement bien plus lent que les deux autres.

Je l’ai évoqué rapidement un peu plus haut dans le cas de Restic et c’est valable pour les deux autres : ces logiciels utilisent un système de cache local pour accélérer certaines opérations. La volumétrie de ce cache peut avoir une forte importance dans certains contextes et semble proportionnelle à la quantité de blocs de donnée uniques sauvegardés sur le dépôt (c’est au moins le cas pour Borg). Je ne suis pas en mesure de présenter des données chiffrées fiables pour Borg en raison d’un oubli de ma part : n’ayant pas relocalisé le cache de Borg pour mon expérience, il s’est mélangé avec le cache de mes autres dépôts Borg (ceux de mes vraies sauvegardes), si bien que sa volumétrie n’est pas comparable avec celle des autres logiciels.
Ceci dit, voici tout de même quelques informations :

Volume du cache de Borg, tout confondu 7,1 Go
Volume du cache de Borg, test, isolé tardivement 828 Mo
Volume du cache de Kopia 6,2 Go
Volume du cache de Restic 11 Go

Le «Volume du cache de Borg, test, isolé tardivement» correspond à un cache pour Borg, dédié à mon script de test, créé 2 jours auparavant. Il a immédiatement atteint les 828 Mo et n’a pas grossi depuis.
Dans tous les cas, Restic est ici le grand perdant, et si on ramène la taille du cache au nombre de snapshots / archives sur le dépôt, alors Borg est vainqueur.

Borg Kopia Restic
Durée des vérifications + - +
Taille du cache local + - -

Pendant cette expérience j’ai apprécié de découvrir que Kopia gère pour l’utilisateur des opérations de maintenance qu’il faut lancer explicitement sur les deux autres logiciel. Je trouve aussi que l’option de Kopia permettant la vérification d’une fraction des fichiers est intéressante. Pour finir j’apprécie que Restic propose une option pour l’opération de nettoyage permettant de faire varier le curseur entre performance et optimisation du stockage.

Related posts

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.