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 |
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.
